分布式架构-可观测性-原理概览

引子

随着分布式架构越来越成熟，微服务、云原生架构(服务端架构演进史)的爆发式增长，可观测性(Observability)已经被纳入了架构必备知识体系。2017 年的分布式追踪峰会(2017 Distributed Tracing Summit)结束后，Peter Bourgon 撰写了总结文章《Metrics, Tracing, and Logging》系统地阐述了这三者的定义、特征，以及它们之间的关系与差异，受到了业界的广泛认可。可观测性可分解为三个更具体方向进行研究，分别是：事件日志、链路追踪和聚合度量，这三个方向各有侧重，又不是完全独立。本系列文章将会从这3个方面剖析概念和主流产品，以期给架构师一个宏观的了解。

一、原理概览

1.1 主体概念

日志(Logging)：日志的职责是记录离散事件，通过这些记录事后分析出程序的行为，譬如曾经调用过什么方法，曾经操作过哪些数据，等等。

追踪(Tracing)：单体系统时代追踪的范畴基本只局限于栈追踪(Stack Tracing)；微服务时代，一个请求的完整的调用轨迹将跨越多个服务，包括服务间的网络传输信息与各个服务内部的调用堆栈信息，因此，分布式系统中的追踪在国内常被称为“链路追踪”，也称为“分布式追踪”(Distributed Tracing)。追踪的主要目的是排查故障。

度量(Metrics)：度量是指对系统中某一类信息的统计聚合。度量指标有很多维度的。最常见的JAVA虚拟机提供的JMX(Java Management eXtensions)度量，可统计内存大小、各分代的用量、峰值的线程数、垃圾收集的吞吐量、频率。度量的主要目的是监控(Monitoring)和预警(Alert)，如某些度量指标达到风险阈值时触发事件，以便自动处理或者提醒管理员介入。

1.2 边界概念

Peter Bourgon原文中有一张图描述了Tracing、Logging、Metrics三者的关系和边界图。如下所示：

看的有点懵，没关系，看我翻译过来的图如下：

如上图所示，我们分4步骤来看边界关系：

1. 追踪(Tracing)+日志(Logging)=请求级事件。例：traceId写入日志，日志可以追踪请求。
2. 度量(Metrics)+日志(Logging)=聚合级事件。例：统计指标写入日志，方便查询指标。
3. 追踪(Tracing)+度量(Metrics)=请求级指标。例：计算每个请求的指标，如请求耗时。
4. 三方交集(图中笑脸)：请求级事件(追踪+日志)+聚合级事件(度量+日志)=请求级、聚合级事件 例：traceId+统计指标写入日志。做请求链路级别的，附带有聚合统计指标的日志。这就是可观测性(Observability)的 基础模型。

二、主流产品

在工业界，目前针对可观测性的产品已经是一片红海，经过多年的角逐，日志、度量两个领域的胜利者算是基本尘埃落定。

• 日志：日志收集和分析大多被统一到 Elastic Stack(ELK)技术栈上。
• 度量：跟随着 Kubernetes 统一容器编排的步伐，Prometheus 也击败了度量领域里以 Zabbix 为代表的众多前辈，已成为云原生时代度量监控的事实标准。
• 追踪：追踪由于跟底层技术栈关联较大，通常要有多种产品来针对不同的语言和网络。市面上主流的工具既有像 Datadog 这样的一揽子商业方案，也有 AWS X-Ray 和 Google Stackdriver Trace 这样的云计算厂商产品，还有像 SkyWalking、Zipkin、Jaeger 这样来自开源社区的优秀产品。

下图是CNCF Interactive Landscape中列出的日志、追踪、度量(度量的核心产品是监控)领域的著名产品，其实这里很多不同领域的产品是跨界的，譬如 ELK 可以通过 Metricbeat 来实现度量的功能，Apache SkyWalking 的探针就有同时支持度量和追踪两方面的数据来源，由OpenTracing进化而来OpenTelemetry更是融合了日志、追踪、度量三者所长，有望成为三者兼备的统一可观测性解决方案。本章后面的讲解，也会扣紧每个领域中最具有统治性产品来进行介绍。

 =========参考===============

凤凰架构：http://icyfenix.cn/distribution/observability/