西格曼：我叫本·西格曼。我是Lightstep的聯(lián)合創(chuàng)始人兼首席執(zhí)行官。我在這里討論的是資源和事務(wù)，這是可觀察性的一個基本的二元性。我職業(yè)生涯的大部分時間都在研究可觀察性。在我職業(yè)生涯之初，我在谷歌工作了九年，致力于谷歌的分布式跟蹤系統(tǒng)Dapper，以及他們的高可用性監(jiān)控和度量系統(tǒng)Monar。然后，Lightstep當(dāng)然也專注于可觀察性。我花了很長時間才到這里。我想出了一種與過去不同的思考可觀察性的方法，這就是這次演講的內(nèi)容。

事務(wù)

什么是事務(wù)?在右邊，您可以看到某個系統(tǒng)的示意圖。我們將從這個銀行賬戶服務(wù)的角度來討論一些事情，它處于一些更大的微服務(wù)架構(gòu)，一些云原生架構(gòu)中。本演示文稿中的事務(wù)不一定像銀行事務(wù)。它只是指從系統(tǒng)的一部分傳播到另一部分的任何請求，而不是整個請求。這是它所做的所有工作，直到它回來并完成它試圖完成的一切。事務(wù)是應(yīng)用程序中實際上“為最終用戶做點什么”的東西，不管最終用戶是人，或者在某些情況下，如果是Twilio，或者類似的東西。也許Twilio的最終用戶實際上只是另一個運行腳本的程序。事務(wù)為用戶或客戶提供價值。

現(xiàn)在，特別是對于原生云，事務(wù)是分布式的。它們不一定非得如此，但通常是這樣。它們可以用許多不同的粒度來描述。我的意思是，同一個事務(wù)可以用非常粗的粒度來描述，就像整個最終用戶工作流一樣。比如，如果你是一個像Lyft、Uber之類的乘車共享應(yīng)用程序，那么整個請求乘車的流程可能會被視為一個事務(wù)。這是您僅有的粒度級別。您可能希望更細粒度地考慮服務(wù)之間的單個請求，比如HTTP請求。您可能會認(rèn)為這是您想要用來描述事物的粒度，或者您想要更詳細地了解一些甚至所有本地函數(shù)調(diào)用。然后我假設(shè)，從理論上講，您可以根據(jù)整個系統(tǒng)中為完成一個事務(wù)而發(fā)生的每個CPU指令來查看一個事務(wù)。這些都是建模事務(wù)的有效方法。當(dāng)然，當(dāng)我們記下這個列表時，在這個粒度級別記錄東西的成本會越來越高。事實上，它可能會變得如此之高，以至于會產(chǎn)生大量的開銷，并開始影響事務(wù)。理論上，這些是不同的粒度。用于描述事務(wù)的遙測通常是跟蹤和結(jié)構(gòu)化日志。結(jié)構(gòu)化日志類似于文本日志語句，但具有明確的鍵值屬性。這些事情在這里有說明。您可以看到銀行帳戶請求有一個請求大小屬性、一些HTTP路徑、狀態(tài)代碼、延遲等等。這些是此模型中事務(wù)片段的理論屬性。

我還認(rèn)為，跟蹤最終將取代日志記錄。這需要時間，但對于事務(wù)來說，跟蹤將取代日志記錄。現(xiàn)在，我將通過向您展示跟蹤模型比簡單的單進程日志記錄靈活得多來激發(fā)這一點。這里我不談?wù)?021，但這更像是放大了可觀測性。這是一個日志記錄語句。第22行有一些偽代碼。這些日志語句中的每一條都定義了自己的表。這里的結(jié)構(gòu)定義了一系列鍵，請求大小、路徑、狀態(tài)、延遲都在這里反映出來。這些列將成為此表的列。然后是從本地狀態(tài)或其他地方提取的值。這組值將成為表中的行。

跟蹤只是跨事務(wù)的連接

為了闡明這一點并使之清楚，您有這個日志語句，因為生產(chǎn)中運行的代碼填充了這個理論表。當(dāng)然，我并不是建議我們將這些數(shù)據(jù)全部插入MySQL或類似的東西，甚至不一定要將其插入到Elastic、Splunk或類似的東西中。只是有一個由日志語句本身描述的理論表，您可以這樣建模。在某些情況下，您可以使用工具對這些表運行查詢。跟蹤的酷之處在于，這些日志記錄系統(tǒng)執(zhí)行靈活連接非常困難或不可能，或者非常昂貴或不可能。分布式跟蹤在整個系統(tǒng)中進行連接。同樣，如果這是您的系統(tǒng)架構(gòu)，我們將要做的是實現(xiàn)所有結(jié)構(gòu)化事件的連接，無論您將它們稱為日志還是跟蹤范圍，這其實并不重要。您仍在描述事務(wù)。我們將使用跟蹤上下文將所有這些服務(wù)中的結(jié)構(gòu)化事件連接到一個更大的表中。其中有一個表，其中包含來自這些不同服務(wù)的列，在這里用顏色編碼，服務(wù)A、B和D也在其中連接。然后，每個分布式事務(wù)表示該表中的一行。

