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