在項目的整個生命周期中，運行維護的份量相當重要，幾乎與項目研發(fā)同等重要。在系統(tǒng)運維階段，及時發(fā)現(xiàn)并解決問題是團隊的首要任務。因此，在垂直電商系統(tǒng)的構建初期，運維團隊已完成了對機器CPU、內(nèi)存、磁盤、網(wǎng)絡等基礎監(jiān)控的設置，期望在出現(xiàn)問題時能夠及時發(fā)現(xiàn)并解決。

然而，實際運行中卻頻繁收到用戶投訴。主要問題包括數(shù)據(jù)庫主從延遲增加導致業(yè)務功能問題、接口響應時間延長導致用戶反饋商品頁面出現(xiàn)空白頁、以及系統(tǒng)出現(xiàn)大量錯誤影響用戶正常使用。這些問題本應及時被發(fā)現(xiàn)和解決，但現(xiàn)實卻是只能被動接收用戶反饋后匆忙修復。

團隊意識到，要快速發(fā)現(xiàn)和定位業(yè)務系統(tǒng)中的問題，必須建立完善的服務端監(jiān)控體系。因為“道路千萬條，監(jiān)控第一條，監(jiān)控不到位，領導兩行淚”。然而，在搭建過程中困難重重：監(jiān)控指標的選擇、采集方法與途徑、以及指標采集后的處理與展示等問題環(huán)環(huán)相扣，關系著系統(tǒng)的穩(wěn)定性和可用性。

監(jiān)控指標如何選擇

在搭建監(jiān)控系統(tǒng)時，首要問題是選擇適當?shù)谋O(jiān)控指標，也就是確定監(jiān)控的對象。有時候，針對新系統(tǒng)的監(jiān)控指標的設定可能會令人感到迷茫，不知從何著手。然而，有一些成熟的理論和方法可供直接借鑒。例如，谷歌對分布式系統(tǒng)監(jiān)控的經(jīng)驗總結(jié)提出了“四個黃金信號”（Four Golden Signals）。

這四個黃金信號主要包括延遲、通信量、錯誤和飽和度。

具體而言，延遲指的是請求的響應時間，比如接口響應時間、數(shù)據(jù)庫和緩存響應時間等；

通信量則表示單位時間內(nèi)的請求量大小，如訪問第三方服務的請求量、消息隊列的請求量等；

錯誤包括顯式和隱式的錯誤，顯式錯誤指的是出現(xiàn)的特定響應碼（例如4xx和5xx），隱式錯誤則是指返回正常響應碼但實際上發(fā)生了與業(yè)務相關的錯誤；

飽和度則表示服務或資源達到上限的程度，包括 CPU、內(nèi)存、磁盤使用率以及數(shù)據(jù)庫連接數(shù)等。

除了四個黃金信號，還可以借鑒RED指標體系，它是從四個黃金信號中衍生出來的，其中R代表請求量（Request rate）、E代表錯誤（Error）、D代表響應時間（Duration），不包含飽和度指標。可以將RED指標體系視為一種簡化版的通用監(jiān)控指標體系。

如何采集數(shù)據(jù)指標

首先，Agent 是一種比較常見的采集數(shù)據(jù)指標的方式

對于從Memcached服務器獲取性能數(shù)據(jù)，可以通過Agent連接到該服務器，并發(fā)送stats命令以獲取服務器的統(tǒng)計信息。然后，從返回的信息中選擇重要的監(jiān)控指標，發(fā)送給監(jiān)控服務器，形成Memcached服務的監(jiān)控報表。以下是一些推薦的重要狀態(tài)項，可供參考使用：

1. curr_connections：當前打開的連接數(shù)。
2. cmd_get：獲取數(shù)據(jù)的請求數(shù)。
3. cmd_set：設置數(shù)據(jù)的請求數(shù)。
4. get_hits：成功獲取數(shù)據(jù)的次數(shù)。
5. get_misses：未找到數(shù)據(jù)的次數(shù)。
6. evictions：因內(nèi)存空間不足而清除數(shù)據(jù)的次數(shù)。
7. bytes：當前存儲的字節(jié)數(shù)。
8. bytes_read：從Memcached讀取的字節(jié)數(shù)。
9. bytes_written：向Memcached寫入的字節(jié)數(shù)。
10. uptime：Memcached服務的運行時間。

另一種很重要的數(shù)據(jù)獲取方式是在代碼中埋點。

埋點和Agent的不同之處在于，Agent主要收集組件服務端的信息，而埋點則從客戶端的角度描述所使用的組件、服務的性能和可用性。在選擇埋點方式時，可以考慮以下兩種方法：

