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

系列目录

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

分布式架构-可观测性(二)-事件日志

分布式架构-可观测性(三)-链路追踪

分布式架构-可观测性(四)-聚合度量

引子

　　随着分布式架构越来越成熟，微服务、云原生架构（服务端架构演进史）的爆发式增长，可观测性（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/