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/