实时警报通知:微信告警通知的重要性解析
805
2023-01-08
本文目录一览:
作为一种将算法集成到工具里的新型运维方式,AIOps 可以帮助企业最大程度地简化运维工作,把 IT 从耗时又容易出错的流程中解放出来。
有了 AIOps,当 IT 出现故障隐患,运维人员不需要再等待系统发出故障告警,通过内置的机器学习算法以及大数据技术,就能自动发现系统的各类异常,从而实现从异常入手判断故障发生的可能性、严重性和影响,依赖机器对数据的分析结果,判断最佳的应对方案。
由此可以看出,基于 AIOps 的管理方法对监控式运维的底层技术实现了颠覆。传统 IT 运维管理工具更为关注突发事件(即告警)、配置和性能,而 AIOps 则更加关注问题、分析和预测,二者可谓互相补充相得益彰。
对 IT 运维人员而言,当一条告警被确认的时候,不但意味着你第一时间发现了业务故障,更意味着在故障发生的这一刻,业务已经受到了影响。而随着 AIOps 的出现,IT 部门可以通过机器学习和算法技术,事先发现 IT 系统的运行异常,提前进行故障的防范甚至规避措施,确保业务故障不出现或者少出现,这些对于 IT 和业务部门来说意义重大。
当前,随着企业数字业务的快速发展和业务量的攀升,企业信息系统架构的升级变迁,以及企业多套业务系统的在线运营,各类监控组件和应用系统间的关系错综复杂,系统运维的难度也急剧增加,且面临着巨大挑战。
在传统运维方式下,数据规模大且离散,数据治理和全面分析能力薄弱且依赖于经验和规则,运维十分被动,解决问题效率非常低下,运维的实用性大打折扣,难以满足当前主动运营的要求。
具体来说有以下几点:
发现问题难:企业在经年累月中布局了诸多监控工具,但是监控手段阈值的设定单一,且一般都是静态阈值,而指标和告警的异常却是多样化的,这样就会造成大量的误报漏报现象。此外,目前绝大多数的监控工具,缺乏趋势预测能力,使得运维局面非常被动,导致发现问题十分困难。
根因定位难:发现问题时一般都是对问题进行定性分析,可能了解到某一告警对应的指标波动是值得关注的,但是并不能因此确定造成这种现象具体根因。而且目前的监控工具,大多缺乏综合根因定界及定位分析的手段,即便对监控进行了集中管理,也难以通过单纯的几种指标进行根因定位。
数据治理难:当数字化建设进行到一定程度的时候,被管理对象的数据量相应的也是水涨船高,数据数量大、类别多且非常分散,很难通过某一指标体系来衡量系统的健康度,也没有一个统一的视角去判断数据质量的好坏优劣。
运营分析难:现有的大多数基础监控工具,多数都是从自己的管理阈例如系统管理、网络管理出发看待问题,缺乏端到端的分析能力,没办法以业务视角从综合运营分析的角度,去看待多样化指标对系统的影响。
而智能运维是一种全新的数字化运维能力,也将是数字化转型的必备能力。智能运维相对于传统运维模式而言,能够在运维数据治理、业务数字化风险、运维人力成本和业务侧影响力四个方面有本质的效能提升。
智能运维相对于传统运维模式而言,能够在四个方面有本质的效能提升:
运维数据治理。通过高性能实时处理的数据平台广泛采集、处理和分析数字化业务运行过程中的多样化运维数据,包括告警、指标、日志、配置以及运维工单等类别,不仅提升了运维大数据的治理能力,优化了数据质量,而且为进一步激活运维数据的价值打下了良好基础;
业务数字化风险。使运维人员不仅提升了历史运维数据的分析能力并且能够对实时数据进行异常检测和问题预判,有效降低数字化业务的运行风险,提升可用性、稳定性;
运维人力成本。使真正意义上的跨域根因定位成为可能,降低对专业运维人员经验技能的依赖,迅速缩短故障排查时间并有效降低人力成本;
业务侧影响力。以业务视角利用多元化数据提高运营分析和决策能力,比如端到端的分析业务交易状态,提供给业务、客服部门及时反馈和决策支持依据,充分增强业务影响力;
智能运维发展正如火如荼,Gartner预见其为下一代运维,认为到2022年将有近50%的企业用户部署智能运维。虽然目前不少企业已经在积极投入建设,也还有一些企业处在迷茫阶段,对这种趋势不太清晰,借用著名作家威廉吉布森的话,“未来已来,只是分布不均。”
统一监控平台,说到底本质上也是一个监控系统,监控的基本能力是必不可少的,回归到监控的本质,先梳理下整个监控体系:
① 监控系统的本质是通过发现故障、解决故障、预防故障来为了保障业务的稳定。
② 监控体系一般来说包括数据采集、数据检测、告警管理、故障管理、视图管理和监控管理6大模块。而数据采集、数据检测和告警处理是监控的最小闭环,但如果想要真正把监控系统做好,那故障管理闭环、视图管理、监控管理的模块也缺一不可。
一、数据采集
1、采集方式
数据采集方式一般分为Agent模式和非Agent模式;
Agent模式包括插件采集、脚本采集、日志采集、进程采集、APM探针等
非Agent模式包括通用协议采集、Web拨测、API接口等
2、数据类型
监控的数据类型有指标、日志、跟踪数据三种类型。
指标数据是数值型的监控项,主要是通过维度来做标识。
日志数据是字符型的数据,主要是从中找一些关键字信息来做监控。
跟踪型数据反馈的是跟踪链路一个数据流转的过程,观察过程中的耗时性能是否正常。
3、采集频率
采集频率分秒级、分钟级、随机三种类型。常用的采集频率为分钟级。
4、采集传输
采集传输可按传输发起分类,也可按传输链路分类。
按传输发起分类有主动采集Pull(拉)、被动接收Push(推)
按传输链路分类有直连模式、Proxy传输。
其中Proxy传输不仅能解决监控数据跨网传输的问题,还可以缓解监控节点数量过多导致出现的数据传输的瓶颈,用Proxy实现数据分流。
5、数据存储
对于监控系统来说,主要有以下三种存储供选择
① 关系型数据库
例如MySQL、MSSQL、DB2;典型监控系统代表:Zabbix、SCOM、Tivoli;
由于数据库本身的限制,很难搞定海量监控的场景,有性能瓶颈,只在传统监控系统常用
② 时序数据库
为监控这种场景设计的数据库,擅长于指标数据存储和计算;例如InfluxDB、OpenTSDB(基于Hbase)、Prometheus等;典型监控系统代表:TICK监控框架、 Open-falcon、Prometheus
③ 全文检索数据库
这类型数据库主要用于日志型存储,对数据检索非常友好,例如Elasticsearch。
二、数据检测
1. 数据加工
① 数据清洗
数据清洗比如日志数据的清洗,因为日志数据是非结构化的数据,信息密度较低,因此需要从中提取有用的数据。
② 数据计算
很多原始性能数据不能直接用来判断数据是否产生异常。比如采集的数据是磁盘总量和磁盘使用量,如果要检测磁盘使用率,就需要对现有指标进行一个简单的四则运算,才能得到磁盘使用率。
③ 数据丰富
数据丰富就是给数据打上一些tags标签,比如打上主机、机房的标签,方便进行聚合计算。
④ 指标派生
指标派生指的是通过已有的指标,通过计算得出新的指标。
2. 检测算法
有固定规则和机器学习算法。固定算法是较为常见的算法,静态阈值、同比环比、自定义规则,而机器学习主要有动态基线、毛刺检测、指标预测、多指标关联检测等算法。
无论是固定规则还是机器学习,都会有相应的判断规则,即常见的< =和and/or的组合判断等。
三、告警管理
1. 告警丰富
告警丰富是为了后续告警事件分析做准备,需要辅助信息去判断该怎么处理、分析和通知。
告警丰富一般是通过规则,联动CMDB、知识库、作业历史记录等数据源,实现告警字段、关联信息的丰富;通过人工打Tags也是一种丰富方式,不过实际场景下由于人工成本高导致难以落地。
2. 告警收敛
告警收敛有三种思路:抑制、屏蔽和聚合
① 抑制
即抑制同样的问题,避免重复告警。常见的抑制方案有防抖抑制、依赖抑制、时间抑制、组合条件抑制、高可用抑制等。
② 屏蔽
屏蔽可预知的情况,比如变更维护期、固定的周期任务这些已经知道会发生的事件,心里已经有预期。
③ 聚合
聚合是把类似或相同的告警进行合并,因为可能反馈的是同一个现象。比如业务访问量升高,那承载业务的主机的CPU、内存、磁盘IO、网络IO等各项性能都会飙升,这样把这些性能指标都聚合到一块,更加便于告警的分析处理。
3. 告警通知
① 通知到人
通过一些常规的通知渠道,能够触达到人。
这样在没有人盯屏的时候,可以通过微信、短信、邮件触发到工作人员。
② 通知到系统
一般通过API推送给第三方系统,便于进行后续的事件处理
另外还需要支持自定义渠道扩展(比如企业里有自己的IM系统,可以自行接入)
四、故障管理
告警事件必须要处理有闭环,否则监控是没有意义的。
最常见还是人工处理:值班、工单、故障升级等。
经验积累可以把人工处理的故障积累到知识库里面,用于后续故障处理的参考。
自动处理,通过提取一些特定告警的固化的处理流程,实现特定场景的故障自愈;比如磁盘空间告警时把一些无用日志清掉。
智能分析主要是通过故障的关联分析、定位、预测等AI算法,进一步提升故障定位和处理的效率;
1. 视图管理
视图管理也属于增值性功能,主要是满足人的心理述求,做到心中有底,面向的角色很多(领导、管理员、值班员等)。
大屏:面向领导,提供全局概览
拓扑:面向运维人员,提供告警关联关系和影响面视图
仪表盘:面向运维人员,提供自定义的关注指标的视图
报表:面向运维人员、领导,提供一些统计汇总报表信息,例如周报、日报等
检索:面向运维人员,用于故障分析场景下的各类数据检索
2. 监控管理
监控管理是企业监控落地过程中的最大挑战。前5个模块都是监控系统对外提供的服务功能,而监控管理才是面向监控系统自身的管理和控制,关注真正落地的过程的功能呈现。主要有以下几个方面:
配置:简单、批量、自动
覆盖率:监控水平的衡量指标
指标库:监控指标的规范
移动端:随时随地处理问题
权限:使用控制
审计:管理合规
API:运维数据最大的来源,用于数据消费
自监控:自身稳定的保障
为了实现上述监控六大基础能力模块,我们可以按如下架构设计我们的统一监控平台。
主要分三层,接入层,能力层,功能层。
接入层主要考虑各种数据的接入,除了本身Agent和插件的采集接入,还需要支持第三方监控源的数据接入,才能算一个完整的统一监控平台。
能力层主要考虑监控的基础通用能力,包含数据采集模块、数据存储模块、数据加工模块、数据检测模块、AI分析模块。
功能层需要贴近用户使用场景,主要有管理、展示两类功能,在建设的过程中可以不断丰富功能场景。
另外,考虑到数据的关联关系,为未来的数据分析打下基础,监控和CMDB也需要紧密联动,所有的监控对象都应该用CMDB进行管理,另外,还可以配置驱动监控为指导理念,实现监控的自动上下线,告警通知自动识别负责人等场景,简化监控的维护管理。
为了统一监控平台能够在企业更好的落地,我们需要配备对应的管理体系,其中最重要的是指标管理体系。
指标管理体系的核心理念:
监控的指标体系是以CMDB为骨架,以监控指标为经脉,将整个统一监控平台的数据有机整合起来。
贯穿指标的生命周期管理,辅以指标的管理规范,保障监控平台长久有序的运行。
从企业业务应用的视角出发,一般将企业监控的对象分为6层,也可以根据企业自己的情况进行调整:
基础设施层
硬件设备层
操作系统层
组件服务层
应用性能层
业务运营层
本人也是个刚入行的金融小白,刚看到一篇文章,觉得很好,来和大家分享下:
数字化转型:大势所趋下的机遇与挑战
01银行业数字化转型是大势所趋
“数字化转型”并不是什么新鲜的概念。早在20世纪80年代个人电脑诞生之后,依托于个人电脑和单机软件的大规模应用,第一波数字化转型显露了雏形,这是数字化转型的第一阶段。
20世纪90年代,伴随着互联网技术的突飞猛进,第二次信息化浪潮孕育了第二波数字化转型。
当前,随着金融科技的迅猛发展,第三次数字化转型浪潮应运而生,人工智能、区块链、云计算、大数据等技术被运用到金融领域的方方面面。
根据相关数据统计,超过20%的银行已在新兴技术领域布局,开展谋划大规模数字化转型,85%的银行将推进数字化作为重点工作。为参与下一阶段的业务竞争,绝大多数银行都在积极筹备数字化转型。
那么,数字化转型要如何推进,这是不得不面对的问题。只靠加大科技投入,仅仅是将传统业务搬到线上,这种做法显然已经过时了。
在未来,银行需要通过技术手段实现金融的穿透性服务,使金融功能服务于大众生活的各个领域。
02银行业数字化转型面临的挑战
①认知不足,定位失误
不可否认,许多银行对数字化银行已经具备了具体而清晰的认知,能够结合行内业务规划、信息化基础等现状,全方面搭建与自身条件相符的数字化转型道路。
但除此之外,仍有大部分银行对数字化转型的认识,还只有一个模糊的轮廓,只知道大致概念,尚未真正理解。
此类银行出于对数字化转型的认识不足,通常过分追求数字化转型的短期效益,缺乏对长期数字化能力的规划。
②系统老化,支撑不力
当前,既有的银行系统老化而孤立,与全面数字化转型的要求还有相当大的差距。 银行系统的支撑是实现全面数字化转型的前提,而当今的银行业系统却呈现不容乐观的分化现象。
首先是各国有大行,以及领先股份制银行,此类银行的IT建设起步早,IT人才储备充足,基本上已构筑起符合自身需求的IT系统架构。此类银行以对当前现有系统的梳理、建设与优化为导向,并开始探索人工智能平台、云平台、数据中台等先进理念。
而另一方面,因为资金、能力等方面的不足,中小银行的系统建设则基本以零散的业务需求为方向。
因此,体系化的技术架构难以形成,整体先进性不足,再加上技术平台的成本压力,与全面数字化转型的要求差距很大。
03银行业数字化转型的建议
①客户中心,服务导向
无论怎样转型,客户都首先是第一位的,数字化转型,必须依然以客户为中心。
数字化转型的在于利用数字化的技术,重构服务模式,以更便捷、更人性化的方式服务客户。
各大领先银行在手机银行中增设生活服务功能,并将银行服务开放给各类互联网应用,在重构银行的客户服务模式的同时,重塑客户关系了。
②战略布局,落地思路
银行决策者需要对数字化转型具有深刻认识,要重视数据投入和长远布局,不能将眼光囿于业务发展和短期效益。
因此,因此银行管理者要放眼未来,以战略眼光看待数字化转型,掌握未来核心竞争力。同时,银行管理者也需要以落地的思路推进数字化转型的实现,构建保障机制,确保转型规划的稳步实施。
04结语
当前,银行业内部竞争激烈,外部金融企业也纷纷入场。面对如此白热化的局面,银行业未来培育新动能,必须尽快谋划并推进数字化转型。同时,银行也应该坚守其作为核心金融中介的身份,确保金融供给与实体经济需求之间相匹配。
IT运维从传统走向智慧,首先要经历数字化运维阶段,搭建数字运维中台既是实现运维数据有效治理的前提和基础,也是推进运维数智化转型的第一步。针对上述需求,擎创科技自主研发的擎创夏洛克AIOps智慧运营平台(如下图所示)可通过数字运维中台,对运维数据进行统一的采集存储和管理,即便面对高达100TB的日增数据量,也可进行秒级实时分析,为异常检测、根因定位等场景奠定坚实基础。
与传统运维方式相比,智能化运维最突出的优势是“数据大集中”,即基于数字运维中台建设,通过统一监控中心来集中管理和分析所有运维数据,并以业务视角观测运维数据的相关性,最终建立智能化场景来解决实际问题。擎创自主研发的智能运维产品——夏洛克AIOps智慧运营平台,刚好为此量身定制。它能以全局运营视角解读IT运维,在AI算法平台的支撑下实现包括精准告警、异常检测、根因定位和容量分析等场景,助力企业数字化业务高效、稳定和顺畅运行。
目前,夏洛克AIOps已在政府机关组织、银行业、证券保险业和交通运输业等行业场景中应用落地,极大节省了企业客户的人力成本和资金成本,提升了运维的有效性和质量。例如,通过为客户构建智能运维平台,轻松应对日增80TB的数据量,让客户平均故障修复时间(MTTR)缩短150%以上,运维总体拥有成本(TCO)下降80%以上。
关于使用aiops 前提条件和的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。 使用aiops 前提条件的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于、使用aiops 前提条件的信息别忘了在本站进行查找喔。发表评论
暂时没有评论,来抢沙发吧~