过去一年，可观测性相关的技术得到了大量的关注，Gartner 也将可观测性列为了2023年十大战略技术趋势。那么到底什么是可观测性？可观测性与传统的监控有什么区别？如何践行一个优秀的业务可观测性实践？以及一个优秀的可观测性平台应该具备哪些能力？本文将从具体的业务场景出发，对可观测性的落地实践做一些深入的介绍，期望能给可观测性领域落地带来一定的启发。
什么是监控？
在回答这个问题之前，先来回想一下我们的系统使用监控的方式。当我们系统要接入监控时，第一步会使用各种各样的监控系统采集我们需要关注的指标和日志，然后配置上对应的仪表盘进行展示或检索，对于比较核心的指标还会设置告警，当系统产生告警时运维开发人员介入处理对应的异常。
以一个具体的案例来进行说明：一个简单的单体应用的架构如下图所示，这种架构服务之间的依赖关系非常简单，我们只需要关注后端服务的运行指标即可掌握整个系统的工作状态，后端服务出现超时或者不可用时，我们只需要查看后端服务负载指标基本上就能解决问题，就算后端服务没有异常，由于依赖的上下游非常简单，只需要稍微排查一些关联系统的负载情况问题基本上就能很好的解决了。
在构建这个监控的过程中，我们系统会收集哪些指标，哪些指标能体现我们系统的状态，这些前提都是已知的。这意味着我们先有目标，然后再使用具体的监控系统。这个阶段我们重点关注的监控覆盖率，当我们系统出现故障时，监控指标是否都有覆盖。简而言之，监控的目标就是希望能够发现系统异常，我们要知道【采什么？看什么？告什么？】
什么是可观测性？
随着云原生和微服务的理念不断推广和落地，传统的单体应用开始变得复杂，单体应用的功能被拆分到多个服务中，我们上面的单体应用架构开始变得复杂起来，原来的单体应用可能会被拆分成网关、认证、注册等多个服务，一些耗时的任务可能也会引入MQ系统，系统的一个请求会流转到多个服务上进行处理，系统中的各个模块之间会相互进行影响。此时，如果按照上面的传统的监控思路对系统故障进行管理时，就会发现很容易碰到瓶颈。
以一个实际的例子来进行说明：告警通知系统中的某个服务CPU使用率突然升高系统产生了中断，需要定位具体的原因。通过上图可知，系统中各个服务之间都有交互依赖关系，如果我们只使用监控的话，只能知道是哪个服务异常了，但是具体是什么原因导致的，以及怎么解决这个异常，监控就显得无能为力了。主要原因是，在监控的场景下系统是一个黑盒，我们主要关注的是指标或日志，监控对于为什么系统不可用给不出具体的答案，运维收到告警后，还需要进一步分析系统的上下游服务的日志或指标来定位问题。
在这种监控场景下，我们的目标是想知道为什么我们系统出现了异常，而不是只需要知道我们系统出现了异常。简而言之，可观测性要解决的是【随时随地掌握系统当前运行状态】。
监控和可观测性区别
通过上面的具体描述，我们不难发现监控是告诉我们系统哪部分是工作的，而可观测性可以告诉我们那里为什么不工作了。
- 监控是可观测性的一个子集，监控关注的是系统的失败因素，从而定义系统的失败模型。它的核心是运维，是监控设施，监控是站在局外人的角度，去审视系统的运行情况。
- 可观测性除了关注失败之外，其核心是研发，是具体的应用，是对系统的一种自我审视，是站在创造者的角度去探索系统应该如何恰当的展现自我的状态。 由此可见，监控是由外到内的过程，可观测性是从内到外的过程，可观测性并不是新生物，而是一种观念的创新。
如何践行业务可观测性实践？
可观测性这种观念上的创新，可以更好的帮助我们对系统进行审计，检查和整理我们系统究竟发生了什么？什么时间发生？以及发生的原因。对于企业来说，践行业务可观测性的首要目标就是要降低MTTR（平均修复时间），长时间的故障会极大的消磨用户口碑，降低用户体验从而影响我们的业务目标。除此之外，可观测性除了帮助我们更好的排查故障，基于可观测性数据解决实际问题，也能够影响我们产品决策从而改变产品，这才是我们践行可观测性的最终目标。
下图是我们分析定位问题的典型链路，对于业务来说，践行可观测性就是要具备下图上面的完整的能力，主要包括两部分：
收集数据： 可观测性能够很好的反馈我们系统的内部运行情况，良好的可观测性第一步是要收集系统运行的数据，这些数据大致可以分为四类：
- Metric：指标数据，典型的指标有请求量、请求耗时、请求成功/失败统计、业务自定义指标等；
- Tracing：分布式追踪数据，用来跟踪用户请求行为，能够清晰的反映用户请求在我们分布式系统中的流转过程；
- Logging：日志数据，记录系统运行过程中的详细信息；
- Profile：性能数据，比如CPU火焰图、内存火焰图等，帮助排查系统性能问题；
分析数据： 收集可观测性数据后，对于可观测性数据的分析能力是至关重要的，以实际的例子来说，我们服务部署在kubernetes集群中，在收集了四类可观测性数据后，是否具备完备的关联分析能力，当系统的服务指标出现异常时，我们能否定位到具体是哪个pod、container、host，以及主机上的网络情况如何。我们实际定位问题时，按照上图的链路会经常跳转到几个系统之间，我们还需要打通指标、调用链、日志、Profile之间的关联关系，方便我们在一个平面上定位问题。
如何构建优秀的可观测性平台？
从践行业务可观测性实践来看，一个优秀的可观测性平台应该具备以下能力：
- 丰富的数据采集能力： 能够具备采集Metric、Tracing、Logging、Profile数据；
- 接入简单无侵入式： 支持语言丰富，提供良好的接入指引，对于动态语言提供无侵入的接入方式；
- 完备的数据关联能力： 建立良好的可观测性数据模型（比如host、pod_name、service_name），统一元数据，能够在一个平面上关联所有可观测性数据；
- 优秀的仪表板能力： 支持各类仪表板，服务拓扑图、火焰图等可视化能力；
- 场景覆盖全面： 覆盖从客户端、服务端到基础设施所有场景；
参考资料
- 云原生可观测性之案例实践分享
- 可观测与监控的区别
- 一文带你走进《可观测性》
- Monitoring and Oberservability
