監控、鏈路追蹤、日誌的區別，傻傻分不清？

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/