OneAPM大讲堂 | Metrics, Tracing 和 Logging 的关系

【编者按】这是在 OpenTracing 和分布式追踪领域内广受欢迎的一片博客文章。在构建监控系统时，你们每每在这几个名词和方式之间纠结。
经过这篇文章，做者很好的阐述了分布式追踪、统计指标与日志之间的区别和关系。

Peter Bourgon 原做： Metrics, tracing, and logging

译者：吴晟

正文

今天，我很荣幸的参加了 2017 分布式追踪峰会(2017 Distributed Tracing Summit)， 并和来自 AWS/X-Ray,
OpenZipkin, OpenTracing, Instana, Datadog, Librato，以及其余更多组织的同仁进行了愉快的沟通和讨论。
其中一个重要的论点，是针对监控项目的范围和定义的。做为一个分布式追踪系统，应该管理日志么?从不一样角度看来，到底什么是日志?如何经过一张图形象的定位这些形形色色的系统?

整体说来，我以为咱们是在一些通用的名词间纠结。我想咱们能够经过图表来定义监控的做用域，使各名词的做用范围更明确。 咱们使用维恩图(Venn
diagram)来描述 Metrics, Tracing, Logging 三个概念的定义。他们三者在某些状况下是重叠的，可是我尽可能尝试定义他们的不一样。以下图所示：

Metrics 的特色是，它是可累加的：他们具备原子性，每一个都是一个逻辑计量单元，或者一个时间段内的柱状图。
例如：队列的当前深度能够被定义为一个计量单元，在写入或读取时被更新统计; 输入 HTTP 请求的数量能够被定义为一个计数器，用于简单累加;
请求的执行时间能够被定义为一个柱状图，在指定时间片上更新和统计汇总。

Logging 的特色是，它描述一些离散的(不连续的)事件。
例如：应用经过一个滚动的文件输出 Debug 或 Error 信息，并经过日志收集系统，存储到 Elasticsearch 中;
审批明细信息经过 Kafka，存储到数据库(BigTable)中;
又或者，特定请求的元数据信息，从服务请求中剥离出来，发送给一个异常收集服务，如 NewRelic。

Tracing 的最大特色就是，它在单次请求的范围内，处理信息。 任何的数据、元数据信息都被绑定到系统中的单个事务上。
例如：一次调用远程服务的 RPC 执行过程;一次实际的 SQL 查询语句;一次 HTTP 请求的业务性 ID。

根据上述的定义，咱们能够标记上图的重叠部分。

固然，大量的被监控的应用是具备分布式能力(Cloud-native)的应用，逻辑处理在单次请求的范围内完成。所以，讨论追踪的上下文是有意义的。
可是，咱们注意到，并非全部的监控系统都绑定在请求的生命周期上的。他们多是逻辑组件诊断信息、处理过程的生命周期明细信息，这些信息和任何离散的请求时正交关系。
因此，不是全部的 Metrics 和 Log 均可以被塞进追踪系统的概念中，至少在不通过数据加工处理是不行的。又或者，咱们可能发觉使用 Metrics 统计数据，对应用监控有很大帮助，例如 Prometheus 生态，能够量化的实时展示应用视图;相应的，若是咱们将 Metrics 统计数据强行使用针对 Log 的管道来处理，将使咱们丢失不少特性。

那么，在这里，咱们能够开始对已知的系统进行分类。如：Prometheus，
专注的 Metrics 统计系统，随着时间推移，也许会进化为追踪系统，进而进行请求内的指标统计，但不太可能深刻到 Log 处理领域。ELK 生态提供 Log 的记录，滚动和聚合，并在其余领域不停的积累更多的特性，并集成进来。

另外，我发现经过维恩图的方式展示三者关系时，会正巧展示出一个附加效应。在这三个功能域中，Metrics 倾向于更节省资源，由于他会“自然的”压缩数据。相反，日志倾向于无限增长的，会频繁的超出预期的容量。(有另外一篇我写的关于这方面的文章，查看，译者注：未翻译)。因此，咱们能够在图上，绘制出容量的需求趋势，Metrics 低到 Logging 高，
而 Trace 可能处于他们两的中间位置

也许，这不是最完美的方式描述这三者的管理，但我从会议现场收到的反馈来看，这个分类仍是至关不错的：随着三者的关系越清晰，咱们越容易建设性的讨论其余问题。若是你尝试对产品的功能进行定位，你可能也须要这张图，在讨论中，澄清产品的位置。

OneAPM Li 智能日志分析平台能够实时收集数据中心基础架构及应用的海量日志，实时搜索，实时分析，洞悉日志价值。想阅读更多技术文章，请访问 OneAPM 官方技术博客。
来源：http://blog.oneapm.com/apm-te...