難忘的經歷
相信很多運維人都有過這樣的經歷：
監控系統某個指標超過閾值，觸發告警。大半夜裏，你被緊急召喚。半睜着眼，你滿臉疑惑：“系統真出問題了嗎，還是僅僅需要調整下告警？上一次有人調整我們的告警閾值是在什麼時候？有沒有可能是上游或者下游的服務出現了問題？”
鑑於這是一次非常重要的應用告警，因此你不得不從牀上爬起來，迅速打開電腦，然後瀏覽監控儀表盤來追蹤問題源頭。忙了半天，你還沒確認這個告警是來自於系統的問題，但也意識到，從海量數據中尋找線索時，時間正在流逝。你必須儘快定位告警的原因，並祈禱系統穩定運行。
對我們的用戶來講，穩健的Netflix服務至關重要。當你坐下來看《養虎爲患》時，你肯定希望它能順利播放。
多年來，我們從經常在深夜被召喚的工程師那裏瞭解到應用程序監控的痛點：
- 過多的告警
- 太多滾動瀏覽的儀表盤
- 太多的配置
- 過多的維護
Telltale
我們的流媒體團隊需要一個全新的監控系統，可以讓團隊成員快速地診斷和修復問題；因爲在系統告警的緊急情況下，每一秒都至關重要！我們的Node團隊需要一個僅需一小撮人就能運維大型集羣的系統。
因此，我們構建了Telltale。
Telltale的特性
- 彙集監控數據源，創建整體監控視圖
Telltale彙集了各種監控數據源，從而能創建關於應用程序運行狀況的整體監控視圖。
- 多維度判斷應用程序的健康狀況
Telltale可以通過多個維度判斷一個應用程序的健康情況，而無需根據單一指標頻繁調整告警閾值。
- 及時告警
因爲我們知道應用程序在什麼情況下是正常的，所以能在應用程序有異常趨勢時及時通知應用程序的所有者。
- 顯示關鍵數據
指標是瞭解應用程序運行狀態的關鍵。但很多時候，你擁有太多的指標、太多的圖表以及太多的監控儀表盤。而Telltale僅顯示應用程序中有用的相關數據及其上游和下游服務的數據。
- 用顏色區分問題的嚴重程度
我們使用不同的顏色來表示問題的嚴重程度（除選擇顏色之外，還可以讓Telltale顯示不同的數字），以便運維人員一眼就能判斷出應用程序的運行狀況。
- 高亮提示
我們還會對一些監控事件進行高亮提示，比如局部區域的網絡流量疏散及就近的服務部署，這些信息對於全面瞭解服務的健康情況至關重要，尤其是在真正發生系統故障的情況下。
這就是我們的Telltale監控。它現已成功運行並提供監控服務，監控着Netflix 100多個生產應用程序的運行狀況。
應用程序健康評估模型
微服務並非是孤立存在和運行的。它需要特定的依賴，與其他服務進行數據交互，甚至位於不同的AWS區域。
上面的調用圖是一個相對簡單的圖，其中涉及許多服務，實際的調用鏈可能會更深更復雜。一個應用程序是系統生態的一部分，它的運行狀態可能會受到相關屬性變化的微弱影響，也有可能會受到區域範圍內某些事件的影響從而發生根本性改變。canary的啓動可能會對應用程序產生一定影響。在一定程度上，上游或下游服務的部署同樣也可以帶來一定的影響。
Telltale通過使用多個維度的數據源構建一個不斷自我優化的模型來監控應用程序的健康度：
不同的數據源對應用程序健康度的影響權重不同。例如，與錯誤率增加相比，響應時間的增加對應用程序的影響要小很多；錯誤代碼有很多，但是某些特定的錯誤代碼的影響要比其他錯誤代碼的影響大。在服務下游部署canary可能不如在上游部署帶來的效果明顯
區域網絡流量轉移意味着某個區域的網絡流量降爲零而另一個區域的網絡流量會加倍。你可以感受下不同的指標對於監控的影響。監控指標的具體含義決定了我們應該如何科學有效地使用它來進行監控。
在構建應用程序健康狀況視圖時，Telltale考慮了所有這些因素。
應用程序健康評估模型是Telltale的核心。
智能監控
每個服務運維人員都知道告警閾值調整的難度。將閾值設置得太低，你會收到大量虛假告警。如果過度補償並放寬告警閾值，就會錯過重要的異常警告。這樣導致的最終結果是對告警缺乏信任。Telltale可以幫助你免除不斷調整相關配置的繁瑣工作。
通過提供準確的和嚴格管理的數據源，我們能讓應用程序所有者的設置和配置過程變得更加容易。這些數據源通過按照一定的組合應用到程序的配置中，以實現最常見的服務類型配置。
Telltale可以自動追蹤服務之間的依賴關係，以構建應用程序健康評估模型中的拓撲。通過數據源管理以及拓撲監測，在不用付出很大的努力情況下就能使配置保持最新狀態。那些需要手動實踐的一些場景仍然支持手動配置和調整。
沒有任何一個獨立的算法可以適用我們所有的監控場景。因此，我們採用了混合算法，包括統計算法、基於規則的算法和機器學習算法。
不久後，我們將在Netflix Tech Blog上發表一篇針對我們監控算法的文章。
Telltale還具有分析器，可用於趨勢探測或內存泄漏監測。智能監控意味着我們的用戶可以信賴我們的監控結果。這表明故障發生時，用戶能更快地定位和解決系統異常問題。
智能告警
智能監控必然會促進智能告警。當Telltale檢測到應用程序中的運行異常時，就會產生異常事件。團隊可以選擇通過Slack、電子郵件或PagerDuty（均由我們的內部告警系統提供支持）進行告警。
如果該異常問題是由上游或下游系統引起的，則Telltale的上下文感知路由會提醒服務對應的維護團隊。智能告警還意味着運維團隊針對特定異常只會收到一個通知，也就是說，告警風暴已經成爲過去式。
在系統出現問題時，掌握準確的信息至關重要。我們的Slack告警程序還會啓動一個包含有關事件上下文信息的線程，提供Telltale識別到的異常問題信息及問題產生的原因。正確的上下文可以方便我們瞭解應用程序的當前狀態，以便值班運維的工程師能有針對性的定位和修復問題。
異常告警事件會不斷髮展而且擁有自己的生命週期，因此及時更新事件狀態至關重要。告警異常是好轉了還是惡化了？是否要考慮新的監控信息或事件？Telltale在當前事件發生改變時會更新Slack線程。系統返回正常狀態後，該線程將被標記爲“已解決”，因此用戶一眼就能知道哪些異常事件正在處理中，哪些異常事件已成功修復。
這些Slack線程不僅僅適用於Telltale。團隊還可以用它們來共享有關事件的其他數據，方便進一步觀察、理論分析和討論。異常信息數據和討論全部集中在一個線程中，方便達成針對當前異常的共識，有利於更快提出問題的解決方案以及異常事件的事後分析。
我們致力於提高Telltale告警的質量。一種方法是向我們的用戶學習。因此，我們在Slack消息中提供了反饋按鈕。用戶可以告訴我們以後某些情況不需要再發生告警，或提供某些告警不合理的原因。智能告警意味着用戶可以信賴我們的告警。
爲什麼我的應用服務運行狀態欠佳？
各種類型的監控數據、應用程序相關知識以及跨多種服務數據的相關性，有助於Telltale檢測分析應用程序運行健康度降低的原因。這些原因包括實例異常、相關依賴的監測和部署異常、數據庫異常或者網絡流量高峯等。突出高亮顯示這些可能的原因可以幫助運維人員節省大量寶貴的時間。
異常事件管理
當Telltale發送告警時，它還會創建一個快照，其中引用了不正常的監控信號數據。隨着新監控信息的到來，會將其添加到此快照中。這簡化了團隊的很多事後審查流程。當需要複查過去的異常問題時，“應用程序事件摘要”功能可以從各個方面顯示當前的問題，包括一些關鍵指標，比如總停機時間和MTTR（平均解決時間）。我們希望幫助我們的團隊瞭解更多的異常事件的模式，以便提高我們服務的整體可用性。
部署監控
可以看出，Telltale的應用程序健康評估模型及其智能監控功能非常強大，所以我們也會將其應用於安全部署方面。我們從開放源碼交付平臺Spinnaker開始測試。
隨着Spinnaker逐漸推出新版本，我們使用Telltale連續監監控運行新版本實例的運行狀態。持續監控意味着新部署在問題出現時能自行停止並進行回滾操作。這意味着部署存在問題時的影響半徑較小，持續時間更短。
持續優化
在複雜的系統中，運行微服務非常具有挑戰性。Telltale的智能監控和告警功能可以幫助我們運維人員提高系統可用性、降低運維人員的勞動強度並減少工作人員大半夜被叫醒的頻率。
我們爲Telltale做到的這些功能提升感到高興。但是遠沒有結束，我們仍在不斷探索新算法，以提高告警的準確性。我們將在以後的Netflix Tech Blog文章中詳細介紹我們的工作進展。
我們仍然在對應用程序健康評估模型進行進一步評估和改進。我們相信服務運行日誌和跟蹤數據中會包含更多有價值的信息，這樣我們就能採集到更有用的指標數據。我們很期待與平臺其他團隊進行合作，共同開發這些新功能。將新應用監控引入Telltale可以享受到很好的服務體驗，但是無法很好的進行擴展，所以我們絕對可以優化和提高自服務的用戶界面。我們確信，有更好的啓發式方法能幫助用戶找出影響服務健康度的一些因素。
Telltale簡化了應用程序的監控。
原文鏈接：
https://netflixtechblog.com/telltale-netflix-application-monitoring-simplified-5c08bfa780ba