云原生时代如何实现真正的业务可观测-华明

云原生时代如何实现真正的业务可观测 华明 个人简介 •2009年起先后任职百度运维部、滴滴运维部。 •做过一线运维也带过研发团队。曾负责大型服务的运维（百度广告系统、团购系统等）、完成滴滴的运维体系建设，打造了滴滴云原生平台，成为国内推进云原生最快的几家公司之一。 •2021年10月联合创立北京快猫星云科技有限公司，致力于通过产品赋能千万数字化企业的服务稳定性保障。 •2022年9月成为TGO鲲鹏会北京会员。 内容大纲 01监控和可观测性的关系及渊源 02当前阶段落地可观测性的挑战在哪里 03落地好一个可观测系统的三大要素 04面向故障处理过程的可观测性体系建设案例 05思考：人工智能2.0对可观测性技术和产品演进的影响 内容大纲 01监控和可观测性的关系及渊源 02当前阶段落地可观测性的挑战在哪里 03落地好一个可观测系统的三大要素 04面向故障处理过程的可观测性体系建设案例 05思考：人工智能2.0对可观测性技术和产品演进的影响 什么是可观测性 可观测性（Observability）是来自控制论的一个概念 Incontroltheory,observabilityisameasureforhowwellinternalstatesofasystemcanbeinferredbyknowledgeofitsexternaloutputs.Theobservabilityandcontrollabilityofasystemaremathematicalduals.TheconceptofobservabilitywasintroducedbyAmerican-HungarianscientistRudolfE.Kalmanforlineardynamicsystems. 简单来看，如果仅使⽤来自系统输出的信息可以估计当前状态，则系统被认为是“可观测的”。 我理解的可观测性 让服务任何时候都可以被观测，且观测效果可持续的规范、标准、方法、工具和平台的集合。 可观测性的三大维度 可观测性明确的三个维度数据：Metrics（指标）、Logging（日志）、Tracing（链路） 监控和可观测性的关系和渊源 可观测性是对监控技术在理论、技术和现实问题下的发展 •理论上：将原来各自独立发展的三条监控线统一了起来（Metrics、Loggin、Tracing），提供标准化支持； •技术上：完备和发展了三条监控线的技术，针对标准提供工具，并强调将三大支柱的数据打通关联起来； •解决的现实问题：在云、容器、微服务的当前，传统监控已经很难适应基础架构的观测需要； 可观测性架构演变 传统基础设施 互联网服务 云原生、微服务 特点： •单机、大型机为主 •服务和架构简单 •观测数据量少 •监控能力和观测能力与服务配套，部分可开箱即⽤ 代表产品： •IBMTivoli •HPopenview •CAunicenter •Ganglia •Cacti 特点： •分布式架构 •服务和架构较为复杂 •观测数据和维度开始增长 •物理机、虚拟机为主 •各维度的观测能力分散发展 代表产品： •Zabbix •Open-falcon •Nagios •grafana •各类APM：Zipkin、Skywalking、Jaeger •ELK、Splunk 特点： •架构微服务化，模块众多 •服务和架构复杂 •观测数据和维度量大且多样 •云、容器、物理机、虚拟机多种基础设施并存 •可观测概念形成体系 代表产品： •Prometheus •夜莺监控Nightingale •Open-telemetry 内容大纲 01监控和可观测性的关系及渊源 02当前阶段落地可观测性的挑战在哪里 03落地好一个可观测系统的三大要素 04面向故障处理过程的可观测性体系建设案例 05思考：人工智能2.0对可观测性技术和产品演进的影响 当前阶段落地可观测性的挑战在哪里？ 观测系统多 稳定性保障难 观测系统多 基础环境和微服务架构复杂 •跨多个云厂商 •公有云+私有云 •物理机+容器 •模块和组件繁多 即有监控方案各异且割裂 •大部分企业都至少维护了5个以上相互割裂、使⽤方法各异的观测平台 •65%以上的企业维护了10个以上的观测系统 微服务架构和组件 Zabbix Open-falcon Nightingale Prometheus Grafana Alertmanager 各云厂商和监控厂商的方案 企业自研的监控系统 指标类： 物理机 虚拟机 容器 云主机 kubernetes 网络/存储/… ELK 阿里云SLS Loki 链路类： Skywalking Jaeger Zipkin 。。。 各云厂商和监控厂商的方案 基础资源多样性，导致方案多样 维护和学习成本高、使⽤体验差 日志类： 故障处理难 •各种可观测性的数据都有了，故障发现、故障定位还是难； •每天报警很多，但业务是不是受影响，靠业务侧反馈或客服投诉； •一确认故障，群里就炸了锅，相互确认，相互等待，团队协同很难，故障定位慢； 内容大纲 01监控和可观测性的关系及渊源 02当前阶段落地可观测性的挑战在哪里？ 03落地好一个可观测系统的三大要素 04面向故障处理过程的可观测性体系建设案例 05思考：人工智能2.0对可观测性技术和产品演进的影响 落地好一个可观测系统的三大要素 场景 好的产品一定是针对场景来设计实现 场景：定制、经验、方法论、最佳实践 数据 平台 一套面向工程师的监控平台/工具 稳定性保障需要的数据不可避免的需要备齐并融合 平台：功能完备、接口友好数据：采集、融合 落地好一个可观测系统的三大要素 平台 场景 数据巧妇难为无米之炊难点： •采集：工具和渠道多样，质量和管理难 •融合：采集后的数据如何融合？ 数据 落地好一个可观测系统的三大要素 数据自采+集成的权衡 集中存储 已有数据源集成（Integration） •各维度典型观测系统 •各云厂商观测系统 统一管理、统一采集、统一标签 公有云-1 公有云-2 公有云-3 容器 日志 标准组件 物理机 虚拟机 网络设备 tracing 落地好一个可观测系统的三大要素 平台一套趁手的炊具是好厨师的必备 场景 平台 难点： •功能：通⽤而完备 •接口：weborapi? 数据 落地好一个可观测系统的三大要素 平台通⽤功能齐备、接口灵活友好 功能 接口 指标查询 日志查询 Tracing查询 关联查询 指标告警 日志告警 告警管理 告警回调 大盘管理 ⽤户管理 权限管理 。。。 友好的web接口 OaC/API命令行操作接口 落地好一个可观测系统的三大要素 场景不是有了食材和炊具都有了就一定能做出一道好菜 场景 难点： 平台 •经验 •方法论 •最佳实践 数据 落地好一个可观测系统的三大要素 场景明确场景才有产品，在场景中对数据做深度融合 可能出现尝试定位和尝试止损过程的反复 故障开始故障发现故障定位服务止损 原因排查 风险解除 状态恢复 状态正常 常态预防 稳定性建设的重点 状态异常 发现处理 首要原则是：先止损后排查 状态正常 复盘改进 增强预防、发现处理能力 •日常巡检 •日常排查 落地好一个可观测系统的三大要素 场景针对场景实现产品、在场景中进一步融合数据 业务层健康状态 定故障 IT层健康状态 定边界 确定问题的优先级 兜底总是漏加报警的问题 引导下钻定位 变业务反馈为主动发现 确定问题的来源 确定跟进的主要责任主体 指标分析 容量分析 定特征 定事件 数据串联融合 连接止损动作的过程 。。。 基础设施分析 事件分析 链路分析 日志分析 引导下钻定位 落地好一个可观测系统的三大要素 场景结合场景建设可观测性的最佳实践 一个针对故障处理场景的产品和通⽤产品的不同： 1.故障发现要明确能量化故障的关键指标，在产品上做VIP对待，而不只是简单的平铺或分级 2.故障处理中首要原则是先止损后排查，而面向止损和面向根因定位的实现有重要的区别 3.在故障处理场景中故障定位不是一味的排查“根因”，而是一个将故障的特征和关键事件连接到止损动作的过程 4.故障定位也不存在一种包打天下的方法，各种可⽤的手段都应该⽤上，可⽤的手段越多定位能力就越强 5.做好场景解决方案不只是产品本身，相应的流程和机制也需要配套建设，而反之有了产品，流程机制的建设也会更为自然 内容大纲 01监控和可观测性的关系及渊源 02当前阶段落地可观测性的挑战在哪里？ 03落地好一个可观测系统的三大要素 04面向故障处理过程的可观测性体系建设案例 05思考：人工智能2.0对可观测性技术和产品演进的影响 面向故障处理过程的可观测性体系建设案例 北极星 ⽤于量化和定义业务健康度（选取指标如实时在线⽤户数、实时订单量、实时支付量等），通常是“量”相关的指标； 配套关键功能：基于智能检测的告警、值守大屏； 灭火图 ⽤于量化IT系统健康度，包括功能/模块（成功率、流量、响应延时）、组件（存储/消息队列等）、基础设施（网络、CDN等），快速圈定故障范围； 配套关键功能：异常飘红、历史回溯、关联下钻、动态更新； 故障定位能力矩阵 指标大盘分析、日志分析、链路分析、事件分析、容量分析等；配套关键功能：串联打通； 可观测平台 配套关键功能：能力完备，接口友好； 看图、大盘、告警、自愈、值班、权限、OaC/API接口等，采⽤开源夜莺监控（Nightingale）； 数据采集 配套关键功能：管理方便、集成简便； 选择All-in-one的采集器Categraf+丰富的线下数据源和云数据源集成能力； 面向故障处理过程的可观测性体系建设案例 北极星 指标分析 分布式追踪 资源大盘分析 ⽤户行为分析 。。。 日志分析 灭火图 事件墙 面向故障处理过程的可观测性体系建设案例 面向故障处理过程的可观测性体系建设案例 可观测性体系建设案例 1）重要问题：微服务的快速变化如何实时体现到可观测视图上？ 指标 基于指标标签及日志字段确定动态映射规则 日志 链路 指标标签： 事件 [business=“b_name”,”app”=“app_name”,service_level=”high”] 日志样例：business：b_nameapp：app_namehttp_host：xxxrequest：/api/xxx 一种可行的微服务健康视图建设规范： 动态的可观测服务健康视图 •在指标生成和采集的源头把握好标签和字段的规范 •可观测视图根据标签和字段完成动态映射、动态变化 可观测性体系建设案例 2）重要问题：如何在场景中进一步串联融合？ 指标 日志 链路 事件 •基于日志生成指标，实现指标和日志关联 •基于tracing生成指标，实现指标和日志关联 •基于id和接口信息实现日志和tracing关联 •基于tracing链路信息实现关联 •基于指标标签实现关联 •基于指标标签和日志字段实现关联 •手动补偿关联 指标标签： [business=“b_name”,”app”=“app_name”,service_level=”high”] 日志样例：business：b_nameapp：app_namehttp_host：xxxrequest：/api/xxx 观测平台的数据融合效果： •提供多种关联融合的工具、规则和方法 •预置故障定位的最佳路径，让⽤户在故障定位中的下一步所需信息即时可得 可观测性体系建设经验点滴 1.面向场景才能做出优秀的产品 2.产品要有方法论和最佳实践的配套 3.产品方和⽤户的深度合作是产品最终成功的关键 4.流程和机制的建设是容易被忽略但却有意想不到的价值 内容大纲 01监控和可观测性的关系及渊源 02当前