《微服務設計》第 8 章 監控
- 2019 年 10 月 8 日
- 筆記
第 8 章 監控
- 將系統拆分成更小的、細粒度的微服務會帶來很多好處。然而，它也增加了生產系統的監控複雜性
- ssh-multiplexers 這樣的工具，在多個主機上運行相同的命令。用一個大的顯示屏，和一個 grep "Error" app.log，我們就可以定位錯誤了
8.3 多個服務，多個服務器
- 你如何在多個主機上的、成千上萬行的日誌中定位錯誤的原因？如何確定是一個服務器異常，還是一個系統性的問題？如何在多個主機間跟蹤一個錯誤的調用鏈，找出引起這個錯誤的原因？答案是，從日誌到應用程序指標，集中收集和聚合儘可能多的數據到我們的手上
8.4 日誌，日誌，更多的日誌
- Kibana（https://www.elastic.co/products/kibana）是一個基於 ElasticSearch 查看日誌的系統， 如圖 8-4 所示。你可以使用查詢語法來搜索日誌，它允許在查詢時指定時間和日期範圍，或使用正則表達式來查找匹配的字符串。Kibana 甚至可以把你發給它的日誌生成圖表，只需看一眼就能知道已經發生了多少錯誤
- Kibana 甚至可以把你發給它的日誌生成圖表，只需看一眼就能知道已經發生了多少錯誤
8.5 多個服務的指標跟蹤
- 我們希望能夠看到整個系統聚合後的指標（例如，平均的 CPU 負載），但也會想要給定的一些服務實例聚合後的指標，甚至某單個服務實例的指標。這意味着，我們需要將指標的元數據關聯，用來幫助推導出這樣的結構
- Graphite 就是一個讓上述要求變得很容易的系統。它提供一個非常簡單的 API，允許你實時發送指標數據給它
8.6 服務指標
- 當你在 Linux 機器上安裝 collectd 並讓它指向 Graphite 時，會發現我們運行的操作系統會生成大量的指標。同樣，像 Nginx 或 Varnish 這樣的支撐子系統，也會暴露很多有用的信息，例如響應時間或緩存命中率
- 我強烈建議你公開自己服務的基本指標。作為 Web 服務，最低限度應該暴露如響應時間和錯誤率這樣的一些指標
- 首先，有一句老話，80% 的軟件功能從未使用過
- 其次，可以通過了解用戶如何使用我們的系統得知如何改進，在這個方面，我們比以往任何時候做得都要好
- 最後，我們永遠無法知道什麼數據是有用的！
- 很多平台都存在一些庫來幫助服務發送指標到一個標準系統中。Codahale 的 Metrics 庫（http://metrics.codahale.com/）就是這樣一個運行在 JVM 上的庫。它允許你存儲一些指標，例如計數器、計時器或計量表（gauge）; 支持帶時間限制的指標（這樣你就可以指定如「過去五分鐘的訂單數量」這樣的指標）；
8.7 綜合監控
- 我們可以通過定義正常的 CPU 級別，或者可接受的響應時間，判斷一個服務是否健康。如果我們的監控系統監測到實際值超出這些安全水平，就可以觸發警告。類似像 Nagios 這樣的工具，完全有能力做這個
- 實現語義監控
8.8 關聯標識
- 一個非常有用的方法是使用關聯標識（ID）。在觸發第一個調用時，生成一個 GUID。然後把它傳遞給所有的後續調用
- 使用關聯標識時，一個現實的問題是，你常常直至問題出現才知道需要它，而且只有在開始時就存在關聯標識才可能診斷出問題！
8.9 級聯
- 監控系統之間的集成點非常關鍵。每個服務的實例都應該追蹤和顯示其下游服務的健康狀態，從數據庫到其他合作服務。你也應該將這些信息匯總，以得到一個整合的畫面。你會想了解下游服務調用的響應時間，並檢測是否有錯誤
- 一些庫，例如 JVM 上的 Hystrix，便很好地提供了這些監控功能
8.10 標準化
- 你應該嘗試以標準格式的方式記錄日誌。你一定想把所有的指標放在一個地方，你可能需要為度量提供一個標準名稱的列表；如果一個服務指標叫作 ResponseTime，另一個叫作 RspTimeSecs，而它們的意思是一樣的，這會非常令人討厭
8.11 考慮受眾
- 我們為不同的人收集這些數據，幫助他們完成工作；這些數據會觸發一些事件。有些數據會觸發支持團隊立即採取行動，比如我們的一個綜合監控測試失敗了
8.12 未來
- 為什麼不能以同樣的方式處理運營指標和業務指標？最終，兩種類型的指標分解成事件後，都說明在 X 時間點發生了一些事情。如果我們可以統一收集、聚合及存儲這些事件的系統，使它們可用於報告，最終會得到一個更簡單的架構
- Riemann（http://riemann.io/）是一個事件服務器，允許高級的聚合和事件路由，所以該工具可以作為上述解決方案的一部分。Suro（https://github.com/Netflix/suro）是 Netflix 的數據流水線，其解決的問題與 Riemann 類似。Suro 明確可以處理兩種數據，用戶行為的相關指標和更多的運營數據（如應用程序日誌）。然後這些數據可以被分發到不同的系統中，像 Storm 的實時分析、離線批處理的 Hadoop 或日誌分析的 Kibana
8.13 小結
- 對每個服務
- 最低限度要跟蹤請求響應時間。做好之後，可以開始跟蹤錯誤率及應用程序級的指標
- 最低限度要跟蹤所有下游服務的健康狀態，包括下游調用的響應時間，最好能夠跟蹤錯誤率。一些像 Hystrix 這樣的庫，可以在這方面提供幫助
- 標準化如何收集指標以及存儲指標
- 如果可能的話，以標準的格式將日誌記錄到一個標準的位置。如果每個服務各自使用不同的方式，聚合會非常痛苦！
- 監控底層操作系統，這樣你就可以跟蹤流氓進程和進行容量規劃
- 對系統
- 聚合 CPU 之類的主機層級的指標及應用程序級指標
- 確保你選用的指標存儲工具可以在系統和服務級別做聚合，同時也允許你查看單台主機的情況
- 確保指標存儲工具允許你維護數據足夠長的時間，以了解你的系統的趨勢
- 使用單個可查詢工具來對日誌進行聚合和存儲
- 強烈考慮標準化關聯標識的使用
- 了解什麼樣的情況需要行動，並根據這些信息構造相應的警報和儀錶盤
- 調查對各種指標聚合方式做統一化的可能性，像 Suro 或 Riemann 這樣的工具可能會對你有用
書
- Stephen Few 的優秀圖書：《Information Dashboard Design: Displaying Data for Ata-Glance Monitoring》
- 《Lightweight Systems for Realtime Monitoring》
