什么是监控、链路追踪和日志？

Metrics、Tracing和Logging

OpenTelemetry基本定义了一个好的观察系统最后要做到的形态：终态就是实现Metrics、Tracing、Logging的融合，作为CNCF可观察性的终极解决方案。

• Tracing：提供了一个请求从接收到处理完毕整个生命周期的跟踪路径，通常请求都是在分布式的系统中处理，所以也叫分布式链路追踪
• Metrics：提供量化的系统内部和外部各个维度的指标，一般包括Counter、Gauge、Histoream等
• Logging：提供系统/进程最精细化的信息，例如某个关键变量、事件、访问记录等
  这三者在可观察性上缺一不可，基于Metrics的告警发现异常，通过Tracing定位问题（可疑）模块，根据模块具体的Logging定位到错误根源，最后再基于这次问题调查经验调整Metrics（增加或者调整报警阈值等）以便下次可疑更早发现/预防此类问题。

实现Metrics、Tracing、Logging融合的关键是能够拿到这三者之间的关联关系。我们用韦恩图可以表示这三者之间的关系：

Metrics中文可以叫度量或者指标，首先它的典型特征就是可聚合（aggregatable）。什么是可聚合呢？简单讲可聚合就是一种基本单位可以在一种维度区间上做数学计算（累加、平均等）。举个例子QPS就是一种Metrics，它的基本单位query是可以聚合的，它的维度区间就是时间区间，区间长度为1s，所以QPS通过聚合得出了每秒系统被请求的次数。类似的Metrics有单个网络query的平均访问延迟，MySQL的CPU资源使用率等。

I think that the defining characteristic of metrics is that they are aggregatable: they are the atoms that compose into a single logical gauge, counter, or histogram over a span of time.

Logging的典型特征就是它和孤立的事件（Event）强关联，一个事件的产生所以导致了一条日志的产生。举个例子就是一个网络query是一个事件，它被云端接到后Nginx产生了一个访问log。大量的不同外部事件间基本是离散的，比如多个用户访问云端业务时产生的5个事件间没有必然的关系，所以在一个服务节点的角度上看这些事件产生的日志间也是离散的。

I think that the defining characteristic of logging is that it deals with discrete events.

Tracing的典型特征就是它是有范围（Scope）的。我们在链路追踪系统时，作为链路追踪系统的元数据必然会承载一些范围信息，比如A服务RPC调用B服务的耗时，通过分析元数据中的traceId流经了哪些服务节点也是一种Scope。

I think that the single defining characteristic of tracing, then, is that it deals with infor