這是非常強大的，因為如果您能夠在這個概念模型中思考問題，就可以運行各種分析來找出跨服務(wù)邊界的列之間的相關(guān)性。這反過來允許您了解一個服務(wù)中的行為如何影響另一個服務(wù)中的某些行為。具體來說，您可能會在服務(wù)a中的堆棧頂部有一個customer ID字段，并且您可能會發(fā)現(xiàn)，當(dāng)銀行帳戶服務(wù)的延遲較高時，某些客戶參與的時間比例較高。然后這就給了你一些東西，比如，那個客戶是如何改變他們的工作量的，或者你做了什么?這些類型的連接實際上是理解跨服務(wù)邊界的因果關(guān)系的一種非常重要的機制。如果您一直想知道分布式跟蹤的所有麻煩是什么，那么在這個模型中，分布式跟蹤實際上是結(jié)構(gòu)化日志語句的一個連接。然后是一系列語義和查詢功能。這就是事務(wù)。

資源是什么?

接下來，我們將討論資源。什么是資源?資源是事務(wù)為完成其工作而消耗的東西。這個定義的一個副作用是，根據(jù)定義，資源是有限的。你的亞馬遜賬單是一種資源。同樣，許多不同的顆粒。通過Kafka主題的吞吐量，Kafka集群只能支持這么多負載。當(dāng)你到了負載的末尾，并且你已經(jīng)消耗了所有的負載，事情會很快變得非常糟糕。你最終會遇到很多推回，很高的延遲，請求被丟棄，諸如此類的事情。類似地，CPU使用率也完全正常，直到不正常為止。如果您使服務(wù)中的CPU飽和，所有您認(rèn)為理所當(dāng)然的事情都會中斷。更糟糕的是，進程的內(nèi)存使用率直接崩潰。例如，您還可以非常精細地討論單個互斥鎖。如果你在一個鎖上有很多爭用，你最終會得到一個讀鎖，這個讀鎖應(yīng)該是180納秒，如果一個鎖有很多爭用，可能需要一百萬倍的時間。這也會帶來問題。這些都是資源類型。資源之所以成為一種資源，是因為它們能夠跨事務(wù)生存，并且能夠跨事務(wù)共享。共享資源是非常重要的，因為如果你不共享資源，你的系統(tǒng)將非常昂貴。在多租戶、多請求環(huán)境中運行的全部好處在于，您可以更好地利用資源，并在事務(wù)中共享資源。這就是資源。

為了讓它更直觀一點，我為一個微服務(wù)、一個Kafka集群和一個互斥鎖繪制了這些框。這完全是說明問題的。我相信有更好的方法來衡量這些東西的健康狀況。對于一種資源，您要考慮的是該資源在某種程度上的剩余量。它是資源消耗量的指標(biāo)。您可以看到CPU使用率會急劇上升，RAM使用率會急劇上升。您可以看到，使用者延遲或生產(chǎn)者延遲是Kafka集群運行狀況的指標(biāo)，或者您必須等待獲取互斥鎖的時間是互斥鎖運行狀況的指標(biāo)。任何資源都有一些健康指標(biāo)。我想在這里強調(diào)的是，這些都不是單個事務(wù)成功或失敗的指標(biāo)。當(dāng)然，當(dāng)CPU和內(nèi)存使用率達到峰值時，事務(wù)會出現(xiàn)問題。這意味著表明資源的健康狀況。我會談?wù)劄槭裁催@是相關(guān)的。然后資源也有一堆標(biāo)簽。這其實很重要。

在我看來，這些標(biāo)簽或?qū)傩缘挠猛臼嵌喾矫娴?。?dāng)然，你只是想理解和分解。如果您看到這樣的峰值，您可能希望按區(qū)域分組，或按集群ID分組，或類似的方式。那很好。您應(yīng)該能夠在時間序列數(shù)據(jù)庫中執(zhí)行此操作。更重要的是，這些標(biāo)簽是溝通資源和事務(wù)的通用語言。理想情況下，當(dāng)事務(wù)跨越資源時，該事務(wù)會以某種方式對該資源進行注釋。它可以作為從事務(wù)數(shù)據(jù)連接到資源數(shù)據(jù)的一種方式，反之亦然。這是一個非常強大的東西。稍后，當(dāng)我們進入一個實際的例子時，我將討論這個問題。

