引言

本文介绍我在PyCon2019上海站的议题内容，结尾有PPT下载链接。
根据Gartner的报告，AIOps将在未来5-10年落地开花，并集中统一各种Ops平台（Dev、IT、Net、Sec），本议题介绍AIOps的核心作用、相关工程难点（数据采集、数据中台、智能算法、自动化等）与开源方案选择，适当介绍了Python在其中的主要作用，覆盖开源方案有：Kafka、Elastic Stack (Beats， Elasticsearch，Kibana)、K8S、Prometheus、Grafana、Thanos, Tick stack (Telegraf，InfluxDB，Chronograf，Kapacitor)、Ansible、OpenTelemetry、Skywalking、Druid、Clickhouse等。

一. 关于AIOps

IT运维目标

AIOps并不是蹭热点，而是以实实在在解决IT运维的痛点或提高效率为目标。一直以来IT运维存在以下3个核心指标/目的：

1. MTTR的降低

MTTR（Mean Time To Repair）平均修复时间，是一个衡量系统宕机时间的指标，IT运维人员以降低此目标为第一要务，越低越好。

2. Cost的降低

公司每年需要在IT上投入很多钱，包括硬件、软件、服务、人员等，通过IT运维希望将资源效率提高到最高，形成持续的成本优化。另一方面，宕机也会带来业务损失（例如电商一时不能用，客户就无法下单），因此此指标也与MTTR和SL相关，MTTR越长，SL越低，成本也越高。

3. Service Level的提高

SLA表示客户与服务商之间服务可用性的承诺，一般以服务可用性用时长为维度，例如99.99%可用，表示一个周期（例如一个月）宕机的总体时间不超过0.01% * 365天 < 4.5分钟。有时也表示API错误率占比。

IT运维挑战

但是IT运维所面临的挑战也呈现越来越高的趋势，大概分成两类原因：

1. IT系统复杂度越来越⾼

目标系统越来越复杂，快速定位问题难度越来越高，具体细分为：架构演变复杂化和数据孤岛越来越多。

架构演变复杂化
随着云计算的普及，许多公司存在云上、云下业务，甚至多云策略（海外业务用AWS，亚太用阿里云）；SaaS的普及（这点在海外非常普遍），容器化与微服务架构的流行，使得一套系统的部署非常复杂。某一个环节出错，可能落点也都有可能。

数据孤岛越来越多
各种数据存储于各个系统之中，在大数据下呈现4V特点（容量Volume、速度Velocity、种类Variety和价值Value），很难集中采集与处理，一旦发生问题，很难有效检查具体数据信息。

2. IT系统成本越来越⾼

祸不单行，修复的IT问题的成本也越来越高，具体细分为三类原因：

业务中断成本
信息化越来越发达的今天，一些流行产品动辄上亿PV、千万UV。例如一些电商、服务系统，一旦临时不可用，造成的损失就是客户无法下单、转投竞品处购买，设想一下，双十一当天每秒的交易额可知成本之高，对于金融、公共服务类的系统，则会造成更大的损失也有可能，基本都会成为新闻报道。

缺少持续改进
另一方面，普遍存在的现象是运维人员的日常工作大部分时间都在忙于救⽕，自然缺少持续改进的时间和机会，包括工程流程上梳理漏洞，编写引入自动化工具，客户培训等

学习速度跟不上
这里特别强调这点，是因为其实人始终是一个非常重要的原因，业务增长的速度往往超乎人的想象（参考风口论），某个业务在一年内提高5倍、10倍甚至100倍都是有可能的，但人的学习成长速度往往很难匹配上。

AIOps基本概念

虽然Ops的概念很宽泛，但一般AIOps表示Artificial Intelligence for IT Operations，可以理解为组合了大数据、机器学习、分析来帮助IT运维实现其目标（例如发现、预测、修复问题）。

而Gartner报告中的一张图可以更具体的解释AIOps对IT运维的改进：

• 通过历史、实时流式数据的导入，结合大数据+机器学习在IT运维的三个方面（检测、管理、自动化）中的4类场景（历史分析、异常检测、性能分析、关联与上下文等）进行增强。
  

1. 大数据促进平台融合

可以看到AIOps平台要求采集各种数据（包括日志、指标、网络数据、API、文本、社会媒体信息等），用于分析、训练API、关联分析等以达到效果。

如前述IT运维挑战所说，完整、实时地采集以上数据是很不容易，且这类数据又被各种角色的人所关心，包括不限于：

• IT运维人员
• 开发人员
• 数据工程师
• 安全运维人员
• 合规审计人员
• 商务分析师
• 相关管理者、决策者

