AIOps背景/所应具备技术能力分析(上)
本文篇幅较长,分为上,中,下,三个部分进行连载。内容分别为:AIOps 背景/所应具备技术能力分析(上),AIOps 常见的误解(中),挑战及建议(下)。
前言
我大概是 5,6 年前开始接触 ITOA 这个领域的,首次接触后,发现领域有着巨大的潜力,一直寻找在这个领域做点事情的机会。大约三年前在这个领域创业,积极寻求 Product Market Fit。这几年下来,经过与行业内的专家交流,研读报告,阅读论文,客户访谈,亲自动手对相应的运维场景解析,行业产品的试用调研,以及结合着中国运维市场现状,撰写了此文。本人才疏学浅,不学无术,欢迎拍砖。
背景
概念的进化:ITOA -> AIOps -> AIOps
让我们回到2013年,著名的 Buzz word (时髦用语) 制造商 Gartner 在一份报告中提及了 ITOA,当时的定义是,IT 运营分析(IT Operations Analytics), 通过技术与服务手段,采集、存储、展现海量的 IT 运维数据,并进行有效的推理与归纳得出分析结论。
而随着时间推移,在2016年,Gartner 将 ITOA 概念升级为了 AIOps,原本的含义基于算法的 IT 运维(Algorithmic IT Operations),即,平台利用大数据,现代的机器学习技术和其他高级分析技术,通过主动,个性化和动态的洞察力直接或间接地,持续地增强 IT 操作(监控,自动化和服务台)功能。 AIOps 平台可以同时使用多个数据源,多种数据收集方法,实时分析技术,深层分析技术以及展示技术。
随着 AI 在多个领域越来越火爆,Gartner 终于按捺不住了,在它的2017年年中一份报告中,顺应民意将 AIOps 的含义定义为了,Artificial Intelligence for IT Operations, 也就是现在大家都在说的智能运维。
在短短的不到 1 年时间中,伴随着AI的热炒,以及在各个领域的落地,运维界的同仁基本上把 AIOps 看成是未来解决运维问题的必然方向。
个人认为,在企业内部构建 AIOps,通过融合 IT 数据,真正打破数据烟囱,对监控,自动化,服务台进行支持,使得 IT 能够更好的支撑业务,利用大数据技术以及机器学习技术,回答以前很多单从业务口径,或者单从 IT 口径无法回答的问题。如,联通,电信,移动,电信的用户,哪种用户转化率较高。AIOps 以创造商业价值为导向,对 IT 运营以及业务运营产生持续洞察,为 DevOps 提供持续反馈,加快企业在竞争日趋激烈市场环境中,数字化转型的步伐。
因此,Gartner 预测到2022年,大型企业中的的40%将会部署 AIOps 平台。
具体关于 AIOps 的概念,价值,Gartner 很多都已经说的很清楚,不是本文的重点,本文是根据我的理解,尝试从现实的角度,去谈 AIOps 在落地过程中容易产生的误解,挑战以及一些建议。
![微信图片_20180504174021.jpg AIOps背景/所应具备技术能力分析(上) 技术分享 第1张](http://blog.oneapm.com/zb_users/upload/2018/05/201805041525426834131864.jpg)
![图片1.jpg AIOps背景/所应具备技术能力分析(上) 技术分享 第2张](http://blog.oneapm.com/zb_users/upload/2018/06/201806071528356025499777.jpg)
AIOps 所应具备技术能力分析
个人认为,AIOps,本质上是 ITOA 的升级版,让我们来看一下 Garnter 在 2015 年对 ITOA 的所应该有的能力定义。
![图片2.png AIOps背景/所应具备技术能力分析(上) 技术分享 第3张](http://blog.oneapm.com/zb_users/upload/2018/06/201806071528356042138149.png)
-
ML/SPDR: 机器学习/统计模式发现与识别;
-
UTISI: 非结构化文本索引,搜索以及推断;
-
Topological Analysis: 拓扑分析;
-
Multi-dimensional Database Search and Analysis:多维数据库搜索与分析;
-
Complex Operations Event Processing: 复杂运维事件处理;
然后, 我们对比一下,Gartner 对 AIOps 的能力定义
-
Historical data management 历史数据管理;
-
Streaming data management 流数据管理;
-
Log data ingestion 日志数据整合;
-
Wire data ingestion 网络数据整合;
-
Metric data ingestion 指标数据整合;
-
Document text ingestion 文本数据整合;
-
Automated pattern discovery and prediction 自动化模式发现和预测;
-
Anomaly detection 异常检测;
-
Root cause determination 根因分析;
-
On-premises delivery 提供私有化部署;
-
Software as a service 提供 SaaS 服务;
除去最后两个的交付方式,对比下来,我认为 AIOps 比起原来的 ITOA 有以下的进化:
强调历史数据的管理:
允许采集,索引和持续存储日志数据,网络数据,指标以及文档数据,数据大部分是非结构化或者半结构化的,而且数据量累积速度很快,格式多样,非常符合大数据的特征。总所周知,在新一轮以 CNN , RNN 算法为代表的算法中,都需要大量有标准的数据来进行训练,因此, 对历史数据的管理,成了智能运维的第一重点。
强调实时的流数据管理:
以 Kafka Streams,Flink,Storm,Spark Streaming 为代表的流计算处理技术,已经成为了各大数据平台的必备组件,而面对 IT 数据中海量的实时流式数据,某些场景里头,在数据进行持久化前,进行实时分析,查询,集合,处理,降低数据库(SQL or Nosql)的负载,成为了非常合理且常规的选择,因此 AIOps 平台中,含有数据流,非常合理。
强调多种数据源的整合:
我认为,这个是 AIOps 平台最大的价值点,因为 Gartner 第一次将多种数据源整合的能力,带入了 ITOM管理的领域,我们搞运维监控那么多年,终于第一次可以以大数据的视角,数据驱动的视角,去思考运维监控这个传统。
Gartner 这里提及到了四种数据,Log Data, Wire Data, Metirc data,Document text。 这样的分类,我是个人持有保留意见,感觉很奇怪,特别是 Document text 的那块,需要用到 NLP,主要是用于打通 ITSM 产品,分析 ITSM 工单。我对这个场景存在必要性,以及实现的 ROI 表示怀疑。具体原因我可能稍后会写一篇文章,进行更详细的解释。
我认为,如果从宏观的类型来划分,应该这样划分 (下含部分我司产品介绍)
机器数据(Machine Data):是 IT 系统自己产生的数据,包括客户端、服务器、网络设备、安全设备、应用程序、传感器产生的日志,及 SNMP、WMI,监控脚本等时间序列事件数据(含CPU 内存变化的程度),这些数据都带有时间戳。这里要强调, Machine Data 不等于 Log Data ,因为指标数据包含。在通常的业界实践中,这些数据通常通过运行在主机上的一个 Agent 程序,如 LogStash, File beat,Zabbix agent 等获得,如果我们的 LogInsight,Server Insight 产品,就是面向此类型数据。
网络数据(Wire Data):系统之间2~7层网络通信协议的数据,可通过网络端口镜像流量,进行深度包检测 DPI(Deep Packet Inspection)、包头取样 Netflow 等技术分析。一个10Gbps端口一天产生的数据可达100TB,包含的信息非常多,但一些性能、安全、业务分析的数据未必通过网络传输,一些事件的发生也未被触发网络通信,从而无法获得。我司的 Network Insight 主要面向的是这些数据,提供关键应用的 7 x 24 小时全方位视图。
代理数据(Agent Data):是在 .NET、PHP、Java 字节码里插入代理程序,从字节码里统计函数调用、堆栈使用等信息,从而进行代码级别的监控。我司的 Application Insight 主要是解决这个问题而诞生,能获得真正用户体验数据以及应用性能指标。
探针数据(Probe Data):也就是所谓的拨测,是模拟用户请求,对系统进行检测获得的数据,如 ICMP ping、HTTP GET 等,能够从不同地点模拟客户端发起,进行包括网络和服务器的端到端全路径检测,及时发现问题。 我司的 Cloud Test,Cloud Performance Test 主要是产出这些数据的,CT 的产品能从遍布全球的拨测点,对网站的可用性进行全天候的分布式监控。其中我们的 CPT 给你带来从数百到数百万完全弹性的压力测试能力,获得应用在高压力的情况下的性能表现情况。
因为 IT 监控技术发展实在是太庞杂,以上的划分不一定对,但是应该没有显著的遗漏。
但如果从微观技术的角度来看,不考虑数据的来源,只考虑数据本身的属性特点,我们可以这样划分:
指标数据( Metrics Data )
描述具体某个对象某个时间点这个就不用多说了, CPU 百分比等等,指标数据等等
日志数据 ( Logging Data )
描述某个对象的是离散的事情,例如有个应用出错,抛出了 NullPointerExcepction,个人认为 Logging Data 大约等同于 Event Data,所以告警信息在我认为,也是一种 Logging Data。
调用链数据( Tracing Data )
Tracing Data 这词貌似现在还没有一个权威的翻译范式,有人翻译成跟踪数据,有人翻译成调用数据,我尽量用 Tracing 这个词。 Tracing 的特点就是,它在单次请求的范围内,处理信息。 任何的数据、元数据信息都被绑定到系统中的单个事务上。 例如:一次调用远程服务的 RPC 执行过程;一次实际的 SQL 查询语句;一次 HTTP 请求的业务性 ID。 通过对 Tracing 信息进行还原,我们可以得到调用链 Call Chain 调用链,或者是 Call Tree 调用数。
![图片3_副本.png AIOps背景/所应具备技术能力分析(上) 技术分享 第4张](http://blog.oneapm.com/zb_users/upload/2018/06/201806071528356057128489.png)
官方 OpenTracing 中的 Call Tree 例子。
在实践的过程中,很多的日志,都会有流水号,Trace ID, span ID, ChildOf, FollowsFrom 等相关的信息,如果通过技术手段,将其串联在一起,也可以将这些日志视为 Tracing 。
Tracing 信息越来越被重视,因为在一个分布式环境中,进行故障定位,Tracing Data 是必不可少的。
由于 Tracing 相对于 Logging 以及 Metircs 相对比较复杂一点,想深入了解的话,可以参考 :
《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 http://bigbully.github.io/Dapper-translation/
Opentracing 的技术规范文档 https://github.com/opentracing/specification 如果我们将以上数据类型做成一个矩阵看看,我们可以得到这样一个表格,比较好的说清楚了相关关系。
举例就是,我们的 Server Insight 基础监控产品,能采集及处理指标数据,及日志,但是基础监控产品,不会处理 Tracing Data,而我们的 Application Insight 产品能从 JVM 虚拟机中,通过插码,获得应用的响应时间(Metris),Java异常( Logging ),应用间的调用拓扑关系,以及调用的响应时间(Tracing)。
![图片4_副本.png AIOps背景/所应具备技术能力分析(上) 技术分享 第5张](http://blog.oneapm.com/zb_users/upload/2018/06/201806071528356089305922.png)
![图片5.png AIOps背景/所应具备技术能力分析(上) 技术分享 第6张](http://blog.oneapm.com/zb_users/upload/2018/06/201806071528356101689569.png)
回到 Garnert 的 AIOps 能力定义, 居然没有把 Tracing Data 纳入到数据整合的范围之中,个人认为不太合理,因为要去做根因分析,如果不知道服务和指标之间的关联关系,其实是比较难做到故障的根本定位的。
算法部分
其实可以看到,Gartner 在 ITOA 定义的算法部分,如模式发现,机器学习等技术定义,都被比较顺滑的过渡到 AIOPS 中来,一个方面可以看出 Gartner 在定义 ITOA 的时候有足够的前瞻性,另外一个方面可以看到,相关的算法问题,解决及演进的速度,是相对于基础大数据架构相对要慢上不少。
小结
AIOPS 概念与 ITOA 概念相比,在大数据技术部分进行了更细,更有指导性的阐述,所以我认为,AIOps 首先是大数据,然后才是算法。
OneAPM 全新推出新一代 AIOps 平台 I2,欢迎您随时联系我们,即刻开启贵公司的智能运维之旅。点击进入 AIOps 官网了解更多信息。
来源:http://blog.oneapm.com/apm-tech/815.html