資源也是一個層次結(jié)構(gòu)

我說過有不同的粒度，也有層次結(jié)構(gòu)。這對于事務(wù)來說是正確的，但我認(rèn)為更重要的是在這里強調(diào)這一點。您可能有一個Kafka集群，它本身有許多微服務(wù)。在這些虛擬機中，有一堆虛擬機。在這些鎖中，有一堆互斥鎖。這些東西也會上下波動。在資源環(huán)境中有層次結(jié)構(gòu)，以及這些健康指標(biāo)。

相互依存

我們已經(jīng)談過事務(wù)了。它們是客戶真正關(guān)心的工作。我們已經(jīng)討論過資源，它們是使事務(wù)做一些事情并在事務(wù)之間共享的東西。這些是相互依存的。下面是這些資源的圖表。這些綠色的曲線旨在說明流入或流出這些資源并執(zhí)行其工作的事務(wù)。您可以看到，在本例中，事務(wù)將轉(zhuǎn)到不同的HTTP端點。在這種情況下，我們將討論不同的Kafka主題。在本例中，讀卡器和寫卡器試圖對互斥鎖執(zhí)行鎖定。有不同類型的事務(wù)，我們希望當(dāng)事務(wù)跨越資源時，使用該資源的標(biāo)識符對其進行注釋。如果這個主題是Y請求，那么根據(jù)不同粒度級別的模式進行事務(wù)，如果您想要了解資源和事務(wù)是如何交互的，那么對于使用Kafka實例狀態(tài)的區(qū)域和集群ID對事務(wù)進行注釋是非常有價值的?；蛘?，對于這個端點，對于要在跟蹤中用諸如主機名或容器ID、服務(wù)名稱、版本之類的東西注釋的事務(wù)。同樣，您可以使用資源中的標(biāo)記清空事務(wù)，并充當(dāng)這兩個世界之間的映射。這就是一個例子。綠色的東西基本上是痕跡。然后在資源中，您通常使用度量遙測、時間序列統(tǒng)計來表示這些資源的運行狀況。不總是，但通常是。

資源和事務(wù)是完全、完全相互依賴的。這是一個非常重要的問題。也就是說，如果您的資源不健康，那么事務(wù)將受到很大影響。如果事務(wù)數(shù)量過多，資源就會受到很大影響。事實上，作為一個主題，持續(xù)集成最讓我感到困擾的一點是，在不知道工作負載的情況下，代碼甚至可以是正確的或不正確的。我認(rèn)為那完全是海市蜃樓。我覺得CI很棒。當(dāng)然，我們在Lightstep中使用CI。至少對于系統(tǒng)軟件或后端軟件來說，您可以知道代碼是否正確的唯一方法是在實際工作負載下運行代碼。因為工作負載實際上是語義的一部分，所有關(guān)于資源如何配置，甚至資源如何設(shè)計和實現(xiàn)的調(diào)優(yōu)都在很大程度上取決于事務(wù)的實際工作負載。這不僅僅是你可能需要更多的東西，而是你可能真的想要一個不同的東西。我不喜歡人們太討厭MySQL。我之前有點討厭某些類型的數(shù)據(jù)，但是如果你的數(shù)據(jù)可以很容易地放在一臺機器上，而且你只需要關(guān)系語義，那就太完美了。除了一些復(fù)制問題之外，它其實沒有什么錯。類似地，如果你想要一個真正的行星規(guī)模和便宜的東西，你必須離開這個模型，做一些其他的事情。從設(shè)計的角度來看，或者從代碼的角度來看，直到您考慮事務(wù)性工作負載時，資源也不能被認(rèn)為是正確的或不正確的?？捎^察性是理解工作負載如何影響資源健康的最簡單方法之一，反之亦然。

