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

事務

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

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

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

跟蹤只是跨事務的連接

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

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

資源是什么?

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

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

在我看來，這些標簽或屬性的用途是多方面的。當然，你只是想理解和分解。如果您看到這樣的峰值，您可能希望按區域分組，或按集群ID分組，或類似的方式。那很好。您應該能夠在時間序列數據庫中執行此操作。更重要的是，這些標簽是溝通資源和事務的通用語言。理想情況下，當事務跨越資源時，該事務會以某種方式對該資源進行注釋。它可以作為從事務數據連接到資源數據的一種方式，反之亦然。這是一個非常強大的東西。稍后，當我們進入一個實際的例子時，我將討論這個問題。

資源也是一個層次結構

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

相互依存

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

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

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

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

DevOps工程師/SRE要做什么?

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

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

服務級別目標(SLOs)

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

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

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

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

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

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

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

總結

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

問答

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

西格曼：現在肯定是個問題。關于這個話題，我有很多話要說。首先，我們想到的是，我們談論的是事務還是資源?也就是說，我們是在談論跟蹤和日志之類的東西，還是更像是統計時間序列數據，比如度量?因為我認為這兩類遙測的對話是不同的。我們發現，至少在我在谷歌工作的時候，還有Lightstep，它不僅僅是一個二進制的東西。你保存數據還是不保存?這就像，你一開始就做樣品嗎?你能把它從主機上取下來嗎?您是否將其集中在廣域網上?你儲存多長時間?您存儲它的粒度是多少?在精度方面，它是如何隨時間降低的?當你看到組織在這方面變得非常成熟時，他們實際上在整個遙測生命周期中有不同的答案。我認為這是一個非常具有挑戰性的問題，因為它取決于您所談論的粒度。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文轉載自微信公眾號「超級架構師」，可以通過以下二維碼關注。轉載本文請聯系超級架構師公眾號。