01. 传统监控与可观测差异
传统监控体系是面向静态资源通过主动拨测方式构建的时序监控指标视图，其前置条件需要明确观测对象及观测指标，基于指标体系工程师能够了解哪些系统是确定工作的。在云原生观测场景下指标覆盖不全、业务侵入性大、数据关联性差、缺乏基于业务视角异常感知机制等问题凸显，传统监控能力难以适应云原生架构动态变化、服务依赖复杂、信息组织多样的现实问题，无法从全业务流量链路上有效定位问题，故障处置不及时整体业务连续性遇到较大挑战。
云原生观测体系通过多维观测数据链路trace、时序指标metric、日志明细log进行有机融合构建体系化观测体系，通过无侵入采集动态插码技术降低业务观测成本。同时提供丰富的业务应用视角的观测手段包括依赖分析、性能剖析、故障排错及根因定位，实现从被动感知到主动观测、从被动响应到主动观测体系建设的思维模式转变，从而达到了解已知、防范风险、探索未知的观测目标。
监控可类比中医基于脉搏时序检测依赖人为经验判断，依赖经验丰富的工程师；可观测类比西医，通过各种观测手段rum、apm、日志、基础监控构建全量观测体系白盒诊断，让医生对系统实时进行全面体检，发现问题所在。
02. 云原生时代应用可观测问题
云原生应用架构在落地敏捷开发、快速迭代、弹性伸缩的同时将原有的单体应用拆分成多个独立部署相互通信的组合应用，应用数量指数增长业务模块间的依赖关系错综复杂，不同业务层级不同维度难以建立实时有效关联的映射关系；同时，随着容器频繁启停监控对象及其指标变化成为常态故障现场难以留存、故障问题难以有效定位。以上云原生架构的观测难点给应用运维的故障分析、根因定位、业务连续稳定带来严峻挑战。云原生应用观测难点概述为以下两点：
1）信息维度复杂，难以建立多维数据关联映射关系
云原生应用的监控度量涉及应用进程、中间件、容器编排平台、容器进程、资源基础设施等相关层级资源属性和性能指标；其次，应用排障及性能剖析涉及多个服务、多个组件复杂交互关系，需根据请求链路依赖关系分析故障根因。
2）架构动态变化，故障现场难以留存问题难以定位
伴随业务规模和复杂度提升需要对服务不断进行拆分，软件架构的变化成为常态；容器部署架构基于声明式面向终态的设计思想，部署资源实例对象变更频繁，服务节点飘逸成为常态。基于多维明细数据和指标数据关联映射构建的运行时观测分析矩阵能有效回溯历史故障现场。
03. 云原生观测体系核心建设路径
1）统一观测模型、建立观测标准
面向云原生体系下不同的观测组件、多维的观测数据汗牛充栋，如何将不同的观测组件和观测数据进行有机融合建立统一观测模型、构建观测标准是建立云原生观测体系首要解决的核心问题。peter bourgon 在2017年2月撰写了一篇简明扼要的文章， 叫 “metrics, tracing, and logging” 首次提出可观测的三大支柱将观测数据按数据类型和应用场景划分为链路数据 trace 、时序指标数据 metric、明细日志文本数据log 。链路数据trace基于特定标识提供单笔请求的全量调用路径自动构建系统运行时软件架构，提供清晰排障路径。时序指标数据 metric 是用户观测系统状态和变化趋势，基于数据波动可有效发现异常，但无法用于根因定位。明细日志文本数据 log 应用运行过程的现场留存，保留完整业务执行明细，是业务排障主要来源。如何将三者进行有机统一，相互融合打造统一观测体系，核心分为以下三点：
① 统一观测对象建模
建立全局统一观测对象模型（可基于cmdb），构建多维业务对象级联关系，方便数据的定位寻址。
② 数据关联打标
在日志明细中埋入traceid和spanid，metric指标上报埋入业务对象标签。
③ 构建时间范围统计关系
提供基于时间统计维度依赖对象间的下钻分析能力
呈现效果：
2）构建以应用为中心的性能评估模型
不同维度的观测数据统一接入后需要对数据进行清洗、关联、聚合，构建以应用为中心将trace、metric、log多维数据融合的应用性能评价体系，从而基于业务视角统一性能评价标准主动发现性能瓶颈、快速感知故障、高效故障恢复，保障应用系统连续稳定。
3）挖掘持续观测运维决策反馈的应用场景
以应用为中心将性能指标、运行日志、服务事件、请求链路进行统计聚合、关联分析、建立服务全景观测中枢，实现服务性能度量、预测，提供故障根因及性能分析依据。联动标准运维能力及ai赋能加持，基于性能观测度量结果构建清晰运维决策链路，联动应用发布、故障处置、容灾演练、服务治理构建持续观测、优化改进的双向闭环反馈机制，保障系统连续稳定。
