关于服务器:监控链路追踪日志的区别傻傻分不清

42次阅读

共计 1705 个字符，预计需要花费 5 分钟才能阅读完成。

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

我之前在做零碎设计的时候也思考过，是不是有必要引入那么多组件，毕竟如果这三者齐全离开每一个一项的话，就有三个组件了（事实上就是：Prometheus+Grafana、Jaeger、ELK）。

监控

Monitoring（监控）举例来说就是：定期体检。

应用监控零碎把须要关注的指标采集起来，造成报告，并对须要关注的异样数据进行剖析造成告警。

特点是：

低频
定期
定量这也是 Prometheus 的架构做得非常简单的起因，Monitoring 的需要并没有蕴含十分高的并发量和通信量。反过来说：高并发、大数据量的需要并不适用于 Monitoring 这个点。

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 最大的不同。

Logging（日志）举例来说就是：废品回收站。各种各样的物品都会汇总进入到配品回收站里，而后通过分门别类演绎整顿，成为各种可回收资源别离回收到商家那里。一般来说咱们在大型零碎中提到 Logging 说的都不是简略的日志，而是日志聚合零碎。

从实质上来说，Monitoring 和 Tracing 都是 Logging，Logging 是这三者中覆盖面最大的超集，而前两者则是其一部分的子集。Logging 最麻烦的是，开发者也不会齐全晓得最初记录进入到日志零碎里的一共会有哪些货色，只有在应用（检索）的时候才可能须要汇总查问总量中的一部分。

要在个别的 Loggin 零碎中进行 Monitoring 也是能够的，间接把聚合进来的日志数据提取进去，定期造成数据报告，就是监控了。Tracing 也是一样，只有聚合进了 Logging 零碎，有了原始数据，前面要做都是能够做的。因而 Logging 零碎最为通用，其特点和 Tracing 基本一致，也是须要解决高频并发和微小的数据量。

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

Monitoring 零碎（Prometheus）从基本的需要和根本设计上就不可能反对 Tracing 和 Logging：低频 vs 高频、低量 vs 高量，其从设计到实现就只为了监控服务
Tracing 零碎（Jaeger）对提供的数据有格局要求，且解决形式和个别的 Logging 也不同，有更限定的利用范畴
Logging 零碎（ELK）能够解决前两者的需要，但前两者的畛域有更业余的工具就不举荐间接应用一般的日志聚合零碎了；Logging 零碎个别用来解决大型零碎的日志聚合以及检索查问。