因此Gartner认为AIOps会从功能（Feature）演逐渐变成平台并落地，且预测到2022年年，40%企业会使⽤用AIOps。

2. 机器学习促进ITOps的主要方式

机器智能主要在如下4个场景下帮助ITOps完成目标：

增强描述性

• 通过算法、可视化与统计分析等方式，对海量数据（例如日志、告警）进行降噪、去重，增强其描述性。

增强排错

• 自动识别数据模式（例如日志模型），自动识别关键实体并关联事件。

增强预测能力

• 使用经典算法，基于模式预测。

增强辅助根因分析

• 通过关联、知识图谱获得可能原因。

总而言之，AIOps的最终目标时促进IT运维的目标达成，逐步释放IT运维人员的效率束缚，理想的未来，甚至被认为是服务Level-0（第一道关）的存在：

二. 工程难点

以下将AIOps系统拆解，并逐个从数据采集、数据中台、智能算法、自动化等角度分析其工程难点。

基本架构

简单描述，一个典型的AIOps的系统可以划分为如下层次：

更进一步，借鉴热门AIOps创业公司Moogsoft的一张图：

自上而下的划分，可以看到如下子系统：

• 场景应⽤：基于AIOps的通用性，场景不仅可以是运维、也可以是审计、DevOps、商务分析等。
• 智能监测系统：AIOps引擎，处理大数据并使用AI、分析从4个方面增强IT运维。
• 自动化系统：自动处理工单、协同沟通、定位问题的编排系统，自动治愈修复也在其中。
• 工单知识库：工单系统是重要的输入源，也是历史类似问题处理的知识库。
• 数据湖：不同于传统数据库或数据仓库，这里是一个无结构模型依赖、实时提供服务的数据湖。
• 监控生态系统：各类监控类系统，输出的数据，也包括告警。
• 数据源： 底层各种数据源系统，被监控的系统都在这里，例如主机、服务、云平台等。

数据采集

没有大数据，AIOps就如巧妇难为无米之炊，实时、有效、完整地数据采集是AIOps的基础前提。

1. 数据的摄取挑战

如前面IT运维的挑战类似，数据采集是很困难的，随着技术架构的演变，数据有3V（（大容量、常变化、高速增长））的特点、以各种格式（Log、Tracking、Event；Metrics、IoT data；⽹网络数据）存在于各种来源（ SaaS、多云、容器器、微服务、主机、应⽤用等）中。

2. 数据类型比较

各种类型的数据之间也有各自的特点，如下：

可见Tracking数据价值大，但采集难度较大；日志类的价值普遍更高；指标类数据简单，但数据量也可能非常大（IoT场景下）；文本内的价值能力最大，但加工难度最大。

另一方面，数据之间也有一定的重叠（数据量仅供参考）：

某种程度上，在一些产品中，tracking、指标类数据被认为是一种结构化的日志。

数据中台的处理

没有数据中台，AIOps如空中楼阁，我们看下数据中台具体是什么，又要做什么：

1. 海量多样数据的存储/索引

数据中台要能够有效存储和索引各类数据（时序指标数据、⽂文本数据、⽇日志、⽹网络数据、Tracking等）。这里有效指的是，针对前述数据类型的特点，有针对性的提高存储、检索效率（例如时序数据的索引与日志类的索引是有所不同的）。

2. 各种分析的⽀支持

还需要支持流式（或微批实时）分析处理，例如实时统计PV或异常告警。另一方面，也需要支持多维度的实时关联统计与分析，且支持交互式add-hoc方式。

3. 数据治理的支持

数据治理的能力也很重要，包括如下两个方面，
数据加⼯：支持通⽤数据模型，且支持对多维机器数据、半结构化数据进行灵活的规整或与各种第三⽅数据关联（富化）等。
数据⽣命周期管理：随时间流式，更老的数据需要降维、聚集或归档等，需要有这方面的支持。

机器学习的挑战

如前述，机器学习具体在如下几个场景发挥作用：

但算法落地面对一些直接的挑战：

• 数据不全，质量量欠佳：数据不全将导致算法模型变形，例如只用小猫图片训练，算法永远无法知道老虎长什么样。好在越来越多的团队意识到数据全面性的价值。
• 团队缺少懂的⼈：算法有一定的数学门槛，但这方面的专业懂的人才相对还是少一些。好在高薪的岗位吸引着越来越多的新鲜血液进入这个领域。
• ⼯具不好⽤：算法工具目前越来越易用，不需要是计算机博士就可以做AI工作，但依然存在一定门槛。
• 工程化不易：目前AI被吐槽的地方就是难的推理结论不准，简单的推理结论显然。

外部数据集成与自动化

