監控、鍊路追蹤、日志的差別，傻傻分不清？

1. 監控、鍊路追蹤、日志

對于一個系統來說，監控、鍊路追蹤、日志的這三者需求都是必然存在的，而有的時候我們會搞不清楚這三者互相之間是什麼關系。

我之前在做系統設計的時候也考慮過，是不是有必要引入那麼多元件，畢竟如果這三者完全分開每一個一項的話，就有三個元件了（事實上就是：Prometheus+Grafana、Jaeger、ELK）。

是以想做個筆記嘗試舉例來梳理下。

Metrics, tracing, and logging 位址：

http://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

2. 監控

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系統一般用來處理大型系統的日志聚合以及檢索查詢