随着微服务架构的流行，越来越多的系统被拆分为多个服务，可观测性成为人们关注的焦点。可观测性通常包括日志、追踪和度量三个方向，它们相互连接，为分析工具提供完整的系统视图。
定义
控制理论中的可观测性（observability）是指系统可以由其外部输出推断其其内部状态的程度。系统的可观测性和可控制性是数学上对偶的概念。可观测性最早是匈牙利裔工程师鲁道夫·卡尔曼针对线性动态系统提出的概念。若以信号流图来看，若所有的内部状态都可以输出到输出信号，此系统即有可观测性。
一系统具有可观测性当且仅当，针对所有的状态向量及控制向量，都可以在有限时间内，只根据输出信号来识别目前的状态。
----维基百科
为什么需要可观测性
当系统无法通过数据反映其内部状态时，对于系统维护人员而言，维护工作将变得异常困难，尤其是在系统出现问题时。近年来，随着微服务架构的普及，系统被拆分为多个服务的情况越来越多。每个服务的运行状况、服务之间的调用关系以及接口响应时延等问题都需要系统维护人员面对。因此，可观测性变得越来越重要，甚至被Gartner列为2023年的十大战略技术趋势之一。
系统具有可观测性能解决以下问题：
- 能够随时随地了解系统的行为、性能和运行状况，以便为最终用户提供最佳体验。
- 可以通过告警机制，及时感知系统出问题，减少对用户的影响。
- 当系统出现问题时，能够快速检测问题，有效排查并快速修复，缩短了平均解决时间。
- 了解系统中一些关键指标的发展趋势，以便及早作出预判响应。
可观测性主要内容
在IT行业中，可观测性一般被分为三个具体方向，即日志记录、追踪和度量。这三个方向被认为是可观测性的三大支柱，它们各有侧重点，但却并不是完全独立的，彼此之间也存在重叠的部分。
日志、追踪和度量（图片来源）
日志（Logging）
定义：
日志用来记录系统运行期间发生过的离散事件（时间随机、状态离散的事件）。主要包括记录事件发生的时间和事件发生时系统上下文的一些有效信息。日志对于生产系统来说是非常重要的，特别是当系统发生异常错误时，程序员就可以根据日志内容来排查问题并解决问题。
对于开发人员而言，日志打印可能是一个简单的任务。然而，在复杂的分布式系统中，面对成千上万的服务节点和快速产生的事件信息，仅仅打印日志是不够的。收集、存储和分析日志都是具有挑战性的任务。幸运的是，市场上已经有一些优秀的开源产品可供选择，具体如下：
在当前的开源产品中，Elastic Stack（ELK）技术栈是目前业界普遍使用的选择。作为CNCF的开源项目，Fluentd正在蓬勃发展，未来可能取代Logstash成为主流。
常见的日志处理过程：
追踪（Tracing）
定义：
追踪通常也被称为全链路追踪，表示请求通过系统时所经过的旅程。对于单体应用来说基本上指的是程序调用栈追踪。对于分布式系统来说，一个请求通常要经过若干个服务节点，此时的追踪是记录请求所经过的每一个服务节点的调用轨迹。记录的数据通常包含，一次请求随着时间的全链路调用过程，以及每段处理请求的耗时等信息，最终形成一个追踪树。如下图所示：
追踪链路时间图（图片来源）
在分布式系统中，通过全链路追踪我们可以很快的找出一个请求处理主要耗时在哪个阶段，找到系统性能瓶颈，然后有针对性的优化程序。同样也可以找到请求是在哪里出错的，提高排查故障的效率。
追踪系统也常被称为“APM 系统”（Application Performance Management），通常包含数据收集、数据存储和数据展示。国内比较知名的开源产品是 SkyWalking ，下面是一些比较优秀的开源产品：
图片来源
度量（Metrics）
定义：
度量是指对系统中某类信息的统计聚合。通常来说是收集一些比较关注的指标，这些指标能够反应系统的整体运行状况。
Java 提供了一种基本的度量方法，即通过 JMX（Java Management Extensions）监控程序的运行状态并获取相关度量数据，如内存使用情况、垃圾回收情况和线程数等。度量主要用于监控和预警功能，在某些指标达到预警值时，可以触发告警机制，通知相关责任人员及时处理。
度量系统可以大致分为目标系统指标数据收集、指标数据存储以及数据可视化和告警三大方面。度量方面比较优秀的产品有老牌的 zabbix，以及即将成为云原生时代下的度量监控标准的 Prometheus。下面是
Prometheus 架构及生态组件（图片来源）
优秀的一些开源产品：
图片来源
可观测性发展趋势
OpenTelemetry 逐渐成为行业标准
在现有可观测性开源框架下，日志、追踪、度量分别是三个系统，它们之间的联系甚少。当系统出现问题时，程序员往往需要在三个系统间来回切换，而且需要程序员自己去思考寻找问题在三个系统间的关联性。
例如某个时间突然某个指标告警，那么程序员将会在度量系统中查看这个指标的一些信息，及指标数据发展趋势，哪个时间段发生等信息。然后大脑就会飞速运转猜测可能造成指标异常的原因，再去日志系统、追踪系统去排查更详细的信息，日志系统和追踪系统之间还要推测思考它们之间的关联性。
通过观察上述排查问题的过程，我们可以得出一个结论：如果有一个系统能够生成一个单一且可遍历的图，其中包含了描述分布式系统状态所需的所有数据，那么这种数据结构将为分析工具提供一个完整的系统视图。这将使问题排查变得更高效和便捷。相比于独立的日志、追踪和度量系统，这种数据结构将它们连接在一起，使它们相互关联。
OpenTelemetry 因此诞生。OpenTelemetry，也简称为OTel，是一个中立的开源的可观测性框架，由一系列工具、API 和 SDK 组成，用于检测、生成、收集和导出遥测数据，如 轨迹、指标、日志，以进行分析和了解软件性能和行为。它的目标是统一追踪、度量和日志三大领域。作为云原生计算基金会 (CNCF) 的孵化项目，OTel 旨在提供与供应商无关的统一库和 API 集。下面是 OpenTelemetry 架构图。
OpenTelemetry 架构（图片来源）
参考引用
1、Metrics, tracing, and logging
2、凤凰架构
随着微服务架构的流行，系统的可观测性变得越来越重要。可观测性通常包括日志、追踪和度量三个方向，它们相互连接成为系统视图，提供给分析工具帮助排查问题。开源产品如Elastic Stack和Fluentd能够帮助收集、存储和分析日志。度量则可以通过JMX来监控程序运行状态和预警。更高效和便捷的排查问题需要系统形成一个可遍历的图，包含了所有描述系统状态的数据，并将日志、追踪和度量相互连接。
