資源角度來看，傳統(tǒng)服務(wù)器這個物理單位也逐漸淡化，變成了看不見摸不到的虛擬資源模式。
從以上兩個變化可以看到這種彈性、標(biāo)準(zhǔn)化的架構(gòu)背后，原先運維與診斷的需求也變得越來越復(fù)雜。為了應(yīng)對這種變化趨勢，誕生一系列面向 DevOps 的診斷與分析系統(tǒng)，包括集中式日志系統(tǒng)（Logging），集中式度量系統(tǒng)（Metrics）和分布式追蹤系統(tǒng)（Tracing）。
Logging，Metrics 和 Tracing
Logging，Metrics 和 Tracing 有各自專注的部分。
Logging - 用于記錄離散的事件。例如，應(yīng)用程序的調(diào)試信息或錯誤信息。它是我們診斷問題的依據(jù)。
Metrics - 用于記錄可聚合的數(shù)據(jù)。例如，隊列的當(dāng)前深度可被定義為一個度量值，在元素入隊或出隊時被更新；HTTP 請求個數(shù)可被定義為一個計數(shù)器，新請求到來時進行累加。
Tracing - 用于記錄請求范圍內(nèi)的信息。例如，一次遠(yuǎn)程方法調(diào)用的執(zhí)行過程和耗時。它是我們排查系統(tǒng)性能問題的利器。
這三者也有相互重疊的部分，如下圖所示。
通過上述信息，我們可以對已有系統(tǒng)進行分類。例如，Zipkin 專注于 tracing 領(lǐng)域；Prometheus 開始專注于 metrics，隨著時間推移可能會集成更多的 tracing 功能，但不太可能深入 logging 領(lǐng)域； ELK，阿里云日志服務(wù)這樣的系統(tǒng)開始專注于 logging 領(lǐng)域，但同時也不斷地集成其他領(lǐng)域的特性到系統(tǒng)中來，正向上圖中的圓心靠近。
關(guān)于三者關(guān)系的更詳細(xì)信息可參考?Metrics, tracing, and logging。下面我們重點介紹下 tracing。
Tracing 的誕生
Tracing 是在90年代就已出現(xiàn)的技術(shù)。但真正讓該領(lǐng)域流行起來的還是源于 Google 的一篇論文"Dapper, a Large-Scale Distributed Systems Tracing Infrastructure"，而另一篇論文"Uncertainty in Aggregate Estimates from Sampled Distributed Traces"中則包含關(guān)于采樣的更詳細(xì)分析。論文發(fā)表后一批優(yōu)秀的 Tracing 軟件孕育而生，比較流行的有：
Dapper(Google) : 各 tracer 的基礎(chǔ)
StackDriver Trace (Google)
Zipkin(twitter)
Appdash(golang)
鷹眼(taobao)
諦聽(盤古，阿里云云產(chǎn)品使用的Trace系統(tǒng))
云圖(螞蟻Trace系統(tǒng))
sTrace(神馬)
X-ray(aws)
分布式追蹤系統(tǒng)發(fā)展很快，種類繁多，但核心步驟一般有三個：代碼埋點，數(shù)據(jù)存儲、查詢展示。
下圖是一個分布式調(diào)用的例子，客戶端發(fā)起請求，請求首先到達負(fù)載均衡器，接著經(jīng)過認(rèn)證服務(wù)，計費服務(wù)，然后請求資源，最后返回結(jié)果。
