談服務可用性監控
一個服務的監控從整體考慮，要達到哪些才能算是完善的？我想，如果沒有一個全域性性的監控思考，一個服務的監控即使加的再多也是會有監控盲區的。
監控的層次
從基礎機器到上層業務，分為三個不同層次：系統，應用，業務。不同的層次都應該有其不同的監控目的。
系統監控
這個層次監控服務所在伺服器的可用性。伺服器的各項基本指標是否正常。包括伺服器的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:
監控系統的衡量指標:
- 速度：需要保證資料的新鮮度和資料獲取速度。需要很快獲取到最新的資料指標。
- 計算：對資料進行計算可以支援各種複雜的查詢需求。
- 介面：既有精確的圖表展示，又提供開放的介面查詢。
- 告警：靈活的告警系統，可以消除不必要的噪音。
總結
感覺基本每個公司差不多都是這些思路，只是在每個具體實現上，可能會針對不同的業務進行不同的定製化。
基本上從不同層面，不同資料來源，對某個服務搭建起來完整的監控鏈路，這個服務的可用性就能得到很好的保證了。