基于 Prometheus+Grafana 實現(xiàn)新華全媒新聞服務平臺統(tǒng)一運維監(jiān)控

鐘盈炯

（新華社通信技術局，北京 100803）

導語

新華全媒新聞服務平臺是按照新華社供稿線路優(yōu)化調(diào)整的總體要求，基于云計算和微服務技術架構，重構新華社轉(zhuǎn)型發(fā)展時期的供稿技術體系，建成包括所有新華社文字、圖片、圖表、視頻、新媒體、多媒體、歷史資料的全媒體供稿平臺。Docker容器技術將作為云計算領域的代表技術之一，以鏡像方式交付，以容器方式運行，使得軟件所依賴的環(huán)境與標準環(huán)境相同，只需要進行一次構建，即可實現(xiàn)重復部署。用微服務來重新定義架構體系已成為業(yè)內(nèi)系統(tǒng)設計和技術實現(xiàn)的熱門方向和首要選擇。

本文首先對Docker、Prometheus和Grafana進行了介紹，然后說明了基于Docker部署的微服務架構全媒平臺，提出了其采用的Prometheus+Grafana實現(xiàn)企業(yè)級系統(tǒng)監(jiān)控的設計方案和實現(xiàn)過程，最后展示了部分可視化輸出效果。

1.Docker簡介

Docker是一個被廣泛使用的開源容器引擎，是一種操作系統(tǒng)級別的虛擬化技術，它以一種特殊進程的方式運行于宿主機上，它依賴于liunx內(nèi)核特性：namespace（名字空間進行資源的隔離）和cgroups（限制、記錄任務組所使用的物理資源），它也可以對應用程序進行打包。Docker是一種基于LXC的輕量級虛擬化技術，基于 Go語言開發(fā)，并遵循 Apache2.0協(xié)議。[9]其主要目標是“Bulid ，Shop and Run Any App，Anywhere”。即利用Docker容器的特點，對資源進行分割和調(diào)度，主要面向于開發(fā)者與系統(tǒng)管理員，最終實現(xiàn)一個分布式平臺，主要負責管理應用組件的整個生命周期。使用Docker容器技術，可以對應用進行高效、敏捷且自動化的部署，同時結合操作系統(tǒng)內(nèi)核技術（namespaces，cgroups 等），為 Docker 容器的安全與資源隔離提供了技術保障。[1]

2. Prometheus與Grafana概述

Prometheus是由SoundCloud開發(fā)的開源監(jiān)控報警系統(tǒng)和時序列數(shù)據(jù)庫（TSDB）。[2]

Prometheus 使 用Go語言開發(fā)，是Google BorgMon監(jiān)控系統(tǒng)的開源版本。 2016年由Google發(fā)起Linux基金會旗下的原生云基金會（Cloud Native Computing Foundation），將Prometheus納入其下第二大開源項目。 Prometheus目前在開源社區(qū)相當活躍。Prometheus和Heapster（Heapster）是K8S的一個子項目，用于獲取集群的性能數(shù)據(jù)。相比功能更完善、更全面。Prometheus性能也足夠支撐上萬臺規(guī)模的集群部署。[2]

Grafana是開源的、炫酷的可視化監(jiān)控、分析利器[3]，擁有快速靈活的客戶端圖表和模塊工具，面板插件有許多不同方式的可視化指標和日志，官方庫中具有豐富的儀表盤插件，比如熱圖、折線圖、圖表等多種展示方式，讓復雜的數(shù)據(jù)展示得美觀而優(yōu)雅。支持許多不同的時間序列數(shù)據(jù)庫作為其數(shù)據(jù)來源的源頭，諸如本文中提及的Prometheus。

3. Prometheus+Grafana設計實現(xiàn)企業(yè)級系統(tǒng)運維監(jiān)控

運維監(jiān)控系統(tǒng)的實現(xiàn)過程是，將基礎平臺和業(yè)務系統(tǒng)中所涉及的硬件資源信息、基礎組件信息、應用軟件信息等統(tǒng)一納入運維監(jiān)控平臺，并進行指標的規(guī)范、收集及統(tǒng)一集中存儲。以可用性指標為基礎，逐步增加服務質(zhì)量相關指標。實現(xiàn)系統(tǒng)運維監(jiān)控的規(guī)范化和故障告警處理的智能化。