說到相互依賴，應(yīng)用程序的客戶只關(guān)心事務(wù)。我的意思是，如果你有一次停電，有人試圖寫一份報告，特別是為一個非技術(shù)性的最終用戶寫的，他們真的一點也不關(guān)心你的資源耗盡這一事實。這不是他們的問題。這是你的問題，不是他們的問題。他們只關(guān)心自己的事務(wù)是否正確，并在合理的時間內(nèi)回來。正確性，也意味著這不是一個錯誤。正確性和延遲是客戶或最終用戶關(guān)心的兩件事，而不是其他。如何做到這一點取決于你自己。對于運營者(operator)來說，你唯一能控制的就是你的資源。按運營者，包括DevOps、SRE。軟件的全部意義在于，我們不是坐在那里從客戶那里獲取事實，然后填寫一些東西，然后作為一個人做一些工作。我們正在編寫自動化軟件。那個軟件是靠資源運行的。

總體而言，運營者主要關(guān)注資源，因為這實際上是他們擁有的控制點。最終用戶只關(guān)心事務(wù)。最終用戶和運營者也以這種方式相互依賴。如果最終用戶改變行為太快，可能會給運營者帶來資源問題。顯然，如果運營者最終做了一些損害資源健康的事情，那么最終用戶就會受到影響。最終用戶、運營者、事務(wù)、資源都以這種方式相互依賴。他們之間有這種關(guān)系。最終用戶和開發(fā)人員，或者開發(fā)人員或運營者也完全相互依賴。我認(rèn)為這是一件非常有趣的事情，對我來說，無論如何，這是一件深刻的事情。最終用戶和事務(wù)、運營者和資源，這是他們傾向于思考的，因為這是他們可以控制和處理的。它們實際上是在工作負載本身中相交的完全不同的平面。

DevOps工程師/SRE要做什么?

我們到底在做什么?這聽起來像個問題。有必要能夠在這兩個方面之間進行轉(zhuǎn)換，跨越遙測類型、度量和跟蹤，通過標(biāo)記進行聚合，并自動進行轉(zhuǎn)換。這是一種方法，您可以通過資源和軸心來了解資源的稀缺性或健康問題，以了解事務(wù)是如何變化的?；蛘?，您可以從事務(wù)非常慢或返回錯誤開始，找出與此相關(guān)的資源，因為高延遲幾乎總是處于爭用狀態(tài)的資源，無論是您的數(shù)據(jù)庫，還是Kafka隊列，或者其他什么。然后，要想理解為什么會出現(xiàn)這種情況，就要弄清楚一些工作負載是如何變化的，比如有人推出了新代碼，使數(shù)據(jù)庫調(diào)用的數(shù)量增加了100倍，這就是為什么我們的數(shù)據(jù)庫變得緩慢。這是一件有趣的事。您經(jīng)常會在事務(wù)處理速度緩慢、找到處于爭用狀態(tài)的資源，然后意識到有人將負載增加了100倍的情況下切換。同樣，從事務(wù)到資源再到資源，或者從事務(wù)到資源再到資源。這真的很難，因為現(xiàn)在人們在前端集成度量和跟蹤，但實際上需要在數(shù)據(jù)層集成它們才能實現(xiàn)這一點。這是一個非常困難的數(shù)據(jù)工程問題，因為數(shù)據(jù)實際上看起來非常不同。度量通常表示為時間序列統(tǒng)計數(shù)據(jù)，跟蹤通常表示為結(jié)構(gòu)化事件，不管它是否跨越日志，不管怎樣，它基本上是一組結(jié)構(gòu)化事件數(shù)據(jù)，而不是統(tǒng)計數(shù)據(jù)。很難在它們之間轉(zhuǎn)換。標(biāo)簽就是我們這樣做的方式。

最后，我做這件事已經(jīng)15年了，我一直在想這件事。沒有人應(yīng)該是這方面的專家才能使用它。它需要某種直觀的東西，并在日常工作流程中為人們帶來這些見解。如果我們不能做到這一點，那么我們基本上沒有成功地解決相互依賴問題。

服務(wù)級別目標(biāo)(SLOs)

SLOs是一個有用的工具。我只想在資源和事務(wù)的上下文中簡要介紹一下SLO。SLO是一個熱門話題。我認(rèn)為SLO就是目標(biāo)。它們是關(guān)于一組范圍限定為一組資源的事務(wù)的目標(biāo)。資源和事務(wù)是思考SLO的一種非常好的方式。我認(rèn)為“服務(wù)水平目標(biāo)”一詞，人們通常認(rèn)為，服務(wù)意味著微服務(wù)。不是真的。如果你像我一樣老了，你拿起電話，聽到撥號音，服務(wù)水平是99.99%的時間都是這樣，或者別的什么。它不一定是一個微型服務(wù)。服務(wù)級別只是說，事務(wù)有多可靠?這是否意味著他們不會經(jīng)常出錯，或者他們很快，或者你做了什么。您希望在某組資源的上下文中檢查該服務(wù)級別。這實際上就是微服務(wù)的用武之地。你也可以為其他事情設(shè)置SLO，同樣，Kafka隊列，數(shù)據(jù)庫，諸如此類的東西。通過這種方式，SLO可以表示這兩種雙重性之間的契約，一方是事務(wù)和資源，另一方是運營者和最終用戶。我認(rèn)為這是一種優(yōu)雅的方式來思考為什么SLO在連接這兩個不同世界方面如此重要和重要。

