監(jiān)控、鏈路追蹤、日志的區(qū)別，傻傻分不清？

作者：Xenojoshua
來(lái)源：xenojoshua.com/2019/04/monitoring-tracing-logging/

1. 監(jiān)控、鏈路追蹤、日志

對(duì)于一個(gè)系統(tǒng)來(lái)說(shuō)，監(jiān)控、鏈路追蹤、日志的這三者需求都是必然存在的，而有的時(shí)候我們會(huì)搞不清楚這三者相互之間是什么關(guān)系。

我之前在做系統(tǒng)設(shè)計(jì)的時(shí)候也考慮過(guò)，是不是有必要引入那么多組件，畢竟如果這三者完全分開每一個(gè)一項(xiàng)的話，就有三個(gè)組件了（事實(shí)上就是：Prometheus+Grafana、Jaeger、ELK）。

因此想做個(gè)筆記嘗試舉例來(lái)梳理下。

Metrics, tracing, and logging 地址：

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

2. 監(jiān)控

Monitoring（監(jiān)控）舉例來(lái)說(shuō)就是：定期體檢。

使用監(jiān)控系統(tǒng)把需要關(guān)注的指標(biāo)采集起來(lái)，形成報(bào)告，并對(duì)需要關(guān)注的異常數(shù)據(jù)進(jìn)行分析形成告警。

特點(diǎn)是：

• 低頻
• 定期
• 定量

這也是Prometheus的架構(gòu)做得非常簡(jiǎn)單的原因，Monitoring的需求并沒(méi)有包含非常高的并發(fā)量和通訊量。反過(guò)來(lái)說(shuō)：高并發(fā)、大數(shù)據(jù)量的需求并不適用于Monitoring這個(gè)點(diǎn)。

3. 鏈路追蹤

Tracing（鏈路追蹤）舉例來(lái)說(shuō)就是：對(duì)某一項(xiàng)工作的定期匯報(bào)。某個(gè)工作開始做了A，制作A事件的報(bào)告，收集起來(lái)，然后這個(gè)工作還有B、C、D等條目，一個(gè)個(gè)處理，然后都匯總進(jìn)報(bào)告，最終的結(jié)果就是一個(gè)Tracing。

特點(diǎn)是：

• 高頻
• 巨量
• 有固定格式

因?yàn)門racing是針對(duì)某一個(gè)事件（一般來(lái)說(shuō)就是一個(gè)API），而這個(gè)API可能會(huì)和很多組件進(jìn)行溝通，后續(xù)的所有的組件溝通無(wú)論是內(nèi)部還是外部的IO，都算作這個(gè)API調(diào)用的Tracing的一部分。

可以想見在一個(gè)業(yè)務(wù)繁忙的系統(tǒng)中，API調(diào)用的數(shù)量已經(jīng)是天文數(shù)字，而其衍生出來(lái)的Tracing記錄更是不得了的量。其特點(diǎn)就是高頻、巨量，一個(gè)API會(huì)衍生出大量的子調(diào)用。

也因此適合用來(lái)做Monitoring的系統(tǒng)就不一定適合做Tracing了，用Prometheus這樣的系統(tǒng)來(lái)做Tracing肯定完蛋（Prometheus只有拉模式，全部都是HTTP請(qǐng)求，高并發(fā)直接掛掉）。

一般來(lái)說(shuō)Tracing系統(tǒng)都會(huì)在本地磁盤IO上做日志（最高效、也是最低的Cost），然后再通過(guò)本地Agent慢慢把文本日志數(shù)據(jù)發(fā)送到聚合服務(wù)器上，甚至可能在聚合服務(wù)器和本地的Agent之間還需要做消息隊(duì)列，讓聚合服務(wù)器慢慢消化巨量的消息。

Tracing在現(xiàn)在的業(yè)界是有標(biāo)準(zhǔn)的：OpenTracing，因此它不是很隨意的日志/事件聚合，而是有格式要求的日志/事件聚合，這就是Tracing和Logging最大的不同。

4. 日志

Logging（日志）舉例來(lái)說(shuō)就是：廢品回收站。各種各樣的物品都會(huì)匯總進(jìn)入到配品回收站里，然后經(jīng)過(guò)分門別類歸納整理，成為各種可回收資源分別回收到商家那里。一般來(lái)說(shuō)我們?cè)诖笮拖到y(tǒng)中提到Logging說(shuō)的都不是簡(jiǎn)單的日志，而是日志聚合系統(tǒng)。

從本質(zhì)上來(lái)說(shuō)，Monitoring和Tracing都是Logging，Logging是這三者中覆蓋面最大的超集，而前兩者則是其一部分的子集。Logging最麻煩的是，開發(fā)者也不會(huì)完全知道最后記錄進(jìn)入到日志系統(tǒng)里的一共會(huì)有哪些東西，只有在使用（檢索）的時(shí)候才可能需要匯總查詢總量中的一部分。

要在一般的Loggin系統(tǒng)中進(jìn)行Monitoring也是可以的，直接把聚合進(jìn)來(lái)的日志數(shù)據(jù)提取出來(lái)，定期形成數(shù)據(jù)報(bào)告，就是監(jiān)控了。Tracing也是一樣，只要聚合進(jìn)了Logging系統(tǒng)，有了原始數(shù)據(jù)，后面要做都是可以做的。因此Logging系統(tǒng)最為通用，其特點(diǎn)和Tracing基本一致，也是需要處理高頻并發(fā)和巨大的數(shù)據(jù)量。

5. 總結(jié)

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

• Monitoring系統(tǒng)（Prometheus）從根本的需求和基本設(shè)計(jì)上就不可能支持Tracing和Logging：低頻 vs 高頻、低量 vs 高量，其從設(shè)計(jì)到實(shí)現(xiàn)就只為了監(jiān)控服務(wù)
• Tracing系統(tǒng)（Jaeger）對(duì)提供的數(shù)據(jù)有格式要求，且處理方式和一般的Logging也不同，有更限定的應(yīng)用范圍
• Logging系統(tǒng)（ELK）可以處理前兩者的需求，但前兩者的領(lǐng)域有更專業(yè)的工具就不推薦直接使用普通的日志聚合系統(tǒng)了；Logging系統(tǒng)一般用來(lái)處理大型系統(tǒng)的日志聚合以及檢索查詢