Edgar通過對請求追蹤（tracing）、日志（logs）、分析（analysis）和元數據（metadata）的總結展示，幫助Netflix團隊有效地對分布式系統進行故障診斷。
每個人都喜歡未解之謎。總有人看起來像是罪魁禍首。有一個明確的動機，一個完美的機會和一個遺留下來的犯罪痕跡。然而，這是個未解之謎！事情從來沒有這么簡單。無論是電視機后面的一張神秘的便條，還是關鍵時刻來自未知號碼的神秘電話，這些片段很少能完美地結合在一起。作為神秘愛好者，我們想回答一個古老的問題：偵探小說；我們想了解到底發生了什么。
對於工程師來說，問題往往是“什么失敗了，為什么失敗了？“，一旦出現問題，我們就戴上偵探帽，通過收集證據開始破案過程。系統越復雜，尋找線索的地方就越多。一個工程師可以發現自己在挖掘日志，仔細研究痕跡，盯着幾十個儀表盤。
所有這些來源都使我們很難知道從何處開始，並增加找出問題所在的時間。盡管如此豐富的儀表盤和信息並非Netflix獨有，但在我們的微服務體系結構中確實如此。每一個微服務可能很容易理解和單獨調試，但是當組合到一個請求中時會怎樣呢？尋找關鍵證據就像是大海撈針。
Edgar中的調用圖示例
在某些情況下，我們要回答的問題是："現在發生了什么？"，問題沒有解決的每一秒鍾都會帶來沉重的代價。我們希望盡快解決這個問題，這樣我們的網站會員就可以恢復享受他們最喜歡的電影和節目。
對於構建可觀察性工具的團隊來說，問題是：我們如何讓理解一個系統的行為變得快速、易消化？快速解析，即使你對該系統的內部運作和復雜程度不是很熟悉，也能輕松地指出哪里出了問題？
在Netflix，我們已經用一套可觀察性工具回答了這個問題。在之前的一篇博文中，我們討論了Telltale，我們的健康監測系統。
Telltale可以告訴我們一個應用程序何時不健康，但有時我們需要更精細的洞察力。我們需要知道為什么一個特定的請求會失敗，以及失敗的原因。
我們構建Edgar就是為了減輕這種負擔，通過對請求跟蹤、日志、分析和元數據的匯總展示，讓我們的用戶能夠高效地排除分布式系統的故障。
Edgar是什么？
Edgar是一個用於分布式系統故障排除的自助服務工具，它建立在請求跟蹤的基礎上，並在上面添加了額外的上下文。通過請求跟蹤和來自日志、事件、元數據和分析的額外數據，Edgar能夠顯示請求在我們的分布式系統中的流程：哪些服務被調用中，哪些信息從一個服務傳遞到下一個服務，在這個服務內部發生了什么，花了多長時間，發出了什么狀態，並突出顯示可能發生問題的地方。如果你熟悉Zipkin或OpenTelemetry等平台，這可能聽起來很熟悉。但是，在Edgar如何處理其數據和用戶方面，有一些實質性的差異：
-
雖然Edgar是建立在請求跟蹤（tracing）之上的，但它也使用跟蹤（tracing）作為線程，將額外的上下文聯系在一起。正如Cindy Sridharan在這篇博文中所闡述的那樣，僅僅從跟蹤數據中獲取有意義的價值是很有挑戰性的。除了跟蹤（tracing）數據，Edgar還從日志、事件和元數據中提取額外的上下文，通過篩選來確定有價值的相關信息，這樣Edgar就可以直觀地突出錯誤發生的位置，並提供詳細的上下文。
-
Edgar可以100%捕捉到有趣的痕跡，而不是抽取固定比例的小流量。這種差異在技術上有很大的影響，從對有趣的傳輸內容進行分類，到成本效益的存儲（請關注Netflix技術博客后面涉及這些主題的文章）。
-
Edgar為工程師和非工程師都提供了強大的、可消費的用戶體驗。如果你接受了存儲大量痕跡的成本和復雜性，你就會希望從這種成本中獲得最大的價值。有了Edgar，我們發現我們可以通過為其他團隊（如客戶服務運營）策划體驗來利用這種價值，我們已經接受了建立一個產品的挑戰，使跟蹤數據易於訪問，易於搜索，並易於獲得多個用戶角色的洞察力。
Tracing 是基礎
日志、度量和追蹤（tracing）是可觀察性的三大支柱：
- 度量指標在宏觀上傳達正在發生的事情
- 追蹤（tracing）說明了一個孤立請求的生態系統
- 而日志則提供了一個細節豐富的服務內部發生的快照
這些支柱具有巨大的價值，業界圍繞每個支柱投入大量資金構建令人印象深刻的儀表盤和工具也就不足為奇了。缺點是，我們有這么多的儀表盤。在一個請求中只打十個服務，可能有十個不同的分析儀表板和十個不同的日志存儲。但是，一個請求有它自己獨特的跟蹤標識符，它是把這個請求的所有部分聯系在一起的共同線。Tracing ID通常是在接收請求的第一個服務處生成，然后作為頭值從一個服務傳遞到另一個服務。這使得Tracing 成為一個很好的起點，可以將這些數據統一在一個集中的位置：
- Tracing是一組段，代表整個系統中單個請求的每一步。分布式Tracing是在分布式系統中生成、傳輸、存儲和檢索Tracing的過程。當一個請求在服務之間流動時，每一個不同的工作單元都被記錄為一個跨度。一個Tracing是由許多跨度組成的，這些跨度用一個跟蹤ID組合在一起，形成一個單一的、端到端的保護傘。一個跨度。
- 代表一個工作單位，如一個服務到另一個服務的網絡調用（客戶機/服務器關系）或一個純粹的內部操作（如啟動和結束一個方法）。
- 通過父/子關系與其他跨度相關。
- 包含一組稱為標簽的鍵值對，服務所有者可以在其中附加有用的值，如 urls、版本號、區域、相應的 ID 和錯誤。標簽可以與錯誤或警告相關聯，Edgar可以在請求的圖上直觀地顯示。
Tracing 有一個開始時間和結束時間，由於有了這些時間戳，用戶就可以快速看到操作的時間。Tracing以及它的底層跨度)允許我們按時間順序用圖形展示請求。
基於Jaegar UI的時間線視圖的跟蹤時間線視圖示例。
在Tracing中添加上下文
僅僅通過分布式跟蹤，Edgar就能夠畫出請求流經不同系統時的路徑。這種集中式的視圖對於確定哪些服務被攻擊以及何時被攻擊非常有幫助，但它缺乏細微的差別。一個標簽可能表明有一個錯誤，但並不能完全回答發生了什么問題。在圖片中添加日志可以提供很大的幫助。有了日志，用戶可以看到服務本身對出錯的情況有什么說法。如果一個數據獲取器失敗了，日志可以告訴你它運行的是什么查詢，到底是什么ID或字段導致了失敗。光是這一點就可以給工程師提供重現問題所需的知識。在Edgar中，我們對日志進行解析，尋找錯誤或警告值。我們將這些錯誤和警告添加到我們的UI中，在我們的調用圖中高亮顯示它們，並將它們與一個給定的服務清晰地關聯起來，使用戶可以輕松地查看我們發現的任何錯誤。
有了Tracing和來自日志的額外上下文來說明問題，下一個問題可能是這個單獨的Tracing如何與每個服務的整體健康和行為相匹配。這是一個異常還是我們在處理一個模式？為了幫助回答這個問題，Edgar從合作伙伴Telltale應用中引入了異常檢測。Telltale為Edgar提供了延遲基准，它表明了單個Tracing的延遲對於這個給定的服務是否是異常的。單單一個Tracing就可以告訴你，一個服務需要500ms的響應時間，但是需要深入了解某個服務的典型行為，才能判斷這個響應時間是否是異常值。Telltale的異常分析可以查看歷史行為，並能評估這個Tracing所經歷的延遲是否異常。有了這些知識，Edgar就可以直觀地警告服務中發生了什么事情，導致其延遲超出了正常范圍。
Edgar應該減負，而不是增加負擔
在一個界面中呈現所有這些數據，減少了工程師發現每個源的工作量。然而，發現只是解決路徑的一部分。有了所有的證據，並由Edgar總結，工程師可能會知道什么地方出了問題，哪里出了問題。這是向解決方法邁出的一大步，但還不值得慶祝。根源可能已經確定，但誰是問題服務的主人？很多時候，找到正確的聯系人需要跳到Slack或公司目錄中，這需要花費更多的時間。在Edgar中，我們已經整合了我們的服務，在應用中提供這些信息以及追蹤的細節。對於任何配置了所有者和支持渠道的服務，Edgar提供了服務的聯系郵件和他們的Slack渠道的鏈接，使一方與另一方的交接更加順暢。如果工程師確實需要將一個問題傳遞給另一個團隊或人員，Edgar的請求詳情頁包含了所有的上下文：跟蹤、日志、分析，並且很容易共享，無需編寫詳細的描述或提供一系列的鏈接來溝通問題。
Edgar的一個重要使命是將用戶和服務所有者的負擔降到最低。有了所有的數據源，數據的數量可能會變得不堪重負。對於Edgar來說，保持一個優先級的界面是非常重要的，它可以向用戶突出顯示錯誤和異常，並協助用戶進行下一步的解決。隨着我們UI的發展，在如何處理新的數據源時，重要的是要有鑒別力和判斷力，將它們編織到我們現有的錯誤和警告模型中，以最大限度地減少干擾並促進快速理解。我們非常重視焦點小組和用戶反饋，以確保緊密的反饋循環，從而使Edgar能夠隨着用戶服務和用例的發展而不斷滿足他們的需求。
隨着服務的發展，他們可能會改變他們的日志格式或使用新的標簽來指示錯誤。我們建立了一個管理頁面，給我們的服務所有者提供這種可配置性，並使我們的產品與深入的服務知識脫鈎。服務所有者可以配置他們的日志存儲的基本細節，例如他們的日志在哪里，以及他們對跟蹤ID和跨度ID使用什么字段。了解他們的跟蹤ID和跨度ID，才能使Edgar將跟蹤和日志關聯起來。不過除此之外，他們的日志有什么特殊性呢？有些字段可能是不相關的，或者是已經廢棄的，團隊希望默認隱藏它們。或者，有些字段包含了最重要的信息，通過在Edgar UI中推廣這些字段，他們能夠更快地查看這些字段。這種自助服務配置有助於減輕服務所有者的負擔。
Edgar的初始日志配置
使用Edgar
為了讓用戶在時間緊迫的情況下求助於Edgar，用戶需要能夠信任Edgar。特別是，他們需要能夠指望Edgar擁有關於他們問題的數據。許多分布式追蹤的方法涉及到設置一個采樣率，比如5%，然后只追蹤這個百分比的請求流量。而Edgar的任務是捕捉100%的有趣請求，而不是固定的采樣率。因此，當發生錯誤時，Edgar的用戶可以確信他們能夠找到錯誤。這是Edgar定位為可靠來源的關鍵。Edgar的方法是做出了一個承諾，即擁有關於某個問題的所有的數據。
除了存儲所有請求的跟蹤數據外，Edgar還實現了一個功能，可以根據用戶的決定，針對給定的標准按需收集額外的細節。當這種細粒度的追蹤功能開啟時，Edgar會捕獲請求和響應的有效載荷，以及與用戶標准相匹配的請求頭。這就更清楚地說明了哪些數據是通過請求路徑從服務傳遞到服務的。雖然這種粒度水平對於所有請求流量來說是不可持續的，但在有針對性的用例中，它是一個強大的工具，特別是對於那些被證明具有挑戰性的重現錯誤。
正如你可以想象的那樣，這帶來了非常真實的存儲成本。雖然Edgar團隊已經盡力有效地管理這些成本，並優化我們的存儲，但成本並不小。加強我們投資回報率的一個方法是成為整個軟件開發生命周期的關鍵工具。Edgar是運營和維護生產服務的重要工具，縮短恢復時間對客戶有直接影響。工程師們在整個開發和測試過程中也依賴我們的工具，他們使用Edgar請求頁面在團隊間交流問題。
通過向多組用戶提供我們的工具，我們能夠更有效地利用我們的成本。Edgar已經不僅僅是工程師的工具，而是成為Netflix任何需要排除服務故障的人的工具。在Edgar早期，當我們努力在痕跡數據之上建立有價值的抽象時，Edgar團隊首先瞄准了流媒體視頻用例。我們為流媒體視頻建立了一個精心策划的體驗，將請求分組到播放會話中，通過開始和停止播放給定的資產進行標記。我們發現這種體驗對於客服運營以及工程團隊來說都是非常強大的。我們的團隊聽取了客服運營的意見，了解哪些常見的問題造成了過多的支持痛苦，這樣我們就可以在UI中總結這些問題。這使客服運營以及工程師能夠以最少的挖掘來快速了解會員問題。通過對痕跡進行邏輯分組，並在更高層次上總結行為，痕跡數據在回答諸如為什么會員沒有收到某個標題的4k視頻或為什么會員無法觀看某些內容等問題時變得非常有用。
在Edgar中查看回放會話的一個錯誤示例。
為Studio擴展Edgar
隨着Netflix工作室方面的發展，我們意識到我們的電影和節目制作支持將從類似的用戶活動匯總中受益。我們的電影和節目制作支持可能需要回答為什么制作組的某個人無法登錄或訪問他們的某個項目的材料。當我們努力為這個新的用戶群體服務時，我們試圖了解我們的制作支持最需要回答的問題，然后將各種數據源聯系在一起，在Edgar中回答這些問題。
Edgar團隊建立了一個滿足這一需求的體驗，用跟蹤數據建立了另一個抽象；這一次，重點是解決與生產相關的用例和應用的問題，而不是流媒體視頻會話。Edgar為我們的生產支持提供了通過姓名或電子郵件搜索某個承包商、供應商或生產人員成員的能力。在找到這個人之后，Edgar會進入許多日志存儲中尋找他們的用戶ID，然后將他們的登錄歷史、角色訪問變更日志以及最近從生產相關應用程序中發出的痕跡匯總在一起。
Edgar在這些數據中掃描出錯誤和警告，然后將這些錯誤直接呈現在前面。也許某個供應商試圖用錯誤的密碼登錄太多次，或者他們在生產中被分配了一個錯誤的角色。在這個新的領域中，Edgar通過將信息捆綁在一起，並將用戶指向下一步的解決方法，來解決同樣的多儀表板問題。
一個與生產相關的用戶的錯誤示例
Edgar是什么，不是什么
Edgar的目標不是要成為萬能的工具，也不是要成為萬能的工具。相反，我們的目標是作為一個故障排除的向導：Edgar應該能夠快速引導用戶理解一個問題，並將他們帶到下一個位置，在那里他們可以補救這個問題。 比方說，一個生產供應商由於角色/權限分配不正確而無法訪問他們生產的材料，這個生產供應商向支持部門求助，要求協助排除故障。當支持用戶搜索到這個供應商時，Edgar應該能夠指出這個供應商最近有一個角色變化，並總結這個角色變化是什么。他們沒有被分配到《死神給我》第二季，而是被分配到了第一季。 在這種情況下，Edgar的目標是幫助支持用戶得出這個結論，並快速引導他們到合適的角色哪兒，去快速糾正解決問題，而不是掌握整個解決方案。
在Netflix的使用情況
雖然Edgar是圍繞Netflix的核心流媒體視頻使用案例而創建的，但后來它已經發展到涵蓋了廣泛的應用。雖然Netflix流媒體視頻被數百萬會員使用，但一些使用Edgar的應用可能以每分鍾的請求量而不是每秒的請求量來衡量，而且可能只有幾十個或幾百個用戶，而不是數百萬。雖然我們一開始是通過策划的方式來解決從事流媒體視頻工作的工程師和支持的痛點，但我們發現這個痛點是與規模無關的。對於所有工程師來說，無論他們是在構建一個由30人大量使用的預算預測應用，還是一個由數百萬人使用的SVOD應用，找到問題的根源都是昂貴的。
今天，Netflix的許多應用和服務，涵蓋了廣泛的類型和規模，發布的跟蹤數據可以在Edgar中訪問，從服務所有者到客戶服務運營的團隊都依賴於Edgar的洞察力。從流媒體到工作室，Edgar利用其豐富的知識，以相同的基本方法，總結請求跟蹤、日志、分析和元數據，加快跨應用程序的故障排除。
當你坐在沙發上觀看一集新的《未解之謎》時，你可能會發現自己的問題比答案還多。為什么受害者會突然離開家？嫌疑人怎么會憑空消失？等等，有多少人看到了那個UFO？不幸的是，Edgar無法在那里幫助你（相信我，我們也很失望）。但是，如果你的休閑夜晚被故障停機而打斷，Edgar會在幕后幫助Netflix工程師解決手頭的謎團。
保持服務的正常運行，讓Netflix能夠與全球的會員分享故事。在每一次中斷和故障的背后，都有一個故事要講，而講這個故事需要強大的可觀察性工具。如果你對可觀察性充滿熱情，那就來和我們聊聊吧。
原文
https://netflixtechblog.com/edgar-solving-mysteries-faster-with-observability-e1a76302c71f