這在實踐中是什么樣子的?

我知道我到目前為止所說的都是理論上的。我決定用這些術(shù)語展示一個生產(chǎn)系統(tǒng)中真實事件的工作示例。它確實顯示了一些產(chǎn)品截圖的東西，但這不是演示或類似的東西。這只是為了幫助從概念上說明這在實踐中是如何發(fā)揮作用的，特別是在Kafka停機期間。

下面是儀表板中的一張圖表，顯示消費者對Kafka隊列的延遲，實際上是在Lightstep自己的內(nèi)部系統(tǒng)中。這不像是一次需要發(fā)生事故或?qū)蛻粲忻黠@影響的停機，但這肯定是人們爭先恐后地想弄清楚到底發(fā)生了什么。你可以看到，10點45分，一切都很好。然后他們變得不好了。經(jīng)典的情況是，Kafka本身就是一個分布式系統(tǒng)。它是一種資源，顯然出了問題，因為作為消費者，它做任何事情都變得非常緩慢。您必須等待很長時間才能從Kafka隊列中獲取任何數(shù)據(jù)。你想做什么?我認(rèn)為一種選擇是嘗試分組，并以各種方式對其進行過濾。我們真正想做的就是說，這個資源發(fā)生了什么變化?這個資源有很多事務(wù)要處理，很多事務(wù)實際上就在這里。另外，一筆事務(wù)就在這里進行。本期與本期之間的事務(wù)發(fā)生了哪些變化?這就是我作為一個操作員想要知道的，因為這可能會給我一個線索，因為Kafka的代碼沒有改變。工作量發(fā)生了變化。怎樣你應(yīng)該可以點擊這個東西。在這里，您可以看到查詢。

您應(yīng)該能夠單擊此更改，然后說，是什么導(dǎo)致了此更改?然后進入一個UI，我們說，好吧，這里是隊列不滿意的異常情況。這是它正常工作的基線。再次，我們只是放大看看這兩個時期是什么樣子。那么我們真正想做的是，從統(tǒng)計學(xué)上理解，這里的事務(wù)和那里的事務(wù)有什么不同?我們試圖理解的不僅僅是Kafka不開心，還有這里和這里的工作量有什么不同。美妙之處在于有標(biāo)簽。Kafka隊列有一個名稱。有關(guān)的主持人都有名字。通過Kafka隊列的跟蹤也使用這些標(biāo)記進行注釋。我們實際上可以從這個資源加入到工作負載中，并回答這個問題?；氐轿覄偛盘岬降哪切┐笮蚐QL表，我們可以說，讓我們看看通過這個特定Kafka隊列的跟蹤，因為這是大型表中的一列。讓我們看看在這兩個不同的時間窗口中通過特定隊列的跟蹤，并了解與此回歸相關(guān)的其他因素。

我們看到的是，在這個擁有許多不同客戶的多租戶系統(tǒng)中，有一個客戶的產(chǎn)品ID為1753，從占所有跟蹤的0.8%增加到幾乎占所有跟蹤的16%。這在基線和回歸之間大約增加了20倍。這真的很有趣。一些客戶顯著地改變了他們的工作量，而這正是我想要的。問題是，客戶標(biāo)簽的位置太高了。Kafka隊列中甚至沒有。只有通過從資源轉(zhuǎn)向分布式事務(wù)跟蹤，我們才能自動理解在這個回歸中涉及到一個特定的客戶ID。我們通過擴展得到更多的細節(jié)，比如說，好的，我們又增加了大約20倍。然后，如果您愿意，我們可以查看樣本跟蹤，以明確了解該客戶正在做什么。

我想說明的是，不需要寫任何查詢，就可以從這種感覺轉(zhuǎn)到這種感覺。您不需要成為專家就可以從資源轉(zhuǎn)向事務(wù)?，F(xiàn)在，實際上很難做到這一點?？傊?，總的來說。我認(rèn)為我對可觀察性的看法是，我們不再將度量、日志和跟蹤作為可觀察性的重點。這只是原始數(shù)據(jù)。相反，我們允許運營者了解其應(yīng)用程序在SLO方面的運行狀況，了解其資源的運行狀況，就像他們今天所做的那樣。然后自然地在這兩件事之間切換，而不必編寫查詢。了解事務(wù)工作負載如何影響資源，以及資源健康狀況如何影響事務(wù)工作負載，而無需舉手或做任何實際工作。

