今天，市面上的监控系统可以说是百花齐放了，从 Google Dapper 再到后面各种开源的监控系统，例如 ZipKin/Pinpoint/ Apache Skywalking / OpenTelemetry / Elasticsearch / Prometheus 等等，无一不是围绕着 Metrics / Tracing / Logging 三种数据中的一种或者多种来进行设计实现的。本文旨在帮助读者更好地理解这三种数据各自的特点以及三者之间存在的关系。

介绍

Metrics

• 一组描述过程或者活动的数据
• 跟随着时间变化的时序数据
• 可聚合的 KV 数据
• 可压缩、存储、处理、检索

Metrics 一般是用来计算 Events 发生数量的数据集，这些数据通常具有原子性，且可以聚合。从操作系统到应用程序，任何事物都会产生 Metrics 数据，这些数据可以用来度量操作系统或应用程序是否健康，或者是用以计算一段时间内请求的平均延时。由于目前并没有 Metrics 采集的标准 API，所以不同的监控系统在收集 Metrics 数据时采取的手段也可能不一样，但大部分无非都是通过 PUSH 到中心 Collector 方式采集 Metrics（比如各种 Agent 采集器，Telegraf 等）；又或者是中心 Collector 通过 PULL 的方式去主动获取 Metrics（比如 Prometheus）。最重要的是可以将采集到的 Metrics 数据与对应的系统或应用程序相关联，通过图表或其他方式直观展示，使得这些 Metrics 更具有价值。

Logging

• 记录离散 Events

Logging 描述的是一些列离散事件，在缺乏有力的监控系统时，Logging 数据通常是工程师在定位生产问题时最直接的手段。如果说 Metrics 可以告诉你系统或者应用程序出现问题，那么 Logging 就可以告诉你为什么会出现问题。关于日志的采集现在也有很多方法，比如：filebeat, fluented, loki 等。

Tracing

• 通常是记录应用程序操作的数据
• 一次请求的完整生命周期
• 分布式系统中一次请求经历过多个服务产生操作的数据（Spans）

Tracing 是通过有向无环图的方式记录在分布式系统中发生的 Events 之间的因果关系。云原生场景下，多个服务之间或多或少存在着依赖关系，一次 Tracing 通常会经过多个服务（Span），甚至在高度复杂的分布式系统中，一次 Tracing 包含数以万计的 Span 也是可能存在的。再者，Tracing 更多的是关注这种端到端系统之间的联系，基于该需求，分布式追踪系统应运而生。