運行監(jiān)控和故障告警是運維監(jiān)控系統(tǒng)的兩個主要功能組成部分。根據(jù)上述實現(xiàn)思路，統(tǒng)一運維監(jiān)控平臺的實現(xiàn)架構設計如圖1所示，劃分為三大組成部分，分別是數(shù)據(jù)采集、數(shù)據(jù)提?。ù鎯Γ┖蛿?shù)據(jù)展示及報警提示。數(shù)據(jù)采集模塊主要是部署Exporter等監(jiān)控工具，獲取各類基礎數(shù)據(jù)，當針對具體的應用實現(xiàn)時，運維人員需要編寫代碼獲取應用的監(jiān)控指標，并格式化為Prometheus的數(shù)據(jù)格式形式；數(shù)據(jù)提?。▋Υ妫┲饕菍⒅笜藬?shù)據(jù)存儲到Prometheus時序數(shù)據(jù)庫中，主要用來存儲和查詢監(jiān)控的指標數(shù)據(jù)；數(shù)據(jù)展示及報警提示模式主要是通過運用Grafana以及郵件、微信等外圍輸出工具，實現(xiàn)基礎環(huán)境和業(yè)務系統(tǒng)監(jiān)控指標的可視化展示和告警信息的輸出。

圖1 運維監(jiān)控設計實現(xiàn)架構圖

4.基于容器微服務架構部署的全媒平臺系統(tǒng)

4.1 微服務簡介

微服務架構是一種面向互聯(lián)網(wǎng)應用服務的軟件開發(fā)架構[4]，主要應用于互聯(lián)網(wǎng)應用服務的服務端軟件開發(fā)，由面向服務架構 SOA 發(fā)展而來。微服務架構提倡將單體架構應用劃分成一組小的服務，服務之間互相協(xié)調(diào)、互相配合。

4.2 從傳統(tǒng)向微服務開發(fā)框架轉(zhuǎn)移

筆者所在單位的原有全媒平臺是基于開源的dubbo框架設計搭建而成，龐大而復雜，此架構對敏捷開發(fā)和迭代優(yōu)化部署較為繁瑣，尤其是在迭代升級和版本回退時較為困難。

本文中提及的現(xiàn)有全媒平臺，由傳統(tǒng)的服務架構向基于Spring Cloud的微服務架構轉(zhuǎn)移，通過調(diào)用本地Consul客戶端Consul服務器注冊、發(fā)現(xiàn)和消費。向Consul服務器注冊時，發(fā)告知其IP和端口，注冊后，會每隔一定時間發(fā)送健康檢查，當需要消費時，先去Consul服務器上拿到一個含有IP和端口的臨時表，再去Get實際的路由。

圖2 服務發(fā)現(xiàn)方式

4.3 業(yè)務服務部署架構

為實現(xiàn)全球站點部署，在設計業(yè)務的服務架構中充分考慮到業(yè)務的增減和變更情況。具體有：gateway（應用服務路由網(wǎng)關）、doc-view（稿件查看）、doc-server（稿件服務）、auth（用戶認證授權）、management（后臺資源管理）、consul server（服務注冊與發(fā)現(xiàn)）和稿件入庫等。其業(yè)務部署架構圖如下所示。

圖3 業(yè)務服務部署架構圖

4.4 容器化部署實施

在上述對各個微服務模塊進行細分的前提下，實現(xiàn)服務模塊化打包、持續(xù)集成持續(xù)交付（CI/CD）的自動化運維服務能力。在此，筆者項目組使用Docker，方便地以“容器化”的方式去部署應用服務，它在鏡像中打包了所有應用所需要的環(huán)境，正所謂一次構建，處處運行。為了方便對 Docker容器進行規(guī)模化和集群化管理，谷歌公司推出的Kubernetes（簡稱K8s）的容器集群管理系統(tǒng)。Kubernetes 主要包括容器集群的自動化部署、自動擴縮容、容器維護管理等功能模塊。[5]在該項目中，使用K8s對各個應用Docker容器進行統(tǒng)一的管理，根據(jù)業(yè)務所需和訪問情況動態(tài)擴充，以保證系統(tǒng)服務的穩(wěn)定性、安全性和可靠性。

5.搭建服務于全媒平臺的企業(yè)級運維監(jiān)控平臺

5.1 功能架構

圖4 統(tǒng)一運維監(jiān)控平臺功能架構圖

平臺主要分為指標數(shù)據(jù)采集、指標存儲、可視化展現(xiàn)、告警管理4個主要功能模塊。指標采集模塊負責對所有的指標接口進行數(shù)據(jù)采集，并將采集到的時序指標數(shù)據(jù)存入指標存儲時序數(shù)據(jù)庫中進行長期存儲，可視化展現(xiàn)模塊利用這些時序數(shù)據(jù)進行指標的各種展現(xiàn)形式的可視化呈現(xiàn)，告警管理模塊則根據(jù)告警規(guī)則，結合時序數(shù)據(jù)進行規(guī)則匹配，若觸發(fā)規(guī)則，則在分組去重后進行告警通知。

