开源AIOps数据中台搭建,搭建开源镜像站


引言

本文介绍我在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个核心指标/目的:
image

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运维实现其目标(例如发现、预测、修复问题)。
image

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

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

1. 大数据促进平台融合

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

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

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

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

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

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

增强描述性

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

增强排错

  • 自动识别数据模式(例如日志模型),自动识别关键实体并关联事件。

增强预测能力

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

增强辅助根因分析

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

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

二. 工程难点

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

基本架构

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

image

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

image

自上而下的划分,可以看到如下子系统:

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

数据采集

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

1. 数据的摄取挑战

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

image

2. 数据类型比较

各种类型的数据之间也有各自的特点,如下:
image

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

另一方面,数据之间也有一定的重叠(数据量仅供参考):
image

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

数据中台的处理

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

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

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

2. 各种分析的⽀支持

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

3. 数据治理的支持

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

机器学习的挑战

如前述,机器学习具体在如下几个场景发挥作用:
image

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

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

外部数据集成与自动化

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

三. 开源方案选择

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

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

1. 数据源与监控

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

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

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

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

image

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

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

3. Prometheus栈方案

3.1 指标类数据监控 - Prometheus

Prometheus作为K8S监控标配(继K8S后第2个CNCF项⽬目),其有如下特点:

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

image

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

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

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

image

3.3 Prometheus的扩展 - Thanos

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

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

image

4. Open Telemetry方案

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

Open Telemetry - SkyWalking

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

image

5. TICK栈方案

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

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

image

6. Elastic栈方案

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

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

image

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

image

6.1 Elasticsearch核⼼能⼒

作为Elastic核心数据库,Elasticsearch具有如下特点:

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

image

但其缺点也较为明显:

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

6.2 Kibana核⼼能⼒

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

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

image

6.3 Logstash核⼼能⼒

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

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

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

image

6.4 Beats核⼼能⼒

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

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

image

7. 其他OLAP选择

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

7.1 Druid

Druid作为Apache项目,有如下特点:

  • 性能优越:

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

image

7.2 ClickHouse

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

  • 性能优越:

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

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

image

8. AI与自动化

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

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

image

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

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

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

image

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

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

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

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

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

如下是一些方案样例:

image

8.3 AI增强 - 预测

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

image

8.4 AI增强 - 根因分析

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

image

四. 结语

开源⽅案选择策略

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

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

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

image

2. 开源 ≠免费

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

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

需要结合团队、技术需求、⽅案选择做细致评估。商业软件或SaaS方案(简化Ops平台⾃自身运维成本,例如和通数据库日志服务)也可作为选项。

其他

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

相关内容