AIOps的最后一块重要系统是外部数据集成与自动化，这也是为什么一些大厂逐步在补齐方面的短板。这部分主要包括工单系统、CMDB（资产管理）的集成；Run Book自动化、告警与应用的编排能力。

三. 开源方案选择

这里介绍一些特定场景下特定的平台搭建的开源选择及策略：

• 日志类数据⽅方案
• 指标类时序数据⽅方案
• 其他OLAP选择
• AI增强⽅方案

1. 数据源与监控

这里以容器化架构为例，自下而上可以看到多个层次的开源方案选择。

• 底层物理虚拟机层的监控由传统优势方案占主导，例如Zabbix、statsd、collectd、Nagios、fluentd等。
• 往上的容器类监控是Prometheus + Grafana + Thanos的领地。
• 上层应用的性能、日志类监控的选择是Elastic栈、TICK栈和Open Telemetry类方案。

2. 监控⽅案作为中台的能力比较

这里选择上面三类监控方案作为中台进行能力比较，维度参考前述挑战中的方面：

其中Prometheus和Tick方案对于指标类支持很好，而Elastic对于日志类支持更好。但流式分析方面，Prometheus和Elastic方案并无直接支持。而统计关联分析方面，Elastic较强，其他一般。在数据治理方面的支持，三个方面也都差强人意。总体而言，一个结论是：没有银弹。

以下大致介绍下相关方案的特点与优缺点。

3. Prometheus栈方案

3.1 指标类数据监控 - Prometheus

Prometheus作为K8S监控标配（继K8S后第2个CNCF项⽬目），其有如下特点：

• 多维数据模型 + PromQL。
• 汇总性数据+Label过滤。
• 可从160+源渠道提取指标数据。
• 主动拉去模式（可由gateway被动）。
• 自动发现。
• 主要用于短期指标。
• 支持20+外部存储用于长期存储。

3.2 通⽤用指标类可视化 - Grafana

作为通⽤型指标类可视化⽅案，Grafana已然是Phrometheus的连体婴儿了，其有如下特点：

• 近70数据源（支持混合）。
• 新推简单⽇志方案：Promtail+Loki，目前还非常初级。
• ⾃由报表定制与构建。
• 30+ 可视化插件。
• ⽀持查询原始指标。

3.3 Prometheus的扩展 - Thanos

试图解决Prometheus的几个核心问题而生的方案，其有如下特点：

• 全兼容Prometheus，提供全局视图+HA。
• 扩展⾼可用。
• Sidecar + Query节点。
• ⻓时间备份与归档。
• 压缩与下采样（Down Sampling）。

4. Open Telemetry方案

是目前CNCF蓝图下统⼀Metric、Tracking的新标准（统一了Open Tracing和Open Census），目前还处于开发阶段，其主要是客户端标准。

Open Telemetry - SkyWalking

SkyWalking作为国内流行Tracking方案，已经是Apache孵化项目，其有如下特点：
• 性能影响较小(<10%)
• Cloud Native容器化⽀持好
• 支持存储到ES/TiDB、MySQL等

5. TICK栈方案

作为InfluxDB家的全家桶，其表示Telegraf + InfluxDB + Chronograf + Kapacitor。此方案具备如下一些特点：

• InfluxDB：⾼性能的时序数据库。与ElasticSearch比较报告号称有8X写⼊速度，少4X磁盘占用，以及3~7X响应速度。
• Telegraf：数据采集客户端，支持200+数据渠道。
• Chronograf：可视化方案，其没有Grafana强⼤和灵活。
• 此方案一个缺点是开源免费版本缺少集群、安全、管理等功能。

6. Elastic栈方案

作为Elastic家的全家桶，在日志与文本领域非常流行，常用BELK表示，意为Beats + Elasticsearch + Logstash + Kibana。此方案有如下特点：

• 接⼊层通常还会搭配Kafka使用。
• 重要企业级组件都在商业组件X-Pack中，包括安全、机器学习、SQL、监控、告警、Transform等
• 其附带了⼀个简单的开源免费的APM方案。

典型Elasticsearch部署方式是搭配Kafka使用，并在整个接入过程中使用Logstash（或Ingest Node）完成数据的转换（ETL），引⼊队列，主要是解决丢数据问题，但相应的部署、维护复杂度也较为复杂。

6.1 Elasticsearch核⼼能⼒

作为Elastic核心数据库，Elasticsearch具有如下特点：

• 简单、易扩展、功能集丰富、生态活跃。
• NoSQL、schema灵活。
• 全文索引查询强、过滤快、聚集功能强⼤。
• 不支持外部关联，有SQL适配器器（有限支持）。

但其缺点也较为明显：

