背景
随着知乎業務快速發展，業務複雜程度也日趨上升，目前服務端的監控處于散點狀态，不成體系，問題發現周期長。是以急需一套完整的服務端監控體系對服務進行監控，保障業務穩定運作。
目标
- 建立首頁服務端監控報警體系，提升線上問題的感覺能力，縮短線上問題發現周期，服務端問題發現周期降低至小時級。
- 以應用為機關，梳理出一套通用的服務端監控體系方案，指導不同業務線的服務端監控體系建設。
- 服務端監控問題發現有效問題 X+。
監控名額分層
為了梳理出完備、系統化的監控名額，本篇文章以業務驅動的思路，再結合自頂向下的理念，将監控名額分為三層：業務層、應用層、系統層。下面是監控名額分層示意圖：
業務層
業務層監控主要涵蓋四個方面：綜合資料監控、業務資料監控、接口監控、關鍵節點監控。
- 綜合資料監控：主要包括應用綜合資料，對應用整體資料有一個監控，如應用SLA、各級别「warning、critical」報警資料數量名額。
- 業務資料監控：以天為機關統計業務資料是否在正常的波動範圍，主要包括接口請求量、5XX等名額。
- 接口監控：主要關注接口次元的名額，直覺觀測接口的運作情況。如接口請求量、接口響應時間、接口響應成功率、接口狀态碼等。
- 關鍵節點監控：根據業務鍊路拆解出關鍵節點，關注各個節點的邏輯及資料處理邏輯、流向是否符合預期，在出現問題時，可以通過鍊路監控快速定位到業務節點。同時監控鍊路上各個階段的耗時情況，為後續性能優化提供參考。另外，需要對定時任務進行監控，包括定時任務運作頻次、運作成功率、定時任務耗時等名額。
應用層
應用層監控主要涵蓋三個方面：日志監控、三方依賴監控、中間層監控。
- 三方依賴監控：在微服務架構下，業務請求來了之後會涉及多個服務，請求鍊路長，複雜度高，是以對三方依賴的監控是必要的，根據業務鍊路梳理出強依賴和弱依賴，主要關注請求量、響應時間、響應成功率等名額。
- 日志監控：服務在運作過程中，會産生很多的日志，日志是我們排查問題時最關鍵的資訊，是以通過對日志進行監控可以反映服務的運作狀态，主要關注各級别日志總量、關鍵鍊路上各級别日志量、錯誤日志占比等名額。
- 中間層監控：中間層服務的穩定是保證應用持續可用的關鍵，常見的中間層軟體有 MySQL、TiDB、Hbase、Redis、Kafka、Nginx等，中間層軟體都有自身特點，需要監控的名額也不同，各中間層軟體監控名額參考下表：
| 中間層軟體 | 監控名額 |
| MySQL | 查詢吞吐量：不同種類 SQL 語句的QPS、讀語句個數、非讀語句個數 查詢執行性能：查詢的平均執行時間、執行出錯的語句數、慢查詢 資料庫連接配接：目前打開連接配接數、目前運作連接配接數、由于伺服器錯誤而被拒絕的連接配接數、嘗試連接配接伺服器失敗的次數、因超過最大連接配接數而被拒絕的連接配接數 |
| TIDB | 查詢綜合資料：SQL 語句執行耗時、每秒鐘執行 SQL 語句的數量、慢查詢 查詢詳情資料：每秒事務的執行數量、事務執行時間、事務重試次數 |
| Redis | 基本活動名額：用戶端連接配接數、QPS、讀 QPS、寫 QPS、slave 數量、資料庫中 key 值總數、緩存命中率、慢查詢、寫資料耗時、讀資料耗時、每分鐘的不同指令執行量 錯誤名額：由于超過最大連接配接數而被拒絕的連接配接數、key 值查找失敗次數 |
| Kafka | 整體名額：Patition 數量、消息寫入 QPS broker 名額：消息寫入QPS、broker 上的 partition的數量、一個請求 FetchConsumer 耗費的所有時間、一個請求 FetchFollower 耗費的所有時間、一個請求Produce耗費的所有時間、broker 上的線程數 producer 名額：producer每秒發給broker的平均request次數、producer每秒發給broker的平均response次數、重試發送的消息總數量、發送錯誤的消息總數量、消息堆積量 consumer 名額：每秒平均消費的消息數量、消息堆積量 |
| HAProxy | 前台監控名額：QPS、錯誤請求量、被拒絕的請求、4XX 數量、5XX 數量 背景監控名額：響應時間、錯誤連接配接數、被拒絕的響應量、狀态碼 |
系統層
系統層主要關注硬體以及資源使用情況，這部分監控由運維團隊關注，不在本篇文章讨論範圍内。
通用監控方案
基于上述監控名額的梳理，下面将重點介紹如何以業務為機關建立服務端監控。主要分為幾個步驟：
業務場景梳理确定核心業務
基于業務範圍，先梳理出整體業務架構圖，再基于業務架構圖，可以進一步梳理出業務内的核心業務。
梳理關鍵鍊路
通過業務場景梳理，我們明确了業務範圍及業務的核心業務，接下來要做的是根據核心業務梳理出各個子業務的關鍵鍊路，這部分工作由研發老師負責。關聯鍊路的梳理思路是通讀業務代碼，基于業務代碼，從業務處理的起始點，一層一層梳理出關鍵節點以及各個節點都進行了哪一些關鍵操作，直至業務處理的結束點，一般都是以接口的形式提供最終的業務資料。
關鍵節點的粒度可以根據實際業務鍊路進行具象的拆分和定義，比較靈活，一般都是選取比較重要的節點作為關鍵節點。
梳理三方依賴
在微服務架構下，請求來了之後，業務調用鍊路長，接口響應異常時，要基于業務鍊路逐層排查，是以需要對業務的三方依賴進行監控，友善在出現問題時，快速定位。
梳理三方依賴主要有三種方式：
- 在業務關鍵鍊路梳理的過程中，可以梳理出業務的三方依賴。
- 通過混沌實驗梳理出應用次元的三方依賴。
- 通過北鬥平台-->服務拓撲功能梳理業務的三方依賴。
梳理&補齊關鍵日志
依據關鍵鍊路的梳理，我們明确了各個關鍵節點的路徑與邏輯，接下來需要研發老師确認各個關鍵節點的日志是否完備，且明确關鍵日志與實際業務的對應關系，如有缺失，需要補充相關日志。
日志級别主要可以分為三類：error、warning、info，研發老師可以根據實際業務場景選擇合适的日志級别。
梳理中間層軟體
中間層軟體是保障系統穩定運作必不可少的一環，梳理中間層軟體主要有兩種方式：
- 在業務關鍵鍊路梳理的過程中，同時梳理出單個核心業務所用到的中間層軟體。
- 在雲效-->應用-->資源中，可以梳理出應用次元所用到的中間層軟體。
确定監控名額
基于上述業務場景、業務核心鍊路、三方依賴、關鍵日志以及中間層軟體的梳理，再結合監控名額分層中的「業務層名額」和「應用層名額」進而可以确定單個核心業務的監控名額。
業務層名額
- 綜合資料：主要關注應用綜合資料，如應用 SLA、各級别報警量等名額。
- 業務資料：主要關注天級别業務資料是否正常，如接口請求總量、資料消耗量、5XX 等名額。
- 接口資料：主要關注接口次元的名額，如接口請求量、接口響應時間、接口響應成功率、接口狀态碼等。
- 業務關鍵節點：根據業務核心鍊路拆解出關鍵節點，關注關鍵節點資料處理、流向是否符合預期、同時關注各個節點耗時情況，确定監控名額。
應用層名額
- 三方依賴：主要關注核心鍊路的三方依賴的相關名額，如三方依賴的響應時間、響應成功率等名額。
- 日志監控：主要關注在業務運作期間，關鍵鍊路日志的數量以及 error 日志占比情況。
- 中間層軟體：主要關注應用所依賴的中間層軟體相關名額，不同的中間層軟體需要監控的名額不同，詳細名額設計可參考「監控名額分層」
建立監控大盤
目前服務端的監控主要分布在兩個平台上，一個是北鬥平台，一個是 GF 平台。
北鬥平台
北鬥平台提供了一部分監控能力，主要包含以下幾個方面的監控能力：
- 服務接口：QPS、響應時長、每分鐘的錯誤數。
- 服務概覽：HAProxy、Service Mesh、容器、依賴與被依賴中的接口和服務次元顯示服務相關資料。
- 依賴分析：服務依賴與服務被依賴主要是針對查詢到的服務上遊或者下遊的服務/接口的名額資料。通過每秒請求量 TOP5、每分鐘錯誤數 TOP5、響應時間 TOP5、響應時間占比 TOP5 趨勢圖和服務/接口清單展示相關資料
- 容器：以服務次元進行的容器側的監控，主要涵蓋Pod、容器 CPU、容器記憶體、MeshSidecar CPU、MeshSidecar 記憶體、服務線程的監控。
- 中間層軟體監控：對應用所依賴的中間層軟體的監控，不同中間層軟體的監控名額不同。具體名額詳見「監控名額分層」→「中間層軟體監控名額表」。
GF 平台
知乎比較成熟的監控平台是 GF，服務端監控可使用GF 平台進行監控大盤的建設。GF 大盤配置文檔
GF 大盤就比較靈活，完全是根據業務方個性化定制監控能力。
業務方是建設監控大盤時，可以結合北鬥平台和 GF 平台，選取合适的監控方式。
配置報警
Firing 平台是知乎内部成熟的報警平台，故本次基于 Firing 平台進行報警配置。
基礎平台已經自行建立了一部分報警檢查項，主要分為兩類：
- 接口級别的報警：接口 5XX、接口耗時 P95
- 基礎設施的報警：Kafka消息堆積、容器資源使用異常、dns 查詢時延過高、cpu 使用率過高、記憶體使用率過高、磁盤使用率過高、redis 記憶體使用率過高、redis CPU 使用率過高、redis 主從同步失敗
報警建設的核心是确定檢查項名額以及報警門檻值的确定。
檢查項名額
- 根據監控的名額項，選擇出關鍵名額确定檢查項名額。
報警門檻值
- 門檻值設定主要分為統一門檻值和自定義門檻值，統一門檻值表示隻要滿足目前設定的門檻值就會報警。自定義門檻值可以根據設定的時間進行不同時間範圍動态報警。
- 針對不同的檢查項名額，可以根據一段時間内名額的波動趨勢，計算得出報警門檻值。
運作&報警門檻值調優
完成監控大盤建設和報警體系建設後，在日常的工作中需要不斷關注報警情況，建立 & 确定值班組的成員，将值班政策配置到報警規則中，確定在報警發生時有值班同學可以及時響應，避免問題影響面擴大。
同時需根據業務運作情況對報警門檻值進行修正，避免誤報、漏報，提升報警體系的準确性。
報警事件的閉環主要分為三個階段：
- 事前：關注發現問題的發現和預防，提升報警處理的效率。
- 事中：關注快速發現和解決問題，快速恢複業務，保證業務連續性，縮小影響範圍。
- 事後：關注問題的根因複盤，通過不斷積累報警分析，沉澱出報警落地文檔，不斷優化監控、報警政策。
作者:瑛子
出處:https://zhuanlan.zhihu.com/p/620111232