作為知名的流媒體巨頭，Netflix 在全球擁有近 2 億訂閱用戶，服務遍及多個國家。本文闡述了 Netflix 的系統(tǒng)監(jiān)控實踐：自研 Telltale，成功運行并監(jiān)控著 Netflix 100 多個生產(chǎn)應用程序的運行狀況。

相信很多運維人都有過這樣的經(jīng)歷：

監(jiān)控系統(tǒng)某個指標超過閾值，觸發(fā)告警。大半夜里，你被緊急召喚。半睜著眼，你滿臉疑惑：“系統(tǒng)真出問題了嗎，還是僅僅需要調(diào)整下告警？上一次有人調(diào)整我們的告警閾值是在什么時候？有沒有可能是上游或者下游的服務出現(xiàn)了問題？”

鑒于這是一次非常重要的應用告警，因此你不得不從床上爬起來，迅速打開電腦，然后瀏覽監(jiān)控儀表盤來追蹤問題源頭。忙了半天，你還沒確認這個告警是來自于系統(tǒng)的問題，但也意識到，從海量數(shù)據(jù)中尋找線索時，時間正在流逝。你必須盡快定位告警的原因，并祈禱系統(tǒng)穩(wěn)定運行。

對我們的用戶來講，穩(wěn)健的 Netflix 服務至關重要。當你坐下來看《養(yǎng)虎為患》時，你肯定希望它能順利播放。

多年來，我們從經(jīng)常在深夜被召喚的工程師那里了解到應用程序監(jiān)控的痛點：

• 過多的告警

• 太多滾動瀏覽的儀表盤

• 太多的配置

• 過多的維護

https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249

我們的流媒體團隊需要一個全新的監(jiān)控系統(tǒng)，可以讓團隊成員快速地診斷和修復問題；因為在系統(tǒng)告警的緊急情況下，每一秒都至關重要！我們的 Node 團隊 需要一個僅需一小撮人就能運維大型集群的系統(tǒng)。

因此，我們構建了 Telltale。

Telltale 監(jiān)控時間軸

1. 匯集監(jiān)控數(shù)據(jù)源，創(chuàng)建整體監(jiān)控視圖

Telltale 匯集了各種監(jiān)控數(shù)據(jù)源，從而能創(chuàng)建關于應用程序運行狀況的整體監(jiān)控視圖。

2. 多維度判斷應用程序的健康狀況

Telltale 可以通過多個維度判斷一個應用程序的健康情況，而無需根據(jù)單一指標頻繁調(diào)整告警閾值。

3. 及時告警

因為我們知道應用程序在什么情況下是正常的，所以能在應用程序有異常趨勢時及時通知應用程序的所有者。

4. 顯示關鍵數(shù)據(jù)

指標是了解應用程序運行狀態(tài)的關鍵。但很多時候，你擁有太多的指標、太多的圖表以及太多的監(jiān)控儀表盤。而 Telltale 僅顯示應用程序中有用的相關數(shù)據(jù)及其上游和下游服務的數(shù)據(jù)。

5. 用顏色區(qū)分問題的嚴重程度

我們使用不同的顏色來表示問題的嚴重程度（除選擇顏色之外，還可以讓 Telltale 顯示不同的數(shù)字），以便運維人員一眼就能判斷出應用程序的運行狀況。

6. 高亮提示

我們還會對一些監(jiān)控事件進行高亮提示，比如局部區(qū)域的網(wǎng)絡流量疏散及就近的 服務部署，這些信息對于全面了解服務的健康情況至關重要，尤其是在真正發(fā)生系統(tǒng)故障的情況下。

這就是我們的 Telltale 監(jiān)控。它現(xiàn)已成功運行并提供監(jiān)控服務，監(jiān)控著 Netflix 100 多個生產(chǎn)應用程序的運行狀況。

微服務并非是孤立存在和運行的。它需要特定的依賴，與其他服務進行數(shù)據(jù)交互，甚至位于不同的AWS區(qū)域。

上面的調(diào)用圖是一個相對簡單的圖，其中涉及許多服務，實際的調(diào)用鏈可能會更深更復雜。一個應用程序是系統(tǒng)生態(tài)的一部分，它的運行狀態(tài)可能會受到相關屬性變化的微弱影響，也有可能會受到區(qū)域范圍內(nèi)某些事件的影響從而發(fā)生根本性改變。canary的啟動可能會對應用程序產(chǎn)生一定影響。在一定程度上，上游或下游服務的部署同樣也可以帶來一定的影響。

