關於監控、鏈路追蹤、日誌三者的區別

1. 監控、鏈路追蹤、日誌

對於一個系統來說，監控、鏈路追蹤、日誌的這三者需求都是必然存在的，而有的時候我們會搞不清楚這三者相互之間是什麼關係。我之前在做系統設計的時候也考慮過，是不是有必要引入那麼多組件，畢竟如果這三者完全分開每一個一項的話，就有三個組件了（事實上 就是：Prometheus+Grafana、Jaeger、ELK）。

因此想做個筆記嘗試舉例來梳理下。

外部鏈接：

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. 總結

這樣一看就很清楚了，每個組件都有其存在的必要性：

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/T85kdL9EgRD66QqAZiF-4Q

猜你喜歡