總結(jié)

事務(wù)遍歷系統(tǒng)，使用資源。用戶不關(guān)心您的資源。類似地，DevOps不能對單個事務(wù)做任何事情。他們只能對自己的資源進行操作，至少不能手動操作。我們必須能夠使用自然連接資源和事務(wù)的系統(tǒng)和提供者，以解決可觀察性中最重要的問題，即是什么導(dǎo)致了這種變化?無論是我事務(wù)的變化，還是我資源的變化。在這個資源和事務(wù)的框架內(nèi)，這就是我認(rèn)為可觀察性的真正方向。

問答

但是，你提到了存儲數(shù)據(jù)的成本。我認(rèn)為，對于人們來說，這總是一次非常棘手的談話。你在進行這些對話時有什么一般性的建議，這樣你可以最小化成本，同時最大限度地提高觀察力?

西格曼：現(xiàn)在肯定是個問題。關(guān)于這個話題，我有很多話要說。首先，我們想到的是，我們談?wù)摰氖鞘聞?wù)還是資源?也就是說，我們是在談?wù)摳櫤腿罩局惖臇|西，還是更像是統(tǒng)計時間序列數(shù)據(jù)，比如度量?因為我認(rèn)為這兩類遙測的對話是不同的。我們發(fā)現(xiàn)，至少在我在谷歌工作的時候，還有Lightstep，它不僅僅是一個二進制的東西。你保存數(shù)據(jù)還是不保存?這就像，你一開始就做樣品嗎?你能把它從主機上取下來嗎?您是否將其集中在廣域網(wǎng)上?你儲存多長時間?您存儲它的粒度是多少?在精度方面，它是如何隨時間降低的?當(dāng)你看到組織在這方面變得非常成熟時，他們實際上在整個遙測生命周期中有不同的答案。我認(rèn)為這是一個非常具有挑戰(zhàn)性的問題，因為它取決于您所談?wù)摰牧６取?/p>

我想說的主要一點是，如果一個組織沒有能力在整個生命周期(包括網(wǎng)絡(luò))中分析其遙測成本，而網(wǎng)絡(luò)實際上是生命周期成本中最大的組成部分之一，那么發(fā)送數(shù)據(jù)就是了。就像任何優(yōu)化問題一樣，你必須從這里開始。坦率地說，我認(rèn)為很多組織都無法對其進行分析。您不能說應(yīng)用程序的哪一部分導(dǎo)致了最長期的遙測成本。在你做到這一點之前，沒有辦法優(yōu)化它。我從那里開始。那么對于已經(jīng)這樣做的人來說，我認(rèn)為主要的事情是能夠控制單個開發(fā)人員的成本，比如添加一行代碼會給度量增加太多的基數(shù)。如果你做錯了，每年可能要花費數(shù)十萬美元。能夠在中心位置糾正這一點，我認(rèn)為是下一個重點。確保單個儀表線不能為平臺團隊帶來無限的成本。

但是，我真的很喜歡你最后的例子，你經(jīng)歷了一個已經(jīng)發(fā)生的事件，并在屏幕上分享。Ben提到了Lightstep，所以你可以看到它是如何工作的。我自己也用過。我覺得你能以如此快的速度找到一個真正的特定客戶做某個動作并引發(fā)一個事件，這真是太令人驚訝了。我自己也知道，在我從事生產(chǎn)系統(tǒng)的職業(yè)生涯中，這種情況已經(jīng)發(fā)生過很多次了，能夠以極快的速度達到非常小的粒度級別是非常有效的。

在給定的兩個時間間隔內(nèi)，能夠輸出重要差異的web界面是什么?你想談?wù)勥@個嗎?你對此的想法，比如不同的界面如何幫助人們做得更好?這是件大事。