https://netflixtechblog.com/automated-canary-analysis-at-netflix-with-kayenta-3260bc7acc69

Telltale 通過使用多個維度的數(shù)據(jù)源構建一個不斷自我優(yōu)化的模型來監(jiān)控應用程序的健康度：

• Atlas 時序指標

• 區(qū)域網(wǎng)絡流量疏散

• Mantis 實時流數(shù)據(jù)

• 基礎架構變更事件

• Canary 部署及使用

• 上、下游服務的運行狀況

• 表征 QoE 的相關指標

• 告警平臺發(fā)出的報警

不同的數(shù)據(jù)源對應用程序健康度的影響權重不同。例如，與錯誤率增加相比，響應時間的增加對應用程序的影響要小很多；錯誤代碼有很多，但是某些特定的錯誤代碼的影響要比其他錯誤代碼的影響大。

在服務下游部署 canary 可能不如在上游部署帶來的效果明顯

區(qū)域網(wǎng)絡流量轉移意味著某個區(qū)域的網(wǎng)絡流量降為零而另一個區(qū)域的網(wǎng)絡流量會加倍。你可以感受下不同的指標對于監(jiān)控的影響。監(jiān)控指標的具體含義決定了我們應該如何科學有效地使用它來進行監(jiān)控。

https://netflixtechblog.com/project-nimble-region-evacuation-reimagined-d0d0568254d4

在構建應用程序健康狀況視圖時，Telltale 考慮了所有這些因素。

應用程序健康評估模型是 Telltale 的核心。

每個服務運維人員都知道告警閾值調(diào)整的難度。將閾值設置得太低，你會收到大量虛假告警。如果過度補償并放寬告警閾值，就會錯過重要的異常警告。這樣導致的最終結果是對告警缺乏信任。Telltale 可以幫助你免除不斷調(diào)整相關配置的繁瑣工作。

通過提供準確的和嚴格管理的數(shù)據(jù)源，我們能讓應用程序所有者的設置和配置過程變得更加容易。這些數(shù)據(jù)源通過按照一定的組合應用到程序的配置中，以實現(xiàn)最常見的服務類型配置。

Telltale 可以自動追蹤服務之間的依賴關系，以構建應用程序健康評估模型中的拓撲。通過數(shù)據(jù)源管理以及拓撲監(jiān)測，在不用付出很大的努力情況下就能使配置保持最新狀態(tài)。那些需要手動實踐的一些場景仍然支持手動配置和調(diào)整。

沒有任何一個獨立的算法可以適用我們所有的監(jiān)控場景。因此，我們采用了混合算法，包括統(tǒng)計算法、基于規(guī)則的算法和機器學習算法。

不久后，我們將在 Netflix Tech Blog 上發(fā)表一篇針對我們監(jiān)控算法的文章。

Telltale 還具有分析器，可用于趨勢探測或內(nèi)存泄漏監(jiān)測。智能監(jiān)控意味著我們的用戶可以信賴我們的監(jiān)控結果。這表明故障發(fā)生時，用戶能更快地定位和解決系統(tǒng)異常問題。

智能監(jiān)控必然會促進智能告警。當 Telltale 檢測到應用程序中的運行異常時，就會產(chǎn)生異常事件。團隊可以選擇通過 Slack、電子郵件或 PagerDuty（均由我們的內(nèi)部告警系統(tǒng)提供支持）進行告警。

如果該異常問題是由上游或下游系統(tǒng)引起的，則 Telltale 的上下文感知路由會提醒服務對應的維護團隊。智能告警還意味著運維團隊針對特定異常只會收到一個通知，也就是說，告警風暴已經(jīng)成為過去式。

Slack 中的 Telltale 通知示例

在系統(tǒng)出現(xiàn)問題時，掌握準確的信息至關重要。我們的 Slack 告警程序還會啟動一個包含有關事件上下文信息的線程，提供 Telltale 識別到的異常問題信息及問題產(chǎn)生的原因。正確的上下文可以方便我們了解應用程序的當前狀態(tài)，以便值班運維的工程師能有針對性的定位和修復問題。

