給系統加上眼睛：服務端監控要怎么做？
在項目的整個生命周期中，運行維護的份量相當重要，幾乎與項目研發同等重要。在系統運維階段，及時發現并解決問題是團隊的首要任務。因此，在垂直電商系統的構建初期，運維團隊已完成了對機器CPU、內存、磁盤、網絡等基礎監控的設置，期望在出現問題時能夠及時發現并解決。
然而，實際運行中卻頻繁收到用戶投訴。主要問題包括數據庫主從延遲增加導致業務功能問題、接口響應時間延長導致用戶反饋商品頁面出現空白頁、以及系統出現大量錯誤影響用戶正常使用。這些問題本應及時被發現和解決，但現實卻是只能被動接收用戶反饋后匆忙修復。
團隊意識到，要快速發現和定位業務系統中的問題，必須建立完善的服務端監控體系。因為“道路千萬條，監控第一條，監控不到位，領導兩行淚”。然而，在搭建過程中困難重重：監控指標的選擇、采集方法與途徑、以及指標采集后的處理與展示等問題環環相扣，關系著系統的穩定性和可用性。
監控指標如何選擇
在搭建監控系統時，首要問題是選擇適當的監控指標，也就是確定監控的對象。有時候，針對新系統的監控指標的設定可能會令人感到迷茫，不知從何著手。然而，有一些成熟的理論和方法可供直接借鑒。例如，谷歌對分布式系統監控的經驗總結提出了“四個黃金信號”（Four Golden Signals）。
這四個黃金信號主要包括延遲、通信量、錯誤和飽和度。
具體而言，延遲指的是請求的響應時間，比如接口響應時間、數據庫和緩存響應時間等；
通信量則表示單位時間內的請求量大小，如訪問第三方服務的請求量、消息隊列的請求量等；
錯誤包括顯式和隱式的錯誤，顯式錯誤指的是出現的特定響應碼（例如4xx和5xx），隱式錯誤則是指返回正常響應碼但實際上發生了與業務相關的錯誤；
飽和度則表示服務或資源達到上限的程度，包括 CPU、內存、磁盤使用率以及數據庫連接數等。
除了四個黃金信號，還可以借鑒RED指標體系，它是從四個黃金信號中衍生出來的，其中R代表請求量（Request rate）、E代表錯誤（Error）、D代表響應時間（Duration），不包含飽和度指標。可以將RED指標體系視為一種簡化版的通用監控指標體系。
如何采集數據指標
首先，Agent 是一種比較常見的采集數據指標的方式
對于從Memcached服務器獲取性能數據，可以通過Agent連接到該服務器，并發送stats命令以獲取服務器的統計信息。然后，從返回的信息中選擇重要的監控指標，發送給監控服務器，形成Memcached服務的監控報表。以下是一些推薦的重要狀態項，可供參考使用：
- curr_connections：當前打開的連接數。
- cmd_get：獲取數據的請求數。
- cmd_set：設置數據的請求數。
- get_hits：成功獲取數據的次數。
- get_misses：未找到數據的次數。
- evictions：因內存空間不足而清除數據的次數。
- bytes：當前存儲的字節數。
- bytes_read：從Memcached讀取的字節數。
- bytes_written：向Memcached寫入的字節數。
- uptime：Memcached服務的運行時間。
另一種很重要的數據獲取方式是在代碼中埋點。
埋點和Agent的不同之處在于，Agent主要收集組件服務端的信息，而埋點則從客戶端的角度描述所使用的組件、服務的性能和可用性。在選擇埋點方式時，可以考慮以下兩種方法：
面向切面編程：這是一種常見的埋點方式，通過在代碼中插入切面邏輯，實現對關鍵方法或代碼塊的監控。例如，在方法執行前后記錄方法調用時間、參數、返回值等信息，以便后續分析性能和定位問題。
客戶端計算：另一種方式是在資源客戶端直接計算調用資源或服務的耗時、調用量等指標，并將這些信息發送給監控服務器。例如，可以在客戶端代碼中添加邏輯，記錄資源調用開始和結束時間，并計算調用耗時，然后將這些數據發送給監控服務器。
最后，日志也是你監控數據的重要來源之一。
在監控系統中，Tomcat和Nginx的訪問日志是非常重要的監控數據源之一。通過開源的日志采集工具，可以將這些日志中的數據發送給監控服務器，以便進行實時監控和分析。目前，常用的日志采集工具包括Apache Flume、Fluentd和Filebeat等，你可以根據自己的熟悉程度和項目需求選擇合適的工具。
在項目中，傾向于使用Filebeat來收集監控日志數據。Filebeat是一個輕量級的日志數據收集工具，具有簡單易用、低資源消耗等特點，適用于實時收集和傳輸日志數據。通過配置Filebeat，你可以輕松地將Tomcat和Nginx的訪問日志發送到監控服務器，實現對這些日志數據的收集和分析，從而更好地監控系統的運行狀態和性能表現。
監控數據的處理和存儲
在采集監控數據后，一般會先通過消息隊列來緩沖數據，以平滑數據流，防止監控服務因寫入過多數據而受到影響。同時，通常會部署兩個隊列處理程序來處理消息隊列中的數據。
一個處理程序負責將數據寫入Elasticsearch，并通過Kibana展示，用于原始數據的查詢。另一個處理程序則用于流式處理，通常使用Spark、Storm等中間件。它們會從消息隊列接收數據并進行如下處理：
解析數據格式，特別是日志格式，提取諸如請求量、響應時間、請求URL等數據。
對數據進行聚合運算，例如針對Tomcat訪問日志，計算同一URL在一段時間內的請求量、響應時間分位值、非200狀態碼請求量等。
將數據存儲在時間序列數據庫中。時序數據庫特點是可以更有效地存儲帶有時間標簽的數據，而監控數據恰好帶有時間標簽，適合存儲在此類數據庫中。常用的時序數據庫包括InfluxDB、OpenTSDB、Graphite等，選擇根據實際需求和團隊熟悉程度而定。
最后，通過Grafana連接時序數據庫，將監控數據可視化成報表，供開發和運維人員使用。
圖片
至此，你和你的團隊也就完成了垂直電商系統服務端監控系統搭建的全過程。這里我想再多說一點，我們從不同的數據源中采集了很多的指標，最終在監控系統中一般會形成以下幾個報表，你在實際的工作中可以參考借鑒。
訪問趨勢報表：此類報表基于Web服務器和應用服務器的訪問日志，展示了服務整體的訪問量、響應時間、錯誤數量、帶寬等信息。它主要反映了服務的整體運行情況，有助于發現問題。
性能報表：這類報表對接的是資源和依賴服務的埋點數據，展示了被埋點資源的訪問量和響應時間情況。它反映了資源的整體運行情況。當從訪問趨勢報表發現問題時，可以先從性能報表中找到出現問題的具體資源或服務。
資源報表：此類報表主要對接使用Agent采集的資源的運行情況數據。當從性能報表中發現某一資源出現問題時，可以進一步從資源報表中查找資源的具體問題，如連接數異常增加或緩存命中率下降。這有助于進一步分析問題的根源并找到解決方案。