西格曼：這是一篇社論。我猶豫了一下，不想表現(xiàn)出來。我不知道還有什么其他的方式來表現(xiàn)它。如果我不展示一些東西，我覺得這太抽象了。要回答字面上的問題，那是Lightstep的產(chǎn)品。如果可以在數(shù)據(jù)層進行集成，那么就沒有理由不能在其他地方進行集成。我認(rèn)為在實踐中很難做到的是，資源度量數(shù)據(jù)和事務(wù)跟蹤數(shù)據(jù)之間的集成必須在數(shù)據(jù)層完成。你不能僅僅通過超鏈接來實現(xiàn)。我所描述的連接實際上是一個連接。您必須能夠從度量中的標(biāo)記連接到數(shù)千條記錄道組上的標(biāo)記。要做到這一點，需要在平臺級別進行一些數(shù)據(jù)工程。事實上，我很想看到開源世界中有更多的解決方案朝著這個方向發(fā)展。事件解決的最短路徑當(dāng)然是能夠通過時間序列數(shù)據(jù)和事務(wù)數(shù)據(jù)之間的標(biāo)記進行透視。如果您必須從一個筒倉式度量解決方案和一個筒倉式跟蹤解決方案(如web UI)開始，那么這實際上是一個困難的問題，因為集成必須在數(shù)據(jù)層進行。從產(chǎn)品的角度來看，這就是為什么它如此棘手的原因。

但是，我看到一些平臺是在我工作過的地方內(nèi)部創(chuàng)建的，但是要讓它正常工作需要很多年和大量的迭代，所以一點也不容易。還有一件有趣的事，比如說，當(dāng)你訪問到這樣的系統(tǒng)時，比如說，你有一個客戶突然改變了他們的模式，但也許這很好。也許他們已經(jīng)接觸了所有這些新用戶，并且正在進行一系列令人驚嘆的工作，這意味著你可以對其他團隊，比如公司的業(yè)務(wù)部門說，“看起來這個客戶的工作真的很棒。你應(yīng)該知道。你知道我們正在這樣做嗎?”它使工程團隊能夠更好地與真正有趣和有洞察力的數(shù)據(jù)進行對話，我認(rèn)為這也很好。建議使用哪些工具進行跟蹤?它始終是一個服務(wù)網(wǎng)格或類似的東西，還是在系統(tǒng)內(nèi)部單獨執(zhí)行更好?

西格曼：是的。事實上，我在2017年在KubeCon做了一次關(guān)于服務(wù)網(wǎng)格和跟蹤的演講。服務(wù)網(wǎng)格是有幫助的，但它絕對不能解決問題。服務(wù)網(wǎng)格真正做的就是為您提供服務(wù)之間調(diào)用的遙測。跟蹤最困難的部分始終是成功地將此跟蹤ID上下文從服務(wù)的入口通過函數(shù)調(diào)用傳播到該服務(wù)的出口。服務(wù)網(wǎng)格與此無關(guān)。服務(wù)網(wǎng)格只處理服務(wù)之間的調(diào)用。它在服務(wù)中，是跟蹤中最困難的部分。這真的沒用。您最終會得到一組帶有服務(wù)網(wǎng)格的點對點數(shù)據(jù)，但要真正成功地解決上下文傳播問題，我唯一的建議是轉(zhuǎn)向OpenTelemetry。這實際上是試圖以一種相當(dāng)全面的方式解決這個問題，并使上下文傳播成為一種內(nèi)置功能。OpenTelemetry還將與服務(wù)網(wǎng)格集成。服務(wù)網(wǎng)格的部分優(yōu)勢在于它解決了跟蹤問題，但事實并非如此。它添加了用于跟蹤的數(shù)據(jù)，但沒有解決上下文傳播問題，而上下文傳播問題實際上是分布式跟蹤的核心。

但是，我看到一些平臺是在我工作過的地方內(nèi)部創(chuàng)建的，但是要讓它正常工作需要很多年和大量的迭代，所以一點也不容易。還有一件有趣的事，比如說，當(dāng)你訪問到這樣的系統(tǒng)時，比如說，你有一個客戶突然改變了他們的模式，但也許這很好。也許他們已經(jīng)接觸了所有這些新用戶，并且正在進行一系列令人驚嘆的工作，這意味著你可以對其他團隊，比如公司的業(yè)務(wù)部門說，“看起來這個客戶的工作真的很棒。你應(yīng)該知道。你知道我們正在這樣做嗎?”它使工程團隊能夠更好地與真正有趣和有洞察力的數(shù)據(jù)進行對話，我認(rèn)為這也很好。建議使用哪些工具進行跟蹤?它始終是一個服務(wù)網(wǎng)格或類似的東西，還是在系統(tǒng)內(nèi)部單獨執(zhí)行更好?