異常告警事件會不斷發(fā)展而且擁有自己的生命周期，因此及時更新事件狀態(tài)至關重要。告警異常是好轉了還是惡化了？是否要考慮新的監(jiān)控信息或事件？Telltale 在當前事件發(fā)生改變時會更新 Slack 線程。系統(tǒng)返回正常狀態(tài)后，該線程將被標記為“已解決”，因此用戶一眼就能知道哪些異常事件正在處理中，哪些異常事件已成功修復。

這些 Slack 線程不僅僅適用于 Telltale。團隊還可以用它們來共享有關事件的其他數(shù)據(jù)，方便進一步觀察、理論分析和討論。異常信息數(shù)據(jù)和討論全部集中在一個線程中，方便達成針對當前異常的共識，有利于更快提出問題的解決方案以及異常事件的事后分析。

我們致力于提高 Telltale 告警的質量。一種方法是向我們的用戶學習。因此，我們在 Slack 消息中提供了反饋按鈕。用戶可以告訴我們以后某些情況不需要再發(fā)生告警，或提供某些告警不合理的原因。智能告警意味著用戶可以信賴我們的告警。

在 Slack 的 Telltale 通知中描述異常詳細信息的一個示例

各種類型的監(jiān)控數(shù)據(jù)、應用程序相關知識以及跨多種服務數(shù)據(jù)的相關性，有助于 Telltale 檢測分析應用程序運行健康度降低的原因。這些原因包括實例異常、相關依賴的監(jiān)測和部署異常、數(shù)據(jù)庫異?；蛘呔W(wǎng)絡流量高峰等。突出高亮顯示這些可能的原因可以幫助運維人員節(jié)省大量寶貴的時間。

Telltale 異常事件摘要的一個示例

當 Telltale 發(fā)送告警時，它還會創(chuàng)建一個快照，其中引用了不正常的監(jiān)控信號數(shù)據(jù)。隨著新監(jiān)控信息的到來，會將其添加到此快照中。這簡化了團隊的很多事后審查流程。當需要復查過去的異常問題時，“應用程序事件摘要”功能可以從各個方面顯示當前的問題，包括一些關鍵指標，比如總停機時間和 MTTR（平均解決時間）。我們希望幫助我們的團隊了解更多的異常事件的模式，以便提高我們服務的整體可用性。

集群視圖下將相似異常事件分組

可以看出，Telltale 的應用程序健康評估模型及其智能監(jiān)控功能非常強大，所以我們也會將其應用于安全部署方面。我們從開放源碼交付平臺 Spinnaker 開始測試。

https://spinnaker.io/

隨著 Spinnaker 逐漸推出新版本，我們使用 Telltale 連續(xù)監(jiān)監(jiān)控運行新版本實例的運行狀態(tài)。持續(xù)監(jiān)控意味著新部署在問題出現(xiàn)時能自行停止并進行回滾操作。這意味著部署存在問題時的影響半徑較小，持續(xù)時間更短。

在復雜的系統(tǒng)中，運行微服務非常具有挑戰(zhàn)性。Telltale 的智能監(jiān)控和告警功能可以幫助我們運維人員提高系統(tǒng)可用性、降低運維人員的勞動強度并減少工作人員大半夜被叫醒的頻率。

我們?yōu)?Telltale 做到的這些功能提升感到高興。但是遠沒有結束，我們?nèi)栽诓粩嗵剿餍滤惴?，以提高告警的準確性。我們將在以后的 Netflix Tech Blog 文章中詳細介紹我們的工作進展

。

我們?nèi)匀辉趯贸绦蚪】翟u估模型進行進一步評估和改進。我們相信服務運行日志和跟蹤數(shù)據(jù)中會包含更多有價值的信息，這樣我們就能采集到更有用的指標數(shù)據(jù)。我們很期待與平臺其他團隊進行合作，共同開發(fā)這些新功能。將新應用監(jiān)控引入 Telltale 可以享受到很好的服務體驗，但是無法很好的進行擴展，所以我們絕對可以優(yōu)化和提高自服務的用戶界面。我們確信，有更好的啟發(fā)式方法能幫助用戶找出影響服務健康度的一些因素。

Telltale 簡化了應用程序的監(jiān)控。

特別推薦一個分享架構+算法的優(yōu)質內(nèi)容，還沒關注的小伙伴，可以長按關注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