5.2 技術架構及實現(xiàn)

圖5 運維監(jiān)控設計實現(xiàn)架構圖

平臺依托于開源技術、產(chǎn)品與自主研發(fā)的相關模塊構建。底層依托容器環(huán)境運行。

主要開源技術、產(chǎn)品的選型介紹如下：

Prometheus（詳情請見本文3中簡述）。

在本系統(tǒng)中作為二級抓取服務，由于具有Web UI服務，所以更方便各二級抓取負責人員進行調(diào)試、更新、維護。

Grafana（詳情請見本文3中簡述）。

查詢分析時序數(shù)據(jù)庫中的時序數(shù)據(jù)然后進行可視化展示。

VictoriaMetrics

VictoriaMetrics套件中的指標集中存儲組件，是一個支持高可用、消耗低、可伸縮的時序數(shù)據(jù)庫，用于Prometheus標準時序指標數(shù)據(jù)的長期存儲。

vmagent

VictoriaMetrics套件中的指標采集組件，可以比Prometheus更高效、資源占用更低的采集海量時序指標數(shù)據(jù)。

vmalert

VictoriaMetrics套件中的告警指示組件，其執(zhí)行一系列給定的rule（基于MetricsQL，PromQL的超集），然后發(fā)送告警信息到Alertmanager組件。

Alertmanager

告警通知組件。其接收vmalert發(fā)送的告警信息，并通過各種告警通知渠道發(fā)送告警信息?？梢宰龅礁婢畔⑦M行去重，降噪，分組，策略路由。

lanxin-gateway

藍信消息網(wǎng)關組件。接收Alertmanager發(fā)送的告警信息，進行預處理和格式轉(zhuǎn)換后通過調(diào)用藍信群消息接口將告警消息發(fā)往相應藍信告警群。

5.3 部署架構

圖6為運維監(jiān)控平臺部署架構示意圖，計劃在全球四大供稿站點和北京總社部署一臺或者多臺服務器，用于部署相應監(jiān)控組件的服務。具體從功能上分為在4個應用服務站點部署二級抓取服務器，收集本站點的監(jiān)控信息，統(tǒng)一收集后，發(fā)送至總社統(tǒng)一匯總統(tǒng)一管理；在北京總社部署集中指標收集服務器和核心服務器。

圖6 運維監(jiān)控部署架構圖

5.3.1 核心服務層

圖6從上向下看，最上一層為核心服務層。主要負責時序數(shù)據(jù)的存儲，同時有告警規(guī)則運算服務alert負責告警規(guī)則的匹配運算，告警服務Alertmanager負責告警消息分組去重及分發(fā)，可視化展示服務Grafana提供指標展示。具體就是接收數(shù)據(jù)收集層發(fā)來的格式化規(guī)范化的數(shù)據(jù)，進行分析篩選，統(tǒng)一存儲至時序數(shù)據(jù)庫中，Grafana調(diào)用時序數(shù)據(jù)庫中的各類數(shù)據(jù)，選用合適的展示模板供用戶查看，同時根據(jù)業(yè)務需要和業(yè)務要求編寫各類告警規(guī)則，輸出報警數(shù)據(jù)。

圖6中間一級抓取層和最下面二級抓取層主要是收集服務器主機的基礎數(shù)據(jù)、基礎組件數(shù)據(jù)和所監(jiān)控應用的服務數(shù)據(jù)等，將所收集到的數(shù)據(jù)進行標準化，提供給Prometheus的服務采集接口。具體為：

一級抓取層。負責拉取對應區(qū)域所有二級抓取機中抓取到的指標數(shù)據(jù)，并將這些數(shù)據(jù)存儲到核心服務器的時序數(shù)據(jù)庫中。一級抓取會將指標數(shù)據(jù)同時推送到總社的核心服務器上進行存儲，保證數(shù)據(jù)可用性。

二級抓取層，負責抓取所管轄服務站點內(nèi)的指標數(shù)據(jù)。具體抓取的數(shù)據(jù)有：抓取所有站點物理機和虛擬機的系統(tǒng)數(shù)據(jù)及基礎組件的指標數(shù)據(jù)；全媒平臺所涉及的4個站點的重要應用服務接口的指標數(shù)據(jù)，所獲取的指標數(shù)據(jù)需足以保證足以覆蓋業(yè)務服務狀態(tài)的安全、可靠和穩(wěn)定。

5.4 環(huán)境搭建實現(xiàn)過程

5.4.1 數(shù)據(jù)收集配置過程

在4個站點和總社匯總點，搭建統(tǒng)一運維監(jiān)控集群服務。分為總社匯總、一級抓取和二級抓取。

