云原生时代如何实现真正的业务可观测
如果无法正常显示,请先停止浏览器的去广告插件。
1. 云原生时代如何实现真正的业务可观测
华 明
2.
3. 个人简介
• 2009年起先后任职百度运维部、滴滴运维部。
• 做过一线运维也带过研发团队。曾负责大型服务的运维(百度广告系统、团购系统等)、完成滴
滴的运维体系建设,打造了滴滴云原生平台,成为国内推进云原生最快的几家公司之一。
• 2021年10月联合创立北京快猫星云科技有限公司,致力于通过产品赋能千万数字化企业的服务稳
定性保障。
• 2022年9月成为TGO鲲鹏会北京会员。
4. 内容大纲
01 监控和可观测性的关系及渊源
02 当前阶段落地可观测性的挑战在哪里
03 落地好一个可观测系统的三大要素
04 面向故障处理过程的可观测性体系建设案例
05 思考:人工智能2.0对可观测性技术和产品演进的影响
5. 内容大纲
01 监控和可观测性的关系及渊源
02 当前阶段落地可观测性的挑战在哪里
03 落地好一个可观测系统的三大要素
04 面向故障处理过程的可观测性体系建设案例
05 思考:人工智能2.0对可观测性技术和产品演进的影响
6. 什么是可观测性
可观测性(Observability)是来自控制论的一个概念
In control theory, observability is a measure for how well internal states of a system can be inferred by knowledge of its external
outputs. The observability and controllability of a system are mathematical duals. The concept ofobservability was introduced by
American-Hungarian scientist Rudolf E. Kalmanfor linear dynamic systems.
简单来看,如果仅使用来自系统输出的信息可以估计当前状态,则系统被认为是“可观测的”。
我理解的可观测性
让服务任何时候都可以被观测,且观测效果可持续的规范、标准、方法、工具和平台的集合。
7. 可观测性的三大维度
可观测性明确的三个维度数据:Metrics(指标)、Logging(日志)、Tracing(链路)
8. 监控和可观测性的关系和渊源
可观测性是对监控技术在理论、技术和
现实问题下的发展
• 理论上:将原来各自独立发展的三条监控
线统一了起来(Metrics、Loggin、
Tracing),提供标准化支持;
• 技术上:完备和发展了三条监控线的技
术,针对标准提供工具,并强调将三大支
柱的数据打通关联起来;
• 解决的现实问题:在云、容器、微服务的
当前,传统监控已经很难适应基础架构的
观测需要;
9. 可观测性架构演变
传统基础设施 互联网服务 云原生、微服务
特点:
• 单机、大型机为主
• 服务和架构简单
• 观测数据量少
• 监控能力和观测能力与服务
配套,部分可开箱即用 特点:
• 分布式架构
• 服务和架构较为复杂
• 观测数据和维度开始增长
• 物理机、虚拟机为主
• 各维度的观测能力分散发展 代表产品:
• IBM Tivoli
• HP openview
• CA unicenter
• Ganglia
• Cacti 代表产品:
• Zabbix
• Open-falcon
• Nagios
• grafana
• 各类APM:Zipkin、
Skywalking、Jaeger
• ELK、Splunk 特点:
• 架构微服务化,模块众多
• 服务和架构复杂
• 观测数据和维度量大且多样
• 云、容器、物理机、虚拟机
多种基础设施并存
• 可观测概念形成体系
代表产品:
• Prometheus
• 夜莺监控Nightingale
• Open-telemetry
10. 内容大纲
01 监控和可观测性的关系及渊源
02 当前阶段落地可观测性的挑战在哪里
03 落地好一个可观测系统的三大要素
04 面向故障处理过程的可观测性体系建设案例
05 思考:人工智能2.0对可观测性技术和产品演进的影响
11. 当前阶段落地可观测性的挑战在哪里?
观测系统多
稳定性保障难
12. 观测系统多
基础环境和微服务架构复杂 即有监控方案各异且割裂
•
•
•
• • 大部分企业都至少维护了5个以上相互割裂、使用方法各异的观测平台
• 65%以上的企业维护了10个以上的观测系统
跨多个云厂商
公有云+私有云
物理机+容器
模块和组件繁多
微服务架构和组件
物理机
云主机
虚拟机
Open-falcon Nightingale Prometheus Grafana Alertmanager 企业自研的监
控系统
日志类: ELK 阿里云SLS Loki 各云厂商和监
控厂商的方案
链路类: Skywalking Jaeger Zipkin 。。。
指标类:
容器
kubernetes
网络/存储/…
样
多
案
致方
导
,
性
多样
源
资
础
基
Zabbix 各云厂商和监
控厂商的方案
学
和
护
维
、
高
本
习成
差
验
体
使用
13. 故障处理难
• 各种可观测性的数据都有了,故障发现、故障定位还是难;
• 每天报警很多,但业务是不是受影响,靠业务侧反馈或客服投诉;
• 一确认故障,群里就炸了锅,相互确认,相互等待,团队协同很难,故障定位慢;
14. 内容大纲
01 监控和可观测性的关系及渊源
02 当前阶段落地可观测性的挑战在哪里?
03 落地好一个可观测系统的三大要素
04 面向故障处理过程的可观测性体系建设案例
05 思考:人工智能2.0对可观测性技术和产品演进的影响
15. 落地好一个可观测系统的三大要素
场景 场景: 定制、经验、方法论、最佳实践
平台 平台: 功能完备、接口友好
数据 数据: 采集、融合
好的产品一定是针对场景来设计实现
一套面向工程师的监控平台/工具
稳定性保障需要的数据不可避免的需要备齐并融合
16. 落地好一个可观测系统的三大要素
数据
巧妇难为无米之炊
难点:
• 采集:工具和渠道多样,质量和管理难
• 融合:采集后的数据如何融合?
场景
平台
数据
17. 落地好一个可观测系统的三大要素
数据
自采+集成的权衡
集中存储
已有数据源集成(Integration)
• 各维度典型观测系统
• 各云厂商观测系统
统一管理、统一采集、统一标签
公有云-1 公有云-2 公有云-3 容器 日志
标准组件 物理机 虚拟机 网络设备 tracing
18. 落地好一个可观测系统的三大要素
平台
一套趁手的炊具是好厨师的必备
场景
难点:
• 功能:通用而完备
• 接口:web or api?
平台
数据
19. 落地好一个可观测系统的三大要素
平台
通用功能齐备、接口灵活友好
功能
接口
指标查询 日志查询 Tracing查询 关联查询
指标告警 日志告警 告警管理 告警回调
大盘管理 用户管理 权限管理 。。。
友好的web接口
OaC/API命令行操作接口
20. 落地好一个可观测系统的三大要素
场景
不是有了食材和炊具都有了就一定能做出一道好菜
难点: 场景
• 经验
• 方法论
• 最佳实践 平台
数据
21. 落地好一个可观测系统的三大要素
场景
明确场景才有产品,在场景中对数据做深度融合
可能出现尝试定位和
尝试止损过程的反复
故障开始
故障发现
故障定位
服务止损
原因排查
风险解除
状态恢复
状态正常 状态异常 状态正常
常态预防 发现处理 复盘改进
稳定性建设的重点 首要原则是:先止损后排查
• 日常巡检
• 日常排查
增强预防、发现处理能力
22. 落地好一个可观测系统的三大要素
场景
针对场景实现产品、在场景中进一步融合数据
业务层健康状态
定 故障 确定问题的优先级
兜底总是漏加报警的问题
变业务反馈为主动发现
定 边界 确定问题的来源
确定跟进的主要责任主体
引导下钻定位
IT层健康状态
引导下钻定位
日志分析
链路分析
事件分析
指标分析
数据串联融合
容量分析
基础设施分析
。。。
定 特征
定 事件
连接止损动作的过程
23. 落地好一个可观测系统的三大要素
场景
结合场景建设可观测性的最佳实践
一个针对故障处理场景的产品和通用产品的不同:
1. 故障发现要明确能量化故障的关键指标,在产品上做VIP对待,而不只是简单的平铺或分级
2. 故障处理中首要原则是先止损后排查,而面向止损和面向根因定位的实现有重要的区别
3. 在故障处理场景中故障定位不是一味的排查“根因”,而是一个将故障的特征和关键事件连接到止损动作的过程
4. 故障定位也不存在一种包打天下的方法,各种可用的手段都应该用上,可用的手段越多定位能力就越强
5. 做好场景解决方案不只是产品本身,相应的流程和机制也需要配套建设,而反之有了产品,流程机制的建设也会更为自然
24. 内容大纲
01 监控和可观测性的关系及渊源
02 当前阶段落地可观测性的挑战在哪里?
03 落地好一个可观测系统的三大要素
04 面向故障处理过程的可观测性体系建设案例
05 思考:人工智能2.0对可观测性技术和产品演进的影响
25. 面向故障处理过程的可观测性体系建设案例
北极星 用于量化和定义业务健康度(选取指标如实时在线用户数、实时订单量、实
时支付量等),通常是“量”相关的指标;
配套关键功能:基于智能检测的告警、值守大屏;
灭火图 用于量化IT系统健康度,包括功能/模块(成功率、流量、响应延时)、组件(存储/消息
队列等)、基础设施(网络、CDN等),快速圈定故障范围;
配套关键功能:异常飘红、历史回溯、关联下钻、动态更新;
故障定位能力
矩阵
可观测平台
数据采集
指标大盘分析、日志分析、链路分析、事件分析、容量分析等;
配套关键功能:串联打通;
看图、大盘、告警、自愈、值班、权限、OaC/API接口等,采用开源夜莺监控(Nightingale);
配套关键功能:能力完备,接口友好;
选择All-in-one的采集器Categraf + 丰富的线下数据源和云数据源集成能力;
配套关键功能:管理方便、集成简便;
26. 面向故障处理过程的可观测性体系建设案例
北极星
指标分析
分布式追踪
资源大盘分析
用户行为分析
。。。
日志分析
灭火图
事件墙
27. 面向故障处理过程的可观测性体系建设案例
28. 面向故障处理过程的可观测性体系建设案例
29. 可观测性体系建设案例
1)重要问题:微服务的快速变化如何实时体现到可观测视图上?
指标
一种可行的微服务健康视图建设规范:
基于指标标签及日志字段确定动态映射规则
动态
的可
观测
服务
健康
视图
日志
链路
指标标签:
{business=“b_name”,”app”=“app_name”,service_level=”high”}
事件
日志样例:
business:b_name
app:app_name
http_host:xxx
request:/api/xxx
• 在指标生成和采集的源头把握好标签和字段的规范
• 可观测视图根据标签和字段完成动态映射、动态变化
30. 可观测性体系建设案例
2)重要问题:如何在场景中进一步串联融合?
指标
日志
•
•
•
•
•
•
•
基于日志生成指标,实现指标和日志关联
基于tracing生成指标,实现指标和日志关联
基于id和接口信息实现日志和tracing关联
基于tracing链路信息实现关联
基于指标标签实现关联
基于指标标签和日志字段实现关联
手动补偿关联
链路 指标标签:
{business=“b_name”,”app”=“app_name”,service_level=”high”}
事件 日志样例:
business:b_name
app:app_name
http_host:xxx
request:/api/xxx
观测平台的数据融合效果:
• 提供多种关联融合的工具、规则和方法
• 预置故障定位的最佳路径,让用户在故障定位中的下
一步所需信息即时可得
31. 可观测性体系建设经验点滴
1. 面向场景才能做出优秀的产品
2. 产品要有方法论和最佳实践的配套
3. 产品方和用户的深度合作是产品最终成功的关键
4. 流程和机制的建设是容易被忽略但却有意想不到的价值
32. 内容大纲
01 监控和可观测性的关系及渊源
02 当前阶段落地可观测性的挑战在哪里?
03 落地好一个可观测系统的三大要素
04 面向故障处理过程的可观测性体系建设案例
05 思考:人工智能2.0对可观测性技术和产品演进的影响
33. 思考:人工智能2.0对可观测性技术和产品演进的影响
AI在可观测领域产生突破性影响的两个阶段:
一、产品交互AI化、稳定性保障领域的专业模型出现
• 系统的输入将基于AI的NLP能力变为对话方式
• 系统的输出将变得更为灵活,可以基于输入产生灵活的输出内容和样式
• 基于全球的故障处理报告、基于有“意义”的可观测数据,结合大模型将产生稳定性保障领域的专业模型,智能化的观测和运维将真
正可能实现
• 和AIOps的不同:AI能力的建设从要求规范、准确的数据输入,转为有“意义”的数据输入
二、AI全托管
• 代码已经由AI编写,系统由AI自动维护,可观测的使用对象可能也是AI,影响太大,未来的形态不可准确预期
34. 个人联系方式
姓名:华明
微信号:myrainhua
开源夜莺监控社区:http://n9e.flashcat.cloud/
35.