很多公司喜欢把一些对分布式的观察系统叫做日志处理系统,告警系统,监控系统等,老实讲都是片面的或者没有真正的理解观察系统和监控系统字面用词区别下的本质理念区别.一个优秀的观察系统不单是日志处理,监控,告警这些单维的功能组件.它是基于日志数据,指标数据等基础数据并结合链路追踪技术做数据综合处理后形成的完备的无缝的观察平台.
Logging,Metrics和Tracing的概念
OpenTelemetry基本定义了一个好的观察系统最后要做到的形态:终态就是实现Metrics、Tracing、Logging的融合,作为CNCF可观察性的终极解决方案.
OpenTelemetry is a collection of tools, APIs, and SDKs. You use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) for analysis in order to understand your software's performance and behavior.
- Tracing: 提供了一个请求从接收到处理完毕整个生命周期的跟踪路径，通常请求都是在分布式的系统中处理，所以也叫做分布式链路追踪。
- Metrics: 提供量化的系统内/外部各个维度的指标，一般包括Counter、Gauge、Histogram等。
- Logging: 提供系统/进程最精细化的信息，例如某个关键变量、事件、访问记录等。
这三者在可观察性上缺一不可,基于Metrics的告警发现异常，通过Tracing定位问题(可疑)模块，根据模块具体的Logging定位到错误根源，最后再基于这次问题调查经验调整Metrics(增加或者调整报警阈值等)以便下次可以更早发现/预防此类问题.
实现Metrics、Tracing、Logging融合的关键是能够拿到这三者之间的关联关系.这篇文章(Metrics, tracing, and logging)详细的描述了三者的定义. 下面我对这篇文章做简短的解释方便大家快速理解,当然要全面的客观的了解还是要看原文.
首先我们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)的.我们在链路追踪系统时,作为链路追踪系统的元数据必然会承载一些范围(Scope)信息,比如A服务RPC调用B服务的耗时(duration),通过分析元数据中的traceId流经了那些服务节点也是一种Scope.
I think that the single defining characteristic of tracing, then, is that it deals with information that is request-scoped.
Metrics、Tracing、Logging是有交集和差集的.每个交集和差集都能找到对应的实际的例子,不再一一赘述.
https://segmentfault.com/a/1190000039082442