面向切面編程：這是一種常見的埋點方式，通過在代碼中插入切面邏輯，實現(xiàn)對關鍵方法或代碼塊的監(jiān)控。例如，在方法執(zhí)行前后記錄方法調(diào)用時間、參數(shù)、返回值等信息，以便后續(xù)分析性能和定位問題。

客戶端計算：另一種方式是在資源客戶端直接計算調(diào)用資源或服務的耗時、調(diào)用量等指標，并將這些信息發(fā)送給監(jiān)控服務器。例如，可以在客戶端代碼中添加邏輯，記錄資源調(diào)用開始和結(jié)束時間，并計算調(diào)用耗時，然后將這些數(shù)據(jù)發(fā)送給監(jiān)控服務器。

最后，日志也是你監(jiān)控數(shù)據(jù)的重要來源之一。

在監(jiān)控系統(tǒng)中，Tomcat和Nginx的訪問日志是非常重要的監(jiān)控數(shù)據(jù)源之一。通過開源的日志采集工具，可以將這些日志中的數(shù)據(jù)發(fā)送給監(jiān)控服務器，以便進行實時監(jiān)控和分析。目前，常用的日志采集工具包括Apache Flume、Fluentd和Filebeat等，你可以根據(jù)自己的熟悉程度和項目需求選擇合適的工具。

在項目中，傾向于使用Filebeat來收集監(jiān)控日志數(shù)據(jù)。Filebeat是一個輕量級的日志數(shù)據(jù)收集工具，具有簡單易用、低資源消耗等特點，適用于實時收集和傳輸日志數(shù)據(jù)。通過配置Filebeat，你可以輕松地將Tomcat和Nginx的訪問日志發(fā)送到監(jiān)控服務器，實現(xiàn)對這些日志數(shù)據(jù)的收集和分析，從而更好地監(jiān)控系統(tǒng)的運行狀態(tài)和性能表現(xiàn)。

監(jiān)控數(shù)據(jù)的處理和存儲

在采集監(jiān)控數(shù)據(jù)后，一般會先通過消息隊列來緩沖數(shù)據(jù)，以平滑數(shù)據(jù)流，防止監(jiān)控服務因?qū)懭脒^多數(shù)據(jù)而受到影響。同時，通常會部署兩個隊列處理程序來處理消息隊列中的數(shù)據(jù)。

一個處理程序負責將數(shù)據(jù)寫入Elasticsearch，并通過Kibana展示，用于原始數(shù)據(jù)的查詢。另一個處理程序則用于流式處理，通常使用Spark、Storm等中間件。它們會從消息隊列接收數(shù)據(jù)并進行如下處理：

解析數(shù)據(jù)格式，特別是日志格式，提取諸如請求量、響應時間、請求URL等數(shù)據(jù)。

對數(shù)據(jù)進行聚合運算，例如針對Tomcat訪問日志，計算同一URL在一段時間內(nèi)的請求量、響應時間分位值、非200狀態(tài)碼請求量等。

將數(shù)據(jù)存儲在時間序列數(shù)據(jù)庫中。時序數(shù)據(jù)庫特點是可以更有效地存儲帶有時間標簽的數(shù)據(jù)，而監(jiān)控數(shù)據(jù)恰好帶有時間標簽，適合存儲在此類數(shù)據(jù)庫中。常用的時序數(shù)據(jù)庫包括InfluxDB、OpenTSDB、Graphite等，選擇根據(jù)實際需求和團隊熟悉程度而定。

最后，通過Grafana連接時序數(shù)據(jù)庫，將監(jiān)控數(shù)據(jù)可視化成報表，供開發(fā)和運維人員使用。

圖片

至此，你和你的團隊也就完成了垂直電商系統(tǒng)服務端監(jiān)控系統(tǒng)搭建的全過程。這里我想再多說一點，我們從不同的數(shù)據(jù)源中采集了很多的指標，最終在監(jiān)控系統(tǒng)中一般會形成以下幾個報表，你在實際的工作中可以參考借鑒。

訪問趨勢報表：此類報表基于Web服務器和應用服務器的訪問日志，展示了服務整體的訪問量、響應時間、錯誤數(shù)量、帶寬等信息。它主要反映了服務的整體運行情況，有助于發(fā)現(xiàn)問題。

性能報表：這類報表對接的是資源和依賴服務的埋點數(shù)據(jù)，展示了被埋點資源的訪問量和響應時間情況。它反映了資源的整體運行情況。當從訪問趨勢報表發(fā)現(xiàn)問題時，可以先從性能報表中找到出現(xiàn)問題的具體資源或服務。

資源報表：此類報表主要對接使用Agent采集的資源的運行情況數(shù)據(jù)。當從性能報表中發(fā)現(xiàn)某一資源出現(xiàn)問題時，可以進一步從資源報表中查找資源的具體問題，如連接數(shù)異常增加或緩存命中率下降。這有助于進一步分析問題的根源并找到解決方案。