作者@Xenojoshua
來源@xenojoshua.com/2019/04/monitoring-tracing-logging
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系統一般用來處理大型系統的日誌聚合以及檢索查詢
回覆“加羣”與大佬們一起交流學習~
點擊“閱讀原文”查看 100+ 篇原創文章
本文分享自微信公衆號 - 前端自習課（FE-study）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。