精简版
0
0
0
云栖社区>阿里云存储服务> 博客>正文
成喆 2019-12-31 00:34:51 浏览 24
大数据
算法
监控
性能
日志
日志服务
工单
Image
devOps
数据采集
- ELK
- grafana
- prometheus
- aiops
- TICK
展开阅读全文
本文介绍我在 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
来源: https://yq.aliyun.com/articles/741219