摘要：随着大量云原生技术的应用，IT系统日益复杂，主动感知、预测故障并迅速定位、排障的难度变得越来越大，传统监控方式已无法跟上需求，由此应运而生的可观测性，被视为未来云环境生产部署不可或缺的技术支撑。
随着大量云原生技术的应用，IT系统日益复杂，主动感知、预测故障并迅速定位、排障的难度变得越来越大，传统监控方式已无法跟上需求，由此应运而生的可观测性，被视为未来云环境生产部署不可或缺的技术支撑。
可观测性是一种对业务应用系统的属性要求，其指的是能够感知系统当前运行状态的特性。提升系统的可观测性有助于我们了解“正在发生什么”以及“为什么会这样”。在设计应用系统架构的初始阶段，应将系统自身的可观测性建设纳入考虑范围，设计出能够暴露更多可被观测的运行时数据的架构，并在这些数据之间建立关联。
监控与可观测性均致力于助力构建高可用性服务，以缩短故障处理时间，二者通常紧密协作，界限相对不明确。
监控通常聚焦于告警触发的瞬间状态，一般围绕告警事件展开，涵盖从告警事件产生至应急响应等一系列操作。其关注视角通常为局部可用性，关注各个具体的监控项，例如 CPU 负载、剩余内存等。监控是一个常被提及的话题，最常见的场景包括系统资源监控、进程或服务状态的粗粒度监控。然而，对定制化的业务指标监控不够友好，另外，传统监控体系对云原生以及微服务体系监控的支持也欠佳。
可观测性可视为监控的一种延续，涉及范围较广，包含全链路分析（APM）、业务服务质量（SLA）、业务容量等，着重于服务的整体可用性。其关注视角通常为全局可用性，会忽略一些不影响服务质量的指标，例如若 CPU 负载高但服务整体时延波动不大，则会忽略该 CPU 负载指标。
可观测性的应用场景通常与业务能力相绑定，通过可视化聚合展示影响 SLA 的相关指标（SLI），再配合监控告警，借助可观测性看板进行下钻分析以确定异常根因。此外，可观测性在打通 Metrics/Traces/Logs 后能够主动识别服务的潜在风险，从而先于用户发现问题。
需要把可观测性的理念贯穿到架构和程序设计中，而不是到事发或事后再来补救。需要有意识地设计一些机制来观察业务指标的关联变化、系统架构的数据漏斗模型、程序内逻辑分支的运行开销、外部资源依赖的健康状态，还要暴露程序内的一些资源并发度、池的填充率和命中率、运行时的状态等情况，当运行错误时也要在错误信息中携带足量的上下文信息。
运维、开发、架构师都是各环节设计的参与者，在协作方式也有一定的改变：
运维人员：需深入了解产品业务与应用服务，对业务指标、应用服务指标、系统资源指标等进行定义并建立关联。同时运维要为可观测场景提供更坚实的工具基础，在庞大的数据压力下，保障和解决数据存储和查询的性能、资源开销、集群的拓展性和稳定性等问题。开发人员：应在框架层进行设计并实现对分布式应用服务运行时的Metric（指标数据）、Trace（调用链路数据）、Log（日志数据）等数据的采集。架构师：负责业务应用系统与可观测性系统的整体架构设计，需关注无侵入式采集上报、多维度量聚合、错误根源分析以及整体海量数据的处理与存储等方面。可观测性建设的核心关注点还是在数据的采集、存储、分析环节。
采集：尝试梳理完整的数据链路，来覆盖从终端发起、网关、业务、基础设施中间的每一层组件，包括请求量、耗时、错误和容量等，以及线程池、队列、连接池等资源指标。
存储：数据存储环节要关注多种类型数据的存储和查询系统选型。最为常见的是Metrics、Traces、Logs相关的存储系统，这三者都有非常广泛的基础软件选型。其中相对棘手的是指标维度爆炸、日志和Trace存储成本及性能相关的问题，一般需要搭配预聚合、前采样和后采样、存储分级等策略来解决。
关联：纵向关联请求上下游链路和调用栈，横向关联请求和处理请求所消耗的应用资源。
模型：数据采集和关联、异常定义和分析、全链路错误寻根三方面统一的模型化设计。针对不同的业务应用系统进行合理抽象，建设更标准的可观测性能力。
分析：数据分析环节要关联不同数据源的元信息，糅合以多维视角来构建查询界面。同时，我们也要关注如何在海量的原始数据中找到一些突出和异常的数据，一般需要建设一些流式检测和聚类分析的能力。
将Metrics、Traces、Logs三者打通才能发挥最大价值，已知的有两类方式：
1、基于时间范围内的统计关系：一般的使用习惯是在Metric异常的时间区间里去找到对应时间区间出现异常行为的Traces和Logs，这种方式会依赖对Traces和Logs的聚类分析能力。
2、基于Label和TraceID关联：基于OpenTelemetry Collector可观测数据采集的框架，我们可以以插件的形式、以Trace Span元数据Label来生成访问指标，也同时将TraceID携带记录到日志的元信息中，这样就能以同样的TraceID或Label维度进行关联查看了。另外当前Prometheus实现了一个exemplar特性可以将Metric与TraceID关联存储，这个设计也挺有意思的。
三者打通最大的价值是能做到全链路根因定位，从发现请求Metric指标异常，通过指标关联分析，并逐层下钻到明细Trace追踪和具体Error Log，全流程自动化从宏观到明细的错误发现和根因定位。
现在OpenTelemetry对Metrics、Traces、Logs三者提供了统一标准，开源社区热度也比较大，是个值得去研究和实践的方向。
打通后可以实现通过服务名等多个维度立体、全息分析整个服务的可用性，最终业务价值在于帮助研发和运维提高了应用服务的排障和治理效率。
其实技术选型没什么特定的标准，每个企业不同阶段可能有不同的选择，适合自己的才是最好的，这里总结几点心得：
控制成本预算，企业一般需要从自身的发展阶段实际情况考虑，不必一上来就整全链路可观测性，也许初期只用传统的Zabbix就满足需求了。理性按需选择，大可不必盲从主流。拥抱开源，初期一般采用开源产品，开箱即用，搭顺风车。另外，选型时还需要考虑周边生态的丰富度。根据团队技术栈选择，中间件、业务服务、云原生、物理机监控等选型都要贴合团队已有的技术栈。来源：11不吃香菜a