西格曼：是的。事實上，我在2017年在KubeCon做了一次關(guān)于服務(wù)網(wǎng)格和跟蹤的演講。服務(wù)網(wǎng)格是有幫助的，但它絕對不能解決問題。服務(wù)網(wǎng)格真正做的就是為您提供服務(wù)之間調(diào)用的遙測。跟蹤最困難的部分始終是成功地將此跟蹤ID上下文從服務(wù)的入口通過函數(shù)調(diào)用傳播到該服務(wù)的出口。服務(wù)網(wǎng)格與此無關(guān)。服務(wù)網(wǎng)格只處理服務(wù)之間的調(diào)用。它在服務(wù)中，是跟蹤中最困難的部分。這真的沒用。您最終會得到一組帶有服務(wù)網(wǎng)格的點對點數(shù)據(jù)，但要真正成功地解決上下文傳播問題，我唯一的建議是轉(zhuǎn)向OpenTelemetry。這實際上是試圖以一種相當(dāng)全面的方式解決這個問題，并使上下文傳播成為一種內(nèi)置功能。OpenTelemetry還將與服務(wù)網(wǎng)格集成。服務(wù)網(wǎng)格的部分優(yōu)勢在于它解決了跟蹤問題，但事實并非如此。它添加了用于跟蹤的數(shù)據(jù)，但沒有解決上下文傳播問題，而上下文傳播問題實際上是分布式跟蹤的核心。

但是，關(guān)于OpenTelemetry還有一個問題。你的想法是什么?

西格曼：我是管理委員會的成員，是這個項目的共同創(chuàng)立者，我對此極有偏見。從擁有眾多貢獻者的角度來看，這確實是一個非常成功的項目。我認(rèn)為僅在上個月我們就有1000名投稿人。每個主要的供應(yīng)商和云提供商都已經(jīng)購買了該項目，并且正在為該項目配備人員等等。OpenTelemetry的唯一問題是它有太多的活動，以至于我們在維護項目時遇到了一些困難。我認(rèn)為它之所以如此成功，是因為它使許多方面受益。對于主要的基礎(chǔ)設(shè)施提供商、云提供商、可觀測性供應(yīng)商，尤其是最終用戶來說，這是一個雙贏的局面，因為您最終可以獲得高質(zhì)量的遙測，而無需與任何特定的供應(yīng)商或提供商綁定。這種便攜性是一件非常吸引人的事情。我認(rèn)為，長期以來，可觀測性解決方案一直受到它們所能收集的遙測數(shù)據(jù)質(zhì)量的限制。OpenTelemetry真的將掀起這股浪潮，然后您將看到解決方案的改進。OpenTelemetry，是的，這是一個非常激動人心的項目。我認(rèn)為我們唯一真正需要的就是能夠在項目中說一點不，這樣我們就能達到我們的里程碑。在某種程度上，它是自身成功的犧牲品。它肯定有一個光明的未來。

但是，對于今年剛剛結(jié)束的OpenTelemetry的路線圖，你有什么要分享的嗎?有什么讓你興奮的事情嗎?

西格曼：跟蹤、度量和日志這三大支柱對于可觀察性來說沒有任何意義。我會堅持我的觀點。它們對遙測技術(shù)來說絕對有意義，所以這三個方面。我們從追蹤開始。到目前為止基本上都是這樣。指標(biāo)很快就要出來了。然后日志記錄將在稍后出現(xiàn)。我認(rèn)為從標(biāo)準(zhǔn)和API集成的角度來看，這實際上是OpenTelemetry要解決的三個問題中最不重要的一個。我很高興指標(biāo)能夠超過這一點。我們還與普羅米修斯社區(qū)進行了大量的合作，以確保普羅米修斯和OpenTelemetry之間的互操作，這樣您就不會被迫做出選擇。我認(rèn)為這也是一件非常好的事情，看到今年夏天穩(wěn)定下來。

但是，關(guān)于分布式跟蹤的性能成本，還有一個常見的問題。你的想法是什么?

Sigelman：從延遲的角度來看，分布式跟蹤不需要任何開銷。在占用資源的意義上，存在一些最小的邊際吞吐量開銷。通常，人們可以采取一些抽樣來解決這個問題。我在谷歌幫助撰寫的這篇短小精悍的論文詳細描述了我們對績效的衡量。從統(tǒng)計噪音的角度看，這是難以察覺的，Dapper 100%的時間都在運行100%的谷歌服務(wù)，并且已經(jīng)運行了15年。如果做得正確，這絕對不是一件高開銷的事情。這就是它的魅力之一。

本文轉(zhuǎn)載自微信公眾號「超級架構(gòu)師」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系超級架構(gòu)師公眾號。