监控、链路追踪、日志的区别，傻傻分不清？

1.监控、链路追踪、日志

对于一个系统来讲，监控、链路追踪、日志的这三者需求都是必然存在的，而有的时候咱们会搞不清楚这三者相互之间是什么关系。

我以前在作系统设计的时候也考虑过，是否是有必要引入那么多组件，毕竟若是这三者彻底分开每个一项的话，就有三个组件了（事实上就是：Prometheus+Grafana、Jaeger、ELK）。

1. 监控

---

Monitoring（监控）举例来讲就是：按期体检。

使用监控系统把须要关注的指标采集起来，造成报告，并对须要关注的异常数据进行分析造成告警。

特色是：

• 低频
• 按期
• 定量 这也是Prometheus的架构作得很是简单的缘由，Monitoring的需求并无包含很是高的并发量和通信量。反过来讲：高并发、大数据量的需求并不适用于Monitoring这个点。

3.链路追踪

Tracing（链路追踪）举例来讲就是：对某一项工做的按期汇报。某个工做开始作了A，制做A事件的报告，收集起来，而后这个工做还有B、C、D等条目，一个个处理，而后都汇总进报告，最终的结果就是一个Tracing。

特色是：

• 高频
• 巨量
• 有固定格式

由于Tracing是针对某一个事件（通常来讲就是一个API），而这个API可能会和不少组件进行沟通，后续的全部的组件沟通不管是内部仍是外部的IO，都算做这个API调用的Tracing的一部分。

能够想见在一个业务繁忙的系统中，API调用的数量已是天文数字，而其衍生出来的Tracing记录更是不得了的量。其特色就是高频、巨量，一个API会衍生出大量的子调用。

也所以适合用来作Monitoring的系统就不必定适合作Tracing了，用Prometheus这样的系统来作Tracing确定完蛋（Prometheus只有拉模式，所有都是HTTP请求，高并发直接挂掉）。

通常来讲Tracing系统都会在本地磁盘IO上作日志（最高效、也是最低的Cost），而后再经过本地Agent慢慢把文本日志数据发送到聚合服务器上，甚至可能在聚合服务器和本地的Agent之间还须要作消息队列，让聚合服务器慢慢消化巨量的消息。

Tracing在如今的业界是有标准的：OpenTracing，所以它不是很随意的日志/事件聚合，而是有格式要求的日志/事件聚合，这就是Tracing和Logging最大的不一样。

4.日志

Logging（日志）举例来讲就是：废品回收站。各类各样的物品都会汇总进入到配品回收站里，而后通过分门别类概括整理，成为各类可回收资源分别回收到商家那里。通常来讲咱们在大型系统中提到Logging说的都不是简单的日志，而是日志聚合系统。

从本质上来讲，Monitoring和Tracing都是Logging，Logging是这三者中覆盖面最大的超集，而前二者则是其一部分的子集。Logging最麻烦的是，开发者也不会彻底知道最后记录进入到日志系统里的一共会有哪些东西，只有在使用（检索）的时候才可能须要汇总查询总量中的一部分。

要在通常的Loggin系统中进行Monitoring也是能够的，直接把聚合进来的日志数据提取出来，按期造成数据报告，就是监控了。Tracing也是同样，只要聚合进了Logging系统，有了原始数据，后面要作都是能够作的。所以Logging系统最为通用，其特色和Tracing基本一致，也是须要处理高频并发和巨大的数据量。

5.总结

这样一看就很清楚了，每一个组件都有其存在的必要性：

• Monitoring系统（Prometheus）从根本的需求和基本设计上就不可能支持Tracing和Logging：低频 vs 高频、低量 vs 高量，其从设计到实现就只为了监控服务
• Tracing系统（Jaeger）对提供的数据有格式要求，且处理方式和通常的Logging也不一样，有更限定的应用范围
• Logging系统（ELK）能够处理前二者的需求，但前二者的领域有更专业的工具就不推荐直接使用普通的日志聚合系统了；Logging系统通常用来处理大型系统的日志聚合以及检索查询。

做者：Xenojoshua
来源：xenojoshua.com/2019/04/monitoring-tracing-logging/