1 丁来强 开源AIOps数据中台搭建与Python的作用

CodeWarrior

2019/10/11 发布于 技术 分类

文字内容
1. 开源AIOps数据中台搭建与 Python的作⽤用 丁来强
2. 关于我 • ⼯工作10+年年,熟悉⼤大数据分析、ITOps、SecOps等领域 • 阿⾥里里云⽇日志服务上海海负责⼈人,之前在Splunk上海海 • ⾃自从2015年年,在4届PyCon上,累计分享7+不不同议题 • 云栖⼤大会或社区累计分享13+个⼤大数据系统或Python相关议题 ⽇日志服务钉钉群 往届视频与PPT
3. ⽬目录 CONTENTS 关于AIOps ⼯工程难点 开源⽅方案与Python作⽤用
4. 1 关于AIOps 根据Gartner的报告,AIOps将在未来5-10年年落地开花,并集中统⼀一 各种Ops平台
5. IT运维的⽬目标/KPI 1 2 3
6. IT运维的挑战 • 复杂度越来越⾼高: • 架构演变:SaaS、多云、容器器、微服务等 • 数据孤岛越来越多:⼤大数据的3V(容量量、变化、种类) • 成本越来越⾼高: • 业务中断成本 • 缺少持续改进(运维⼈人员⼤大部分时间忙于救⽕火) • ⼈人员学习速度跟不不上业务增⻓长和问题出现的速度
7. 基本概念 • AIOps = Artificial Intelligence for IT Operations • 组合⼤大数据 + 机器器学习 + 分析来帮助IT运维: • 发现、预测、修复问题 ⼤大数据 机器器学习 分析
8. Garner:AIOps对IT运维的改进
9. ⼤大数据促进平台融合 • 采集各种数据(以下各种⻆角⾊色都关⼼心): • IT运维⼈人员、开发⼈人员、数据⼯工程师、 • 安全运维、合规审计⼈人员、商务分析师 • Garner预测未来5年年: • AIOps会从功能演变成平台并落地 • 到2022年年,40%企业会使⽤用AIOps
10. 机器器学习促进ITOps的主要⽅方式 ⾃自动模式识别 通过关联、知识图谱获 得可能原因 事件关联 增强排错 diagnostic 增强描述性 descriptive 降噪、去重 可视化与统计分析 辅助根因分析 root cause analysis 增加预测能⼒力力 proactive capabilities 基于模式的预测
11. AIOps增强分析与⾏行行动能⼒力力,挡住更更多⼯工单
12. 2 ⼯工程难点 数据采集、数据中台、智能算法、⾃自动化等
13. AIOps系统(常规层次)
14. AIOps系统架构 • 场景应⽤用 • 智能监测系统 • ⾃自动化系统 • ⼯工单知识库 • 数据湖 • 监控⽣生态系统 • 数据源
15. 数据的摄取挑战 • 各种来源: • SaaS、多云、容器器、微服务、主机、应⽤用等 • 各种数据样式: • Log、Tracking、Event;Metrics、IoT data;⽹网络数据; • ⽂文本、⼯工单、知识库;API;代码等 • ⼤大数据的3V(容量量、变化、种类)
16. 数据类型⽐比较 数据类型与⽐比较 ⽇日志 Tracking 指标 ⽂文本 数据格式 ⾮非结构化 半结构化,数据关联 结构化(聚集) ⾮非结构化 数据量量 ⼤大 较⼤大 ⼀一般到极⼤大(IoT) ⼀一般 单条⼤大⼩小 100~10KB 100~10KB < 500 100~10KB 采集难度 ⼀一般 较难 ⼀一般 ⼀一般 加⼯工难度 较难 ⼀一般 简单 较难 价值 ⾼高(尤其安全) ⾼高 随着时间推移变低 ⽐比较⾼高
17. 数据之间的重叠
18. 数据中台的处理理 • 海海量量多样数据的存储/索引: • 时序指标数据、⽂文本数据、⽇日志、⽹网络数据、Tracking等 • 各种分析的⽀支持: • 流式分析:流式或微批实时处理理 • 统计关联分析:多维度的实时关联统计与分析⽀支持,⽀支持交互式add-hoc⽅方式 • 数据治理理: • 数据加⼯工:通⽤用数据模型;多维机器器数据、半结构化的规整、各种第三⽅方数据关联 • 数据⽣生命周期管理理(时序数据的归并、变化数据更更新等)
19. 机器器学习对分析增强的⽅方向 增强点 统计性分析 描述 基于IT实体与数据,在单维、多维变量量上的关联、聚类、分类和推断。 ⾃自动模式发现与预测 基于历史数据⾃自动探索出数学与结构化模式,并⽤用于各种可能维度的预测。 异常检测 基于模式识别正常⾏行行为与异常⾏行行为。 根因判断 修剪⽹网络并提供有效问题的关系链接。 规范性建议 拓拓扑 对问题进⾏行行分类,并基于过去⽅方案提供有效建议。 提供拓拓扑能⼒力力强化上下⽂文与前述的准确度
20. 算法落地的直接挑战 • 数据不不全,质量量⽋欠佳 • 团队缺少懂的⼈人 • ⼯工具不不好⽤用 • ⼯工程化不不易易
21. 算法落地的趋势 • ⾼高薪机会让更更多⼈人⼈人员会进去这个领域 • 框架使得学习⻔门槛降低:不不需要博⼠士就能做 • 公司培训与⼈人员参与促进发展
22. 外部数据集成与⾃自动化 • ⼯工单系统 • CMDB(资产管理理) • Run Book⾃自动化 • 告警 • 应⽤用编排
23. 3 开源⽅方案选择与Python作⽤用 特定场景下特定的平台搭建选择及策略略以及Python的作⽤用 • ⽇日志类数据⽅方案 • 指标类时序数据⽅方案 • 其他OLAP选择 • AI增强⽅方案
24. 数据源与监控 - 容器器化架构为例例 应⽤用层 ⽇日志 指标监控 elastic stack, TICK stack, Open Telemetry 应⽤用层性能监控 容器器CaaS层资源监控 prometheus + grafana + thanos 容器器POD指标监控 物理理主机/VM层监控 Zabbix, statsd, collectd Nagios, fluentd
25. ⼏几个监控⽅方案作为中台的能⼒力力⽐比较 ⽅方案⽐比较 摄取 存储 分析 数据 治理理 Prometheus Stack Elastic Stask TICK Stack ⽀支持 初级 ⽆无 ⽆无 ⽀支持(效率⼀一般) 较好 全⾯面 不不⽀支持 ⽀支持 ⽆无 ⽆无 ⽀支持 统计关联 ⼀一般(DSL等) 查询统计强,关联弱 (商业版可部分转SQL) ⼀一般(类SQL查询统计等) 数据加⼯工 ⽆无 ⽀支持(logstash/reindex) ⽀支持(CQ/TickScript) ⽣生命周期 不不直接⽀支持 ⽀支持 不不直接⽀支持 指标 ⽇日志 ⽂文本 流式
26. 指标类数据监控 - prometheus • K8S监控标配(继K8S后第2个CNCF项⽬目) • 多维数据模型 + PromQL • 汇总性数据+Label过滤 • 可从160+源渠道提取指标数据 • 主动拉去模式(可由gateway被动) • ⾃自动发现 • 主要⽤用于短期指标 • ⽀支持20+外部存储⽤用于⻓长期存储
27. 通⽤用指标类可视化 - grafana • 通⽤用的指标类可视化⽅方案 • 近70 数据源(⽀支持混合) • 新推简单⽇日志⽅方案:Promtail+Loki • ⾃自由报表定制与构建 • 30+ 可视化插件 • ⽀支持查询原始指标
28. prometheus的扩展 - thanos • 全兼容Prometheus,提供全局视图+HA • 扩展⾼高可⽤用 • Sidecar + Query节点 • ⻓长时间备份与归档 • 压缩与下采样(DownSampling)
29. Open Telemetry • CNCF统⼀一Metric、Tracking的新标准 • ⽬目前开发阶段 + =
30. Open Telemetry - SkyWalking • Apache孵化阶段 • 国内⽤用的⽐比较多 • 性能影响较⼩小(<10%) • Cloud Native容器器化⽀支持好 • ⽀支持存储到ES/TiDB、 MySQL等
31. InfluxData stack (TICK) • Telegraf + InfluxDB + Chronograf + Kapacitor • InfluxDB:⾼高性能的时序数据库。 • vs ES: 8X写⼊入,少4X磁盘占⽤用,3~7响应速度 • Telegraf:⽀支持200+数据渠道 • 开源免费版本缺少集群、安全、管理理等功能 • Chronograf:不不如Grafana强⼤大灵活
32. Elastic Stack (BELK) • Beats + Elasticsearch + Logstash + Kibana • 接⼊入层还会搭配Kafka • 重要企业级组件都在商业组件X-Pack中 • 安全、ML、SQL、监控、告警、Transform等 • 提供⼀一个开源免费的APM⽅方案
33. Kafka + EBLK 引⼊队列,解决丢数据问题 部署、维护复杂度较为复杂
34. Elasticsearch核⼼能⼒ • 简单,易易扩展,功能集丰富,⽣生态活跃 • NoSQL,schema灵活 • 全⽂文索引查询强,过滤快、聚集功能强⼤大 • 不不⽀支持外部关联,有SQL适配器器 • 缺点: • 企业特性需要商业License • 内存管理理挑战较⼤大,复杂统计易易失控 • 超过百TB规模后运维成本⾼高 • 存储压缩效率偏低
35. Kibana核⼼能⼒ • 交互式查询控制台、tail-f • 完整报表中⼼与交互功能 • ⾼级图表功能:地图、关系图 • 时序数据 • 机器学习(收费) • Canvas⾃由编辑
36. Logstash核⼼能⼒ • 插件化灵活:输⼊入/过滤/输出 • 200+插件 • 配置统⼀一管理理 • 数据传输可靠性
37. Beats核⼼能⼒ • 8类轻量级Beats • 配置统⼀管理,部分逻辑插件化 • 集成50+内置⽣态模块(⽇志与指标) • ⽀持容器类部署场景
38. 其他OLAP选择: Druid • 性能优越: • PB级别规模 • 亚秒级OLAP系统 • 实时写⼊入与查询 • 组件⻆角⾊色较多,搭建较为复杂 • Json-QL(有SQL适配器器) • 不不⽀支持外Join、窗⼝口等
39. 其他OLAP选择: Clickhouse • 性能优越: • 10亿+条规模⽐比商业软件快5倍 • ⽐比MySQL快⼏几百倍 • 稳定可靠,⾮非Hadoop体系, • 类SQL功能 • 缺点: • 聚合结果要在⼀一台机器器内存内 • 缺少完整更更新删除操作 • ⽀支持操作系统有限
40. ⼤大数据⽅方案开源全景图(部分)与Python作⽤用 • 数据治理理:Python ETL、PySpark、Flink/Blink-Python • 机器器学习:Airflow(编排)+ 如下机器器学习框架 • ⾃自动化:Ansible、Puppet等 •
41. AI增强 - 降噪去重与模式识别 • 对海海量量⽇日志进⾏行行模式聚类(例例如从65万条⽇日志,聚类出50条⽇日志模式) 阿⾥里里云⽇日志服务 Sumologic Splunk
42. 消除告警疲劳 • 传统阈值⽅方式的告警并不不能解决问题: • 阈值难以合理理,或会⾮非常复杂 • 有效阈值维护成本较⾼高 • 过滤后的告警数量量依然较多 • 使⽤用基于统计的动态阈值 • 使⽤用模式识别正常⾏行行为与异常⾏行行为。
43. AI增强 - 异常值(Outlier)与异常识别(Anomaly) • 以历史数据作为基准,对周期性或断层数据异常进⾏行行识别 阿⾥里里云⽇日志服务 ElasticSearch ML (X-Pack) Splunk
44. AI增强 - 预测 • 对周期性趋势性数据进⾏行行预测 阿⾥里里云⽇日志服务 ElasticSearch ML (X-Pack) Splunk
45. AI增强 - 根因分析 • 关联事件上下⽂文与相关链路路指标,提供根因辅助 阿⾥里里云⽇日志服务 ElasticSearch ML (X-Pack) Splunk
46. 使⽤用开源⽅方案时需要考虑 • 没有银弹,没有one for all • 选择合适的⽅方案组合,但也不不要万花筒。 • 开源 不不等于 免费 • 学习、迁移、维护升级、稳定性、License、潜在坑等 • 某些开源软件的重要扩展是需要额外费⽤用的。 • 结合团队、技术需求、⽅方案选择做细致评估。 • 商业软件或SaaS⽅方案(简化Ops平台⾃自身运维成本)也可作为选 项。
47. 推⾏行行策略略 • 不不要⼀一步到位 • 从历史数据开始 • 持续改进 • 选择合适平台 • 可以摄取各种数据尤其⽂文本、log、与指标数据 • 提供历史与当前视⻆角 • 选择合适⼯工具 • ⽀支持模式识别、异常检测、预测、根因分析扩展的⽅方案
48. THANK YOU 本⼈人微信 Github下载PPT ⽇日志服务钉钉群