概述
雲搜是58集團搜索技術部推出的搜索服務雲平臺，旨在為集團內部各垂直業務提供成熟的搜索服務。在之前的《58雲搜系統設計與實現》一文中，我們對58雲搜進行了詳細的介紹。雲搜系統自上線至今已穩定運行近2年的時間，已經接入了集團內部各業務線的上百個搜索實例，得益於集團內部的運維監控平臺，雲搜在系統、網絡等方面得到了有效的監控。但隨著雲搜承載業務量的增加以及集群規模的不斷擴大，對於容器層級、業務層級以及Kubernetes內部資源對象上的監控和問題排查變得越發複雜和困難。針對這一情況，我們在使用集團運維監控平臺的同時，結合雲搜運維場景，提出了基於Prometheus的雲蒐集群監控解決方案。本文將分享Prometheus監控解決方案在雲搜中的應用與實踐。
本文將從以下三個部分來進行討論：
1. 雲搜監控系統面臨的挑戰
2. 雲搜監控系統技術選型
3. 雲蒐集群監控系統設計方案
雲搜監控系統面臨的挑戰
與傳統監控相比，雲搜監控面臨著更多難點，包括：
1. 雲蒐集群的資源對象動態可變，無法進行預先配置；
2. 雲蒐集群監控範圍繁雜，各類監控融合難度大；
3. 雲搜實例間的調用關係複雜，故障排查更困難；
在工程角度也面臨著不少考驗，如：
1. 監控系統必須要保證可靠性，保證系統不會因為單點故障而全局失效，監控數據有備份機制，系統各服務的實例均可通過備份數據得到恢復；
2. 監控系統必須支持容器上快速部署及水平擴容，這既是雲原生的基本要求，也符合企業系統容器化演進的實際情況。
雲搜監控系統技術選型
監控的諸多挑戰讓前期的調研變得非常慎重，自己開發還是選擇雲原生的開源組件成為調研的關鍵，經過調研和部署測試，決定採用開源監控方案Prometheus。
Prometheus是一個開源的系統監控和警報工具包，自2012年啟動以來，該項目收到了廣泛的關注，項目擁有非常活躍的開發人員和用戶社區，許多公司和組織諸如CoreOS、Maven、SoundCloud、網易雲等都採用Prometheus。目前，Prometheus已經從CNCF孵化完成，是容器雲場景中監控的首選解決方案，結合雲搜的實際業務場景，選擇Prometheus主要有以下幾個原因。
靈活的數據模型
在Prometheus裡，監控數據是由值、時間戳和標籤表組成的，其中監控數據的源信息是完全記錄在標籤表裡的；同時Prometheus支持在監控數據採集階段對監控數據的標籤表進行修改，這使其具備強大的擴展能力。
更契合的架構
雲搜採用Kubernetes作為容器編排工具，支持Prometheus無縫部署和擴展。如將Node-exporter以Daemonset的方式能夠直接部署到集群各節點上，直接獲取各節點的狀態信息。
強大的查詢能力
Prometheus 提供有數據查詢語言PromQL。從表現上來看，PromQL提供了大量的數據計算函數，大部分情況下都可以直接通過PromQL從 Prometheus 裡查詢到需要的聚合數據，便於快速獲取監控數據。
豐富的組件支持
Prometheus監控主體是PrometheusOperator。除此以外，Prometheus方案加入了多種組件滿足Kubernetes的監控場景，如Alertmanager報警組件、Node-exporter節點資源採集組件等，極大地豐富了Prometheus方案的功能。
成熟的社區
Prometheus擁有成熟的開源社區，有豐富的參考文檔，便於快速的搭建監控系統。
雲蒐集群監控系統設計方案
整體架構
圖1 雲搜監控系統物理架構
圖1是雲搜監控系統的物理架構，具體包括數據採集模塊、數據存儲模塊、告警分發模塊、告警上報模塊、數據可視化模塊五大模塊。
數據採集模塊：
數據採集模塊主要採用以下三種方式協同採集集群數據。
1. 採用Prometheus擴展組件Node-exporter採集底層服務器的各種運行參數，如CPU、diskstats，filesystem，loadavg，meminfo，netstat等信息。
2. 採用Heapster採集Node節點上的cAdvisor數據，作為Node-exporter的有效補充，Heapster能夠按照Kubernetes資源類型來整合資源，如pod，namespace，容器等狀態信息，並將數據輸出到外部存儲，如本例中使用的InfluxDB，為數據可視化呈現提供有效的數據支持。
3. 目前雲蒐集群的組件基本以二進制文件的方式部署，使用1、2中所述的方式無法完全監控到各組件的狀態。因此採用Crontab的方式對集群各組件進行監測並收集數據，同時，支持對異常組件進行遠程恢復。
數據存儲模塊：
數據存儲模塊為數據的可視化呈現提供有效的數據支持，在本例中，採用InfluxDB存儲集群節點及Kubernetes資源對象的狀態信息，併兼容集群已有的MySql數據庫。
告警上報模塊：
在運維過程中，發現郵件報警的查看率較低，報警效果差。在本例中，採用Webhook接入運維側提供的微信報警平臺，第一時間通知相關負責人。
數據可視化模塊：
採用Grafana可視化工具，提供面向集群級的數據展示服務，圖標可定製化，兼容多種數據源，便於用戶監控管理。
在工程實現方面，雲搜監控系統進行了如下設計：
採用命名空間隔離部署方式，將監控系統實例與線上搜索實例相隔離。啟動數據採集組件的服務自動發現，當集群內部的節點和資源對象發生變更時，監控實例也將隨之增加變化，自動發現變更後的節點或對象；
採用多監控實例作用於同一監控對象，使得單一實例失效也不會影響到此對象的監控，滿足高可用的要求；
監控系統所有組件及配置均實現容器化並由Kubernetes編排；在任意 Kubernetes集群裡都能夠一鍵部署；系統需要變更時，僅需修改相關編排文件，即可完成改變。
系統詳細設計
多維度集群監控
多維度集群監控旨在對集群內的資源對象及組件進行監控，並及時的上報異常信息。多維度體現在採用多種數據採集方式對集群內各組件及資源對象進行監控，監控對象主要包括以下幾個方面：
1. 集群基礎組件監控：集群節點宕機、網絡不可用、集群組件異常等；
2. 集群資源對象監控：資源對象狀態監控、容器狀態監控等；
3. 集群服務可用性監控：資源對象可用性監控。
集群基礎資源監控
集群資源對象監控主要依賴Prometheus和Heapster模塊實現，其監控流程如圖2所示。Prometheus和Heapster都是Kubernetes集群內部的監控組件，但在使用場景和功能上有所區別。Prometheus既適用於面向服務器等硬件指標的監控，也適用於高動態的面向服務架構的監控，同時提供報警功能與頁面的展示功能。但在容器監測上，還有所欠缺。cAdvisor是專門用來分析運行中的Docker容器的資源佔用以及性能特性的工具，能夠收集、聚集、處理並導出運行中容器的信息，Heapster通過調用cAdvisor接口獲取當前節點上的數據。在本次設計中，採用Heapster搭配Prometheus的監控方式，對集群各資源狀態及可用性進行統一的監控。
圖2 集群資源對象監控模塊示意圖
集群組件遠程監控
遠程狀態監控模塊是對Prometheus和Heapster監控方式的補充，主要採用拉模式進行對集群組件的數據採集。監控模塊示意圖如圖3所示，監控模塊流程如圖4所示。
圖3 監控模塊示意圖
圖4 監控模塊流程圖
雲蒐集群中Master和Node邏輯上相互獨立，均採用多機互備的方式，其之間的通信是依靠代理層進行流量轉發。在監控上，無法單純依賴容器原生的監控組件對Master和Node進行統一的監控。將監控數據統一彙總到告警上報模塊。
集群資源告警合併
集群內的服務主要以Pod形式存在，每個Pod中包含至少一個容器。當遇到異常情況如宕機、網絡異常時，勢必造成大量的Pod及容器異常。因此，對於同一類告警不再是單條逐個提醒，採用簡化報警，提示關鍵信息的方式，達到預警效果，同時避免告警風暴。
告警合併的關鍵是對Prometheus產生的告警進行分類，這裡，我們採用的方法是自定義Prometheus的Metrics，只收集我們所關心的數據並進行分類。
Prometheus客戶庫提供了四個核心的Metrics類型，分別是Counter、Gauge、Histogram、Summary。這四個類型分別提供了在不同場景下的數據統計方法。我們利用這四類基礎類型，搭配自定義的查詢方法，過濾出我們所需要的告警數據集合。例如我們需要獲取近30m中重啟過的容器數，我們可以定義如圖5所示的過濾表達式：
圖5 Prometheus告警過濾表達式
我們針對30分鐘內出現的容器重啟數量進行過濾。當容器出現異常情況時，Prometheus會首先向Alertmanager推送單條異常告警，如果異常情況大於1條，Prometheus會同時觸發圖5所示的過濾規則，此時Prometheus會將所有的告警合併成一條Json數據推送出來。根據這一特點，在接收到Alertmanager分發的告警時針對告警類型進行過濾，只提出異常情況大於一條的告警數據，從而有效的減少告警數量，監控告警過濾流程如圖6所示。圖7為用戶接收到的告警示例。
圖6 監控告警過濾流程圖
圖7 監控系統告警實例
服務可用性監控
資源對象可用性監控依賴Pod對象的探針檢測機制，被監控的對象需要先內置Liveness和Readiness探針，用來檢測Pod的存活狀態和可讀性，當探針檢測失效，會標記Pod內容器的狀態。從而在集群監控檢測容器狀態時，一旦發現Pod或容器狀態異常，第一時間上報。
定製化的監控呈現
本例中採用了Grafana作為數據的主要呈現平臺，輔助以PromDash進行監控項配置，為管理者提供完善的可視化監控管理平臺。監控報警的選項直接通過修改Configmap資源並實時熱加載，能夠針對不同的監控場景快速的配置監控項目。下圖8為Grafana的數據展示圖表。
圖8 Grafana集群監控數據示例圖
總結與展望
目前雲搜監控系統已經具備以下特性：
高可用：在雲蒐集群中，每個Prometheus監控組件實例均採用多副本方式部署；任意一個Prometheus實例失效都不會影響到監控系統的整體功能。
監控立體化：監控系統已經集成了基礎組件、服務及應用等三個維度的監控告警；
可動態調整：在雲蒐集群架構中，支持對監控組件實例的動態可調。目前雲搜支持通過調整監控組件實例數，來滿足各種規模系統的監控需求。
另外，在不遠的將來，還會在下面幾個方面持續改進雲搜監控系統：
1. 目前系統尚不支持日誌監控及分佈式追蹤等功能，考慮在日後加入ELK進行日誌監控，通過Logstash搭配Elasticsearch方便監控日誌的查詢。
2. 增強監控及告警響應的速度，加入更多的自處理機制。
3. 引入Helm包管理工具管理系統的部署文件，簡化部署的流程。
歡迎大家關注“58架構師”微信公眾號，定期分享雲計算、AI、區塊鏈、大數據、搜索、推薦、存儲、中間件、移動、前端、運維等方面的前沿技術和實踐經驗。
閱讀更多 58架構師 的文章