在各個站點安裝exporter，實現(xiàn)基礎數(shù)據(jù)的采集。主要指標數(shù)據(jù)分為CPU、內(nèi)存、文件系統(tǒng)、磁盤、網(wǎng)絡、TCP連接數(shù)等方面。包括CPU 各模式秒數(shù)、5 分鐘平均負載、內(nèi)存總/空閑/可用字節(jié)數(shù)、文件系統(tǒng)總/可用字節(jié)數(shù)、mysql、mongoDB、Nginx、es、redis等多項關鍵指標。

在各個站點部署應用的指標采集程序，安裝白盒黑盒探針及日志分析服務等，轉(zhuǎn)化為Prometheus可以識別可以支持的數(shù)據(jù)格式，轉(zhuǎn)換為上一級可以提取的數(shù)據(jù)格式。

5.4.2 數(shù)據(jù)展示配置過程

登錄總社服務器，安裝Grafana。（如果查看各個站點收集數(shù)據(jù)的展示情況，也可在分站點安裝Grafana）。

通過Web服務連接Grafana，使用管理員賬戶登錄Grafana，配置連接的時序數(shù)據(jù)庫數(shù)據(jù)源。

選用合適的展示模塊，如當前沒有，從官網(wǎng)獲取相應的Json文件或者模塊編號，將其導入Grafana中。

綜合分析業(yè)務展示方式和展示效果，選取所需要的各類數(shù)據(jù)，包括基礎數(shù)據(jù)和應用服務指標數(shù)據(jù)，將其展示到Grafana的Web界面中。

5.4.3 告警規(guī)則配置過程

Grafana的告警觸發(fā)以panel為基礎，即每個panel單獨配置告警信息，包括告警規(guī)則、觸發(fā)條件、告警通知通道及內(nèi)容。

指定所需要修配配置的通道，修改Grafana配置文件（grafana.ini）。

登錄Grafana Web服務界面，進入設置區(qū)，接收告警的通道，并配置相應的閾值。

6.整體界面效果

根據(jù)配置的Granfa服務地址和端口，登錄Grafana Web服務，配置連接對應的時序數(shù)據(jù)庫，將收集到的格式化數(shù)據(jù)統(tǒng)一展示在運維監(jiān)控大屏之中，巧妙選擇不同的顯示顏色和不同的展示方式，將數(shù)據(jù)平面化、圖形化、易讀化，便于運維值班人員隨時查看了解系統(tǒng)賴以運行的基礎環(huán)境和網(wǎng)絡的實時工作情況，第一時間獲取系統(tǒng)運行的狀態(tài)信息和報警信息。

6.1 全媒平臺監(jiān)控概覽

圖7展示了全媒平臺業(yè)務、端口、接口和進程的總體情況。如某個模塊顏色變紅，則說明存在報警情況，將鼠標放置在某一面板左上的超鏈接圖標上，即顯示下鉆詳情的超鏈接，點擊可進入相應的二級監(jiān)控頁查看詳情。左下部分為新供稿2.0四個站點的撥測詳情。如某個模塊顏色變紅，則說明存在報警情況，點擊相應模塊可進入二級監(jiān)控頁查看詳情。

圖7 全媒平臺統(tǒng)一監(jiān)控總覽

6.2 全媒平臺二級監(jiān)控細覽

圖8和圖9展示了業(yè)務系統(tǒng)中涉及的進程服務狀態(tài)和端口服務狀態(tài)，圖10和圖11展示了業(yè)務系統(tǒng)中部署的基礎環(huán)境和網(wǎng)絡環(huán)境的整體情況，下圖的顏色會變成黃色或者紅色等不同顏色狀態(tài)信息，以方便運維人員通過顏色及時獲知系統(tǒng)的運行情況。

圖8 全媒平臺二級撥測詳情

圖9 全媒平臺二級端口服務詳情

圖10 全媒平臺CPU/內(nèi)存情況

圖11 全媒平臺網(wǎng)絡基礎環(huán)境情況

結語

簡單而又直觀的監(jiān)控信息展示，是系統(tǒng)運維的利器，正確而又及時地監(jiān)控報警是服務穩(wěn)定的基礎。隨著微服務架構設計理念應用到全媒平臺的實際生產(chǎn)應用中，開源的Prometheus+Grafana天然組合，因其簡單、穩(wěn)定、可靠和易擴展等特點，成為搭建企業(yè)級運維監(jiān)控平臺的首選環(huán)節(jié)。筆者在本文中所闡述的設計方案和實施細節(jié)，有效助力了全媒平臺運維人員的運維效率和運維能力，從而進一步保障了系統(tǒng)的穩(wěn)定可靠運行，成為當前系統(tǒng)運維不可或缺的組成部分。