度量，跟踪和日志记录

今天，我有幸参加了2017年的分布式追踪峰会，其中有很多来自AWS / X-Ray，OpenZipkin，OpenTracing，Instana，Datadog，Librato等公司的人员，我很遗憾我忘记了这一点。有一次讨论转向了项目范围和定义。跟踪系统是否也应该管理日志记录？什么确实的记录，通过在室内所代表的不同的镜头看？所有各种混凝土系统在哪里适合图片？

简而言之，我觉得我们在共享词汇中磕磕绊绊了一下。我认为我们可能会将仪器或可观察性的领域映射为一种维恩图。度量，跟踪和日志记录绝对是更广泛图景的所有部分，并且在某些情况下肯定会重叠，但我想尝试识别每个真正不同的属性。我想过喝咖啡休息时间想出来。

 

我认为度量的定义特征是它们是可聚合的：它们是在一段时间内组成单个逻辑规范，计数器或直方图的原子。作为示例：队列的当前深度可以被建模为规范，其更新与last-writer-win语义聚合; 传入的HTTP请求的数量可以建模为计数器，其更新通过简单的加法聚合; 并且观察到的请求持续时间可以被建模为直方图，其更新聚合成时间段并产生统计摘要。

我认为日志记录的定义特征是它处理离散事件。例如：通过syslog将轮换文件描述符发送到Elasticsearch（或OK Log，nudge nudge）的应用程序调试或错误消息; 审计跟踪事件通过Kafka推送到像BigTable这样的数据湖; 或从服务调用中提取的特定于请求的元数据，并将其发送到像NewRelic这样的错误跟踪服务。

我认为，跟踪的唯一定义特征是它处理请求范围的信息。可以绑定到系统中单个事务对象的生命周期的任何数据或元数据。例如：出站RPC到远程服务的持续时间; 发送到数据库的实际SQL查询的文本; 或入站HTTP请求的相关ID。

通过这些定义，我们可以标记重叠部分。

 

当然，云原生应用程序的许多典型工具最终都是请求范围的，因此在更广泛的跟踪环境中讨论可能是有意义的。但我们现在可以观察到并非所有仪器都必然会请求生命周期：例如，逻辑组件诊断信息或流程生命周期细节与任何离散请求正交。因此，例如，并非所有指标或日志都可以被追溯到跟踪系统 - 至少，不是没有一些工作。或者，我们可能会意识到直接在我们的应用程序中使用度量标准为我们带来了强大的好处，例如灵活的表达式 评估我们车队的实时视图; 相比之下，将指标纳入日志管道可能会迫使我们放弃其中的一些优势。

从这里开始，我们可以开始对现有系统进行分类。例如，Prometheus专门作为度量系统开始，随着时间的推移可能会逐渐增加到跟踪，从而进入请求范围的度量标准，但可能不会过度深入到日志记录空间。ELK提供了日志记录和汇总，将其牢牢地置于可聚合事件空间，但似乎不断在其他领域积累更多功能，将其推向中心。

此外，我观察到一个奇怪的操作细节作为这种可视化的副作用。在三个域中，度量标准往往需要最少的资源来管理，因为它们的性质很好地“压缩”。相反，伐木往往势不可挡，往往超过其报告的生产流量。（我之前在这个主题上写了更多。）因此，我们可以绘制一种体积或操作开销梯度，从度量（低）到记录（高） - 我们观察到跟踪可能位于中间的某个位置。

 

也许这不是对空间的完美描述，但我在峰会与会者的感觉是这种分类是有道理的：当我们所说的很清楚时，我们能够更有成效地说话。如果您试图了解产品空间，或者澄清您自己组织中的对话，也许这个图对您也很有用。

原文地址：http://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

参考：https://yq.aliyun.com/articles/514488?spm=a2c4e.11155435.0.0.65972a3cvBLOsg