• 企业特性需要商业License（x-pack）。
• 内存管理理挑战较大，复杂类统计DSL易失控。
• 超过百TB规模后运维成本⾼（非线性增长）。
• 存储压缩效率偏低。

6.2 Kibana核⼼能⼒

Kibana作为Elastic专属可视化方案，近几年迭代很快，其具有如下特点：

• 支持交互式查询控制台、类tail-f功能。
• 支持完整报表中⼼与交互功能。
• 提供⾼级图表功能：地图、关系图等。
• 支持时序数据。
• 支持机器学习（收费）。
• 提供Canvas⾃由编辑能力（支持暗黑主题，但挂接数据方式有限）。

6.3 Logstash核⼼能⼒

作为ELK的主要接入与数据治理核心组件，Logstash具备如下特点：

• 插件化灵活：输⼊入/过滤/输出
• 200+插件
• 配置统⼀一管理理
• 数据传输可靠性

但其缺点也较为明显：占用资源较大，性能较差。

6.4 Beats核⼼能⼒

为解决Logstash的性能问题，引入了Beats，提供8类轻量级Beats，具备如下特点：

• 配置统⼀管理，部分逻辑插件化
• 集成50+内置⽣态模块（⽇志与指标）
• ⽀持容器类部署场景

7. 其他OLAP选择

除了前述三种主要开源监控类方案外，这里也介绍一下其他部分流行OLAP的开源方案作为中台选择参考。

7.1 Druid

Druid作为Apache项目，有如下特点：

• 性能优越：

  • PB级别规模。
  • 亚秒级OLAP系统。
  • 实时写入与查询。
• 组件⻆色较多，搭建较为复杂。
• Json-QL（有SQL适配器器）。
• 不⽀持外Join、窗口等。

7.2 ClickHouse

作为新起之秀，ClickHouse以其独门武功的卓越性能吸引了一大批用户，其具有如下特点：

• 性能优越：

  • 10亿+条规模⽐比商业软件快5倍
  • ⽐比MySQL快⼏几百倍
• 稳定可靠，⾮非Hadoop体系，
• 类SQL功能

• 缺点：

  • 聚合结果要在⼀一台机器器内存内
  • 缺少完整更更新删除操作
  • ⽀支持操作系统有限

8. AI与自动化

关于AI方面以Python框架为主，而自动化方面选择较多，这里也列举一些Python的方案如下：

• 数据治理：Python ETL、PySpark、Flink/Blink-Python
• 机器学习：Airflow（编排）+ 如下机器学习框架
• 自动化：Ansible、Puppet等

以下列举一下具体的AI算法在场景下应用实例：

8.1 AI增强 - 降噪去重与模式识别

这里主要体现在机器数据的聚类（模式识别），例如对海量日志进行模式聚类（从65万条日志，聚类出50条日志模式），以下是一些方案样例：

8.2 AI增强 - 异常值（Outlier)与异常识别（Anomaly）

传统Ops平台普遍存在告警疲劳，因为传统基于阈值方式的告警并不能很好解决问题：

• 阈值难以合理，例如CPU高于90%在某些情况下合理，某些又不正常。
• 基于经验的有效阈值会⾮常复杂：例如外网非工作时间频繁登录失败是异常，但公司内工作时间相对容忍度较高。
• 有效阈值维护成本较⾼：经常因情况变化要调整。
• 过滤后的告警数量依然较多。

比较好的方法策略是以历史数据作为基准，对周期性或断层数据异常进⾏识别：

• 使⽤基于统计的动态阈值。
• 使⽤模式识别正常行为与异常行为。

如下是一些方案样例：

8.3 AI增强 - 预测

对周期性趋势性数据进行预测，一些方案样例：

8.4 AI增强 - 根因分析

关联事件上下⽂文与相关链路路指标，提供根因辅助，一些方案样例：

四. 结语

开源⽅案选择策略

使用开源方案时需要考虑几点：

1. 没有银弹，没有one for all

没有一套方案完美解决所有问题，需要权衡选择合适的方案组合，但也不要万花筒。

2. 开源 ≠免费

开源的东西不等于免费，因为如下几点原因：

• 学习、迁移、维护升级、稳定性、License、潜在坑（例如这个长长的breaking change清单）等。
• 某些开源软件的重要扩展是需要额外费用的（例如InfluxDB的集群功能）。

需要结合团队、技术需求、⽅案选择做细致评估。商业软件或SaaS方案（简化Ops平台⾃自身运维成本，例如阿里云日志服务）也可作为选项。

其他

PPT下载: https://github.com/wjo1212/ChinaPyCon2019
另外，我们一直在提供并发展云上AISecDevOps平台，欢迎扫群加入日志服务技术交流钉钉群, 获得第一手资料与支持：