Metrics、Tracing、Logging的融合

终极目标

OpenTelemetry的终态就是实现Metrics、Tracing、Logging的融合，作为CNCF可观察性的终极解决方案。

Tracing：提供了一个请求从接收到处理完毕整个生命周期的跟踪路径，通常请求都是在分布式的系统中处理，所以也叫做分布式链路追踪。
Metrics：提供量化的系统内/外部各个维度的指标，一般包括Counter、Gauge、Histogram等。
Logging：提供系统/进程最精细化的信息，例如某个关键变量、事件、访问记录等。

这三者在可观察性上缺一不可：基于Metrics的告警发现异常，通过Tracing定位问题（可疑）模块，根据模块具体的日志详情定位到错误根源，最后再基于这次问题调查经验调整Metrics（增加或者调整报警阈值等）以便下次可以更早发现/预防此类问题。

Metrics、Tracing、Logging融合的关键

实现Metrics、Tracing、Logging融合的关键是能够拿到这三者之间的关联关系.其中我们可以根据最基础的信息来聚焦，例如：时间、Hostname(IP)、APPName。这些最基础的信息只能定位到一个具体的时间和模块，但很难继续Digin，于是我们就把TraceID把打印到Log中，这样可以做到Tracing和Logging的关联。但这还是解决不了很多问题：

如何把Metrics和其他两者关联起来
如何提供更多维度的关联，例如请求的方法名、URL、用户类型、设备类型、地理位置等
关联关系如何一致，且能够在分布式系统下传播

在OpenTelemetry中试图使用Context为Metrics、Logging、Tracing提供统一的上下文，三者均可以访问到这些信息，由OpenTelemetry本身负责提供Context的存储和传播：

Context数据在Task/Request的执行周期中都可以被访问到
提供统一的存储层，用于保存Context信息，并保证在各种语言和处理模型下都可以工作（例如单线程模型、线程池模型、CallBack模型、Go Routine模型等）
多种维度的关联基于Tag（或者叫meta）信息实现，Tag内容由业务确定，例如：通过TrafficType来区别是生产流量还是压测流量、通过DeviceType来分析各个设备类型的数据...
提供分布式的Context传播方式，例如通过W3C的traceparent/tracestate头、GRPC协议等

转载于:https://www.cnblogs.com/aguncn/p/11511758.html