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

事務(wù)

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

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

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

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

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

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

資源是什么?

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

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

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

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

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

相互依存

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

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

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

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

DevOps工程師/SRE要做什么?

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

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

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

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

這在實(shí)踐中是什么樣子的?

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

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

您應(yīng)該能夠單擊此更改，然后說(shuō)，是什么導(dǎo)致了此更改?然后進(jìn)入一個(gè)UI，我們說(shuō)，好吧，這里是隊(duì)列不滿意的異常情況。這是它正常工作的基線。再次，我們只是放大看看這兩個(gè)時(shí)期是什么樣子。那么我們真正想做的是，從統(tǒng)計(jì)學(xué)上理解，這里的事務(wù)和那里的事務(wù)有什么不同?我們?cè)噲D理解的不僅僅是Kafka不開(kāi)心，還有這里和這里的工作量有什么不同。美妙之處在于有標(biāo)簽。Kafka隊(duì)列有一個(gè)名稱。有關(guān)的主持人都有名字。通過(guò)Kafka隊(duì)列的跟蹤也使用這些標(biāo)記進(jìn)行注釋。我們實(shí)際上可以從這個(gè)資源加入到工作負(fù)載中，并回答這個(gè)問(wèn)題。回到我剛才提到的那些大型SQL表，我們可以說(shuō)，讓我們看看通過(guò)這個(gè)特定Kafka隊(duì)列的跟蹤，因?yàn)檫@是大型表中的一列。讓我們看看在這兩個(gè)不同的時(shí)間窗口中通過(guò)特定隊(duì)列的跟蹤，并了解與此回歸相關(guān)的其他因素。

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

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

總結(jié)

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

問(wèn)答

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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