1、可观测性--前言

为什么“可观测性”必不可少？

相信你在开发过程中，一定遇到过这样的情况：

当线上环境出现一个问题后，测试找到开发业务的同学 A，A 发现这个请求还依赖其他项目组，于是就去找相关的责任人 B，但 B 经过一番排查，发现这个问题原来是 C 的。大家相互推诿，很难找到问题发生的原因，甚至严重时还会影响到项目的正常发布，惹得团队怨声载道。大家的开发任务已经很重了，还要被这种事情弄得焦头烂额。

虽然从业这么多年，但这个问题却始终困扰着我。最初，我以为是因为初创公司技术能力不足才导致这样的问题，后来却发现成熟的技术团队和技术架构同样存在着类似问题，它并没有因为我个人能力的成长和所在团队水平的提高而消失，反而越来越困扰我。比如，为什么有这么多的问题找不到原因，为什么我总是在解决十分相似的问题，为什么团队的沟通效率会如此低，并且随着团队离职率的上升，新人无法很快的熟悉以前的流程导致爆发新的问题， 等等。

因此，可观测性系统应运而生。

链路追踪通常与可观测性一起出现，它为可观测性提供了强有力的数据支持，也是可观测性中必不可少的一环。通过对这部分数据源的可视化，开发人员可以看到链路中每一环的执行流程。链路追踪通常还可以和链路分析结合在一起，除了链路追踪，还可以进行性能诊断并给出优化建议，为可观测性提供了多维度的数据和展现方式的支持。

如果没有很好的可观测系统，会存在哪些问题呢？

1. 无法有效地处理问题

开发人员，职责是编写好业务代码，并保证其持续且稳定地运行，但如何实现这个职责却是一大难题。如果运维人员告诉你线上出现了问题，但你翻遍日志也找不出问题的原因；如果用户反馈说出现了问题，但你测试没有任何异常，这个问题就像定时炸弹一样被埋了下来，不知道什么时候就会爆炸。可观测性可以通过一套完整的数据观测系统帮助你更快且更有效地发现问题、解决问题，可以说是保障线上稳定的关键。

2. 无法快速理解分布式系统

随着微服务的兴起，后端的服务和系统数量越来越多。同时，项目在不停地迭代，如果没有及时沉淀文档架构图，你就很难了解整体的系统架构和数据走向，站在“上帝”的视角去考虑如何优化。最常见的情况就是两个模块之间存在循环引用，但这种常见的问题往往又会有较大的隐患。无论你是一个开发小白，还是从业多年的架构师，可观测性都可以通过可视化的形式帮助你快速了解整个系统的架构、数据流向、业务指标等，从而使你更加了解系统，梳理架构。

3. 无法有效地利用系统资源

由于系统的数量越来越多，相应机器的资源管控也越来越复杂，同时每个服务之间还存在着一定的依赖关系。因此，我们很难了解每台机器上的资源是否都被充分利用了。而可观测性就可以帮助你分析出哪些服务利用率不够，哪些服务可以进行资源缩减。

综上不难发现，“可观测性”所解决的核心是效率问题。无论是处理问题、了解系统还是分配系统资源，“可观测性”都可以提高从公司到个人的整体效率。 这也是为什么，越来越多的公司开始重视可观测性。

可观测性≠监控

你可能会问，“可观测性”不就是监控吗？虽然它们看起来十分相似，但监控可以说是可观测性的一个子集。它们之间有 3 点区别：

核心不同

监控是以运维为核心的系统，它通过各项指标数据来定义整体的运行状态、失败情况等；观测则是以开发为核心的系统，除了监控，它还会对整个系统进行分析。很多时候，运维给出的错误数据，只能算是提出了问题，但可观测性除了提出问题，还可以清晰地给出导致错误的原因。

维度不同

监控是从外围的角度，通过各种指标（机器CPU、负载、网络的维度等）来判断整个系统的执行情况；而可观测性则在这种外部指标的基础上，以应用内的各个维度来展开推测，最后，通过二者结合的数据更加真实地反映出我们应用的运行情况。

展现的信息不同

有些系统在正常运行时十分稳定，但是一到高并发的时候就会出现问题。此时，监控只能汇报问题出现的状况，但可观测性就可以很好地通过图形化的方式告知我们问题的原因，而不是由我们用经验来猜测。它可以将未知或者不确定的信息展现出来，使我们可以更好地了解系统的整体情况。

可观测性打破了开发和运维原有的问题解决方式，不再是运维发现问题开发解决，而是以开发为中心。 开发人员以什么样的形式去暴露关键的指标等，是与业务开发中的可扩展性和高可用性同等重要的内容。