談服務可用性監控

一個服務的監控從整體考慮，要達到哪些才能算是完善的？我想，如果沒有一個全局性的監控思考，一個服務的監控即使加的再多也是會有監控盲區的。

監控的層次

從基礎機器到上層業務，分為三個不同層次：系統，應用，業務。不同的層次都應該有其不同的監控目的。

系統監控

這個層次監控服務所在服務器的可用性。服務器的各項基本指標是否正常。包括服務器的CPU，服務器的磁盤，服務器的內存等。

有的服務器會進行服務混布，這種監控更為重要。因為其他服務導致的服務器問題只能通過系統監控層面得到反饋。

操作系統層面的監控也是最為基礎的了。如果我們購買雲服務器，阿里雲或者騰訊雲上都會有對應的監控設置，但如果是自有的虛擬化集群，集群管理也有對應的開源實現，比如 prometheus + node_exporter 的形式。

這類監控報警通常關注的就是機器CPU負載，空閑內存，網絡帶寬，磁盤空間等。

應用監控

這個層次監控當前服務進程的可用性。分析當前服務進程與業務無關的各項指標。把一個應用（進程）當作是黑盒，不管其中的業務邏輯正確與否，只觀察這個應用的健康狀態。大致應用狀態包含：

• 進程數
• CPU占用
• 內存占用
• Coredump情況
• fd打開數

對於這個級別的監控，prometheus 也有一個 process_exporter 是專門做這個事情的。

在應用監控的時候，對於 Golang 項目，需要監控進程的runtime信息。

這個runtime信息包括：

• gorutine個數
• gc暫停時間
• gc次數
• 內存分配

Go 的 runtime 的基本監控方法都是在 Golang 的進程中插入一個包，這個包負責監控 runtime， 並且打點到 metric 系統。

prometheus 也提供了這樣一個庫： github.com/prometheus/client_golang

能打出這樣一些關於runtime的數據：

go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
go_gc_duration_seconds{quantile="0.5"} 0
go_gc_duration_seconds{quantile="0.75"} 0
go_gc_duration_seconds{quantile="1"} 0
go_gc_duration_seconds_sum 0
go_gc_duration_seconds_count 0
# HELP go_goroutines Number of goroutines that currently exist.
# TYPE go_goroutines gauge
go_goroutines 8
# HELP go_info Information about the Go environment.
# TYPE go_info gauge
go_info{version="go1.14.2"} 1
# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
# TYPE go_memstats_alloc_bytes gauge
go_memstats_alloc_bytes 2.563056e+06

業務監控

這個層次監控具體的業務了。這個層次的監控關注的是業務是否可用，業務是否有走入異常分支，業務哪些服務是比較慢的。

關於業務監控，個人的感覺是盡量不要使用metric監控，因為業務的問題一旦報警，排查是需要分析的，這個時候如果僅僅是告訴開發有異常了，但是沒有對應的日志，或者查找日志需要去線上機器一個個撈，是一件很痛苦的事情。

所以業務監控的實現方式，基本上都是落盤日志 + 日志文件采集 + 結構化處理 + 分布式日志存儲 + 分析報警。

標准的 ELK 三件套非常適合進行實操部署這套。

業務監控應該從三個方面進行報警：

性能監控

監控每個業務請求的性能指標，可以對具體的業務請求的性能進行完整的展示。

我們應該對整體請求的請求時長，所有網絡調用的請求時長，所有數據操作的網絡時長，以及關鍵函數的請求時長都有記錄。最后在具體分析的時候就能有所抓手。

鏈路監控

監控每個業務請求的完成鏈路，這個包括對上游和下游的鏈路日志，也包括在當前業務中各個模塊的日志記錄。

對於微服務架構，鏈路監控是非常重要的。服務與服務間的鏈路需要通過一個 trace 進行串聯。

關於鏈路監控，已經有很多開源成熟方案可以部署，大都都是基於 Dapper 理論進行實現的。

錯誤監控

業務中不僅僅只有正常流程的邏輯，也有很多各種各樣的錯誤分支邏輯。對於這些務請求中非正常的錯誤信息。往往是很有用的。特別是能彌補測試人員沒有測試到的一些分支異常。

錯誤信息必須要保留的應該有錯誤請求體、錯誤堆棧、錯誤觸發條件等信息。

監控的數據源

關於監控的數據源，無非就分為兩類：日志 和 metric(統計)

日志數據源比metric數據源的優勢是能有更強大的數據結構，可以進行更為復雜的日志搜索，可以存儲更多的信息。缺點則是存儲量比metric數據大很多，在大流量業務場景下，很難做到全量采集。很經常采用的是抽樣采集記錄。這里面就有一個抽樣采集策略。

另一方面 metric 數據源理論上比日志數據源有更強的實時性。也可以通過各種環比來得出趨勢的變化。

日志又分為幾個類型的日志

• 錯誤日志：記錄錯誤信息
• 運行日志：記錄內部運行和數據流轉的各種日志記錄
• 訪問日志：記錄請求進出服務的訪問入口日志

如何衡量監控系統的完整性？

摘抄自 Google SRE:

監控系統的衡量指標:

• 速度：需要保證數據的新鮮度和數據獲取速度。需要很快獲取到最新的數據指標。
• 計算：對數據進行計算可以支持各種復雜的查詢需求。
• 接口：既有精確的圖表展示，又提供開放的接口查詢。
• 告警：靈活的告警系統，可以消除不必要的噪音。

總結

感覺基本每個公司差不多都是這些思路，只是在每個具體實現上，可能會針對不同的業務進行不同的定制化。

基本上從不同層面，不同數據源，對某個服務搭建起來完整的監控鏈路，這個服務的可用性就能得到很好的保證了。