【編者按】這是在 OpenTracing 和分布式追蹤領(lǐng)域內(nèi)廣受歡迎的一片博客文章紊婉。在構(gòu)建監(jiān)控系統(tǒng)時(shí)聪轿，大家往往在這幾個(gè)名詞和方式之間糾結(jié)捌斧。 通過這篇文章戈稿，作者很好的闡述了分布式追蹤西土、統(tǒng)計(jì)指標(biāo)與日志之間的區(qū)別和關(guān)系。

Peter Bourgon 原作： Metrics, tracing, and logging

譯者：吳晟

正文

今天鞍盗，我很榮幸的參加了 2017 分布式追蹤峰會(2017 Distributed Tracing Summit)需了， 并和來自 AWS/X-Ray, OpenZipkin, OpenTracing, Instana,?Datadog, Librato跳昼，以及其他更多組織的同仁進(jìn)行了愉快的溝通和討論。 其中一個(gè)重要的論點(diǎn)肋乍，是針對監(jiān)控項(xiàng)目的范圍和定義的鹅颊。作為一個(gè)分布式追蹤系統(tǒng)，應(yīng)該管理日志么?從不同角度看來墓造，到底什么是日志?如何通過一張圖形象的定位這些形形色色的系統(tǒng)?

總體說來堪伍，我覺得我們是在一些通用的名詞間糾結(jié)。我想我們可以通過圖表來定義監(jiān)控的作用域觅闽，使各名詞的作用范圍更明確帝雇。 我們使用維恩圖(Venn diagram)來描述 Metrics, Tracing,? Logging 三個(gè)概念的定義。他們?nèi)咴谀承┣闆r下是重疊的蛉拙，但是我盡量嘗試定義他們的不同尸闸。如下圖所示：

Metrics 的特點(diǎn)是，它是可累加的：他們具有原子性孕锄，每個(gè)都是一個(gè)邏輯計(jì)量單元吮廉，或者一個(gè)時(shí)間段內(nèi)的柱狀圖。 例如：隊(duì)列的當(dāng)前深度可以被定義為一個(gè)計(jì)量單元畸肆，在寫入或讀取時(shí)被更新統(tǒng)計(jì); 輸入 HTTP 請求的數(shù)量可以被定義為一個(gè)計(jì)數(shù)器宦芦，用于簡單累加; 請求的執(zhí)行時(shí)間可以被定義為一個(gè)柱狀圖，在指定時(shí)間片上更新和統(tǒng)計(jì)匯總轴脐。

Logging 的特點(diǎn)是踪旷，它描述一些離散的(不連續(xù)的)事件。 例如：應(yīng)用通過一個(gè)滾動的文件輸出 Debug 或 Error 信息豁辉，并通過日志收集系統(tǒng)，存儲到 Elasticsearch 中; 審批明細(xì)信息通過?Kafka舀患，存儲到數(shù)據(jù)庫(BigTable)中; 又或者徽级，特定請求的元數(shù)據(jù)信息，從服務(wù)請求中剝離出來聊浅，發(fā)送給一個(gè)異常收集服務(wù)餐抢，如 NewRelic。

Tracing 的最大特點(diǎn)就是低匙，它在單次請求的范圍內(nèi)旷痕，處理信息。 任何的數(shù)據(jù)顽冶、元數(shù)據(jù)信息都被綁定到系統(tǒng)中的單個(gè)事務(wù)上欺抗。 例如：一次調(diào)用遠(yuǎn)程服務(wù)的 RPC 執(zhí)行過程;一次實(shí)際的 SQL 查詢語句;一次 HTTP 請求的業(yè)務(wù)性 ID。

根據(jù)上述的定義强重，我們可以標(biāo)記上圖的重疊部分绞呈。

當(dāng)然贸人，大量的被監(jiān)控的應(yīng)用是具有分布式能力(Cloud-native)的應(yīng)用，邏輯處理在單次請求的范圍內(nèi)完成佃声。因此艺智，討論追蹤的上下文是有意義的。 但是圾亏，我們注意到十拣，并不是所有的監(jiān)控系統(tǒng)都綁定在請求的生命周期上的。他們可能是邏輯組件診斷信息志鹃、處理過程的生命周期明細(xì)信息夭问，這些信息和任何離散的請求時(shí)正交關(guān)系。 所以弄跌，不是所有的 Metrics 和 Log 都可以被塞進(jìn)追蹤系統(tǒng)的概念中甲喝，至少在不經(jīng)過數(shù)據(jù)加工處理是不行的。又或者铛只，我們可能發(fā)覺使用 Metrics 統(tǒng)計(jì)數(shù)據(jù)埠胖，對應(yīng)用監(jiān)控有很大幫助，例如 Prometheus 生態(tài)淳玩，可以量化的實(shí)時(shí)展現(xiàn)應(yīng)用視圖;相應(yīng)的直撤，如果我們將 Metrics 統(tǒng)計(jì)數(shù)據(jù)強(qiáng)行使用針對 Log 的管道來處理，將使我們丟失很多特性蜕着。

那么谋竖，在這里，我們可以開始對已知的系統(tǒng)進(jìn)行分類承匣。如：Prometheus蓖乘， 專一的 Metrics 統(tǒng)計(jì)系統(tǒng)，隨著時(shí)間推移韧骗，也許會進(jìn)化為追蹤系統(tǒng)嘉抒，進(jìn)而進(jìn)行請求內(nèi)的指標(biāo)統(tǒng)計(jì)，但不太可能深入到 Log 處理領(lǐng)域袍暴。ELK 生態(tài)提供 Log 的記錄些侍，滾動和聚合，并在其他領(lǐng)域不停的積累更多的特性政模，并集成進(jìn)來岗宣。

另外，我發(fā)現(xiàn)通過維恩圖的方式展現(xiàn)三者關(guān)系時(shí)淋样，會正巧展現(xiàn)出一個(gè)附加效應(yīng)耗式。在這三個(gè)功能域中，Metrics 傾向于更節(jié)省資源，因?yàn)樗麜疤烊坏摹眽嚎s數(shù)據(jù)纽什。相反措嵌，日志傾向于無限增加的，會頻繁的超出預(yù)期的容量芦缰。(有另一篇我寫的關(guān)于這方面的文章企巢，查看，譯者注：未翻譯)让蕾。所以浪规，我們可以在圖上，繪制出容量的需求趨勢探孝，Metrics 低到 Logging 高笋婿， 而?Trace?可能處于他們兩的中間位置

也許，這不是最完美的方式描述這三者的管理顿颅，但我從會議現(xiàn)場收到的反饋來看缸濒，這個(gè)分類還是相當(dāng)不錯的：隨著三者的關(guān)系越清晰，我們越容易建設(shè)性的討論其他問題粱腻。如果你嘗試對產(chǎn)品的功能進(jìn)行定位庇配，你可能也需要這張圖，在討論中绍些，澄清產(chǎn)品的位置捞慌。

OneAPM Li智能日志分析平臺可以實(shí)時(shí)收集數(shù)據(jù)中心基礎(chǔ)架構(gòu)及應(yīng)用的海量日志，實(shí)時(shí)搜索柬批，實(shí)時(shí)分析啸澡，洞悉日志價(jià)值。想閱讀更多技術(shù)文章氮帐，請?jiān)L問OneAPM 官方技術(shù)博客嗅虏。

來源：http://blog.oneapm.com/apm-tech/811.html