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

2020-03-01 225浏览

  • 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：⾼高性能的时序数据库。 • vsES: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 ⽇日志服务钉钉群