2017 年以前，我們運維體系的監控主要還是以 Zabbix 作為主流的解決方案。當時數據庫這部分的監控服務也是使用的監控運維團隊提供的服務。

[[287153]] 

圖片來自 Pexels

總體來說，Zabbix 的功能還是非常強大的，而且使用也比較簡單，基本上寫寫腳本就能實現指定應用的監控。

PS：目前已經不是 Zabbix 了，運維團隊基于 Open-Falcon 定制開發了一套統一的運維監控系統，當然這是后話了。

我們在 2016 年就已經嘗試 MySQL 的容器化，2017 年開始大規模應用。容器化以后 MySQL 數量大幅度上升，通過平臺化進行管理。

原來使用的 Zabbix 已經無法滿足需求：

• 監控指標太多，如果都接入到 Zabbix，服務器無法承受(當時的服務器資源情況下)。
• 數據庫運維平臺對監控告警的管理需要聯動處理。
• 數據庫運維平臺上實例增刪時需要監控系統自動發現實例。
• 有趨勢預測、數據快速統計的需求。
• 對監控指標畫圖有自定義的需求。

所以我們 DB 團隊內部想選型一款監控系統來支撐以上需求。

技術選型

關于數據庫的監控，我們并不想投入太多人力去維護，畢竟監控系統不是我們的主要工作。

所以需要選一款部署簡單、服務器資源占用低、同時又能結合告警功能的監控系統。

雖然目前開源的監控系統還是有不少的，但是最終評估下來，還是選擇了更輕量化的 Prometheus，能夠快速滿足我們數據庫監控的需求。

①易用性

二進制文件啟動、輕量級 Server，便于遷移和維護、PromQL 計算函數豐富，統計維度廣。

②高性能

監控數據以時間為維度統計情況較多，時序數據庫更適用于監控數據的存儲，按時間索引性能更高，數百萬監控指標，每秒處理數十萬的數據點。

③擴展性

Prometheus 支持聯邦集群，可以讓多個 Prometheus 實例產生一個邏輯集群，當單實例 Prometheus Server 處理的任務量過大時，通過使用功能分區(Sharding)+聯邦集群(Federation)可以對其進行擴展。

④易集成性

Prometheus 社區還提供了大量第三方實現的監控數據采集支持：JMX，EC2，MySQL，PostgresSQL，SNMP，Consul，Haproxy，Mesos，Bind，CouchDB，Django，Memcached，RabbitMQ，Redis，Rsyslog等等。

⑤可視化

自帶了 Prometheus UI，通過這個 UI 可以直接對數據進行查詢。結合 Grafana 可以靈活構建精美細致的監控趨勢圖。

⑥強大的聚合語法

內置查詢語言，可以通過 PromQL 的函數實現對數據的查詢、聚合。同時基于 PromQL 可以快速定制告警規則。

實踐

監控的目的

在做監控系統之前，首先我們要明確監控的目的。

在總結相關內容的時候，正好在網上看到了 CNCF 基金會 Certified Kubernetes Administrator 鄭云龍先生基于《SRE：Google 運維解密》對監控目的的總結，總結很到位，所以就直接引用過來了。

引用來源：

https://www.bookstack.cn/read/prometheus-book/AUTHOR.md 

長期趨勢分析：通過對監控樣本數據的持續收集和統計，對監控指標進行長期趨勢分析。

例如，通過對磁盤空間增長率的判斷，我們可以提前預測在未來什么時間節點上需要對資源進行擴容。

告警：當系統出現或者即將出現故障時，監控系統需要迅速反應并通知管理員，從而能夠對問題進行快速的處理或者提前預防問題的發生，避免出現對業務的影響。

故障分析與定位：當問題發生后，需要對問題進行調查和處理。通過對不同監控監控以及歷史數據的分析，能夠找到并解決根源問題。

數據可視化：通過可視化儀表盤能夠直接獲取系統的運行狀態、資源使用情況、以及服務運行狀態等直觀的信息。

一個監控系統滿足了以上的這些點，涉及采集、分析、告警、圖形展示，完善覆蓋了監控系統應該具備的功能。下面就講解我們是如何基于 Prometheus 來打造數據庫監控系統的。

我們的監控系統架構簡介

我們在 2016 年底開始使用到現在，中間也經歷過幾次架構演進。但是考慮到閱讀體驗，被替代的方案就不在這細說了，我們著重講一下目前的架構設計和使用情況。

首先看一下總體的架構：

我們逐個介紹一下上面架構圖中的內容：

①Agent

這是我們用 Golang 開發的監控信息采集 Agent，負責采集監控指標和實例日志。

監控指標包括了該宿主機的相關信息(實例、容器)。因為我們是容器化部署，單機實例數量大概在 4-20 左右。

隨著運維平臺的實例增刪，該宿主機上的實例信息可能會發生變化。所以我們需要 Agent 能夠感知到這個變化，從而決定采集哪些信息。

另外采集間隔時間做到了 10s，監控顆粒度可以做的更細，防止遺漏掉突發性的監控指標抖動。

②Pushgateway

這是我們用的官方提供的組件，因為 Prometheus 是通過 Pull 的方式獲取數據的。

如果讓 Prometheus Server 去每個節點拉數據，那么監控服務的壓力就會很大。

我們是在監控幾千個實例的情況下做到 10s 的采集間隔(當然采用聯邦集群的模式也可以，但是這樣就需要部署 Prometheus Server。再加上告警相關的東西以后，整個架構會變的比較復雜)。

所以 Agent 采取數據推送至 pushgateway，然后由 Prometheus Server 去 pushgateway 上面 Pull 數據。

這樣在 Prometheus Server 寫入性能滿足的情況下，單臺機器就可以承載整個系統的監控數據。

考慮到跨機房采集監控數據的問題，我們可以在每個機房都部署 pushgateway 節點，同時還能緩解單個 pushgateway 的壓力。

③Prometheus Server

將 Prometheus Server 去 pushgateway 上面拉數據的時間間隔設置為 10s。多個 pushgateway 的情況下，就配置多個組即可。

為了確保 Prometheus Server 的高可用，可以再加一個 Prometheus Server 放到異地容災機房，配置和前面的 Prometheus Server 一樣。

如果監控需要保留時間長的話，也可以配置一個采集間隔時間較大的 Prometheus Server，比如 5 分鐘一次，數據保留 1 年。

④Alertmanager

使用 Alertmanager 前，需要先在 Prometheus Server 上面定義好告警規則。我們的監控系統因為是給 DBA 用，所以告警指標類型可以統一管理。

但是也會有不同集群或者實例定義的告警閾值是不同的，這里怎么實現靈活配置，我后面再講。

為了解決 Alertmanager 單點的問題(高可用見下圖)，我們可以配置成 3 個點，Alertmanager 引入了 Gossip 機制。

Gossip 機制為多個 Alertmanager 之間提供了信息傳遞的機制。確保及時在多個 Alertmanager 分別接收到相同告警信息的情況下，也只有一個告警通知被發送給 Receiver。

Alertmanager 支持多個類型的配置。自定義模板，比如發送 HTML 的郵件;告警路由，根據標簽匹配確定如何處理告警;接收人，支持郵件、微信、Webhook 多種類型告警;inhibit_rules，通過合理配置，可以減少垃圾告警的產生(比如機器宕機，該機器上面所有實例的告警信息就可以忽略掉，防止告警風暴)。

我們告警是通過 Webhook 的方式，將觸發的告警推送至指定 API，然后通過這個接口的服務進行二次加工。

 

Prometheus 和 Alertmanager 的高可用

⑤Filter&Rewrite模塊

這個模塊的功能就是實現 MySQL 集群告警規則過濾功能和告警內容改寫。

先說一下告警規則過濾，因為上面提到是統一設置了告警規則，那么如果有 DBA 需要對個別集群的告警閾值調整的話就會很麻煩，為了解決這個問題，我們在 Alertmanager 后面做了 Filter 模塊。

這個模塊接收到告警內容后，會判斷這條告警信息是否超過 DBA 針對集群或者實例(實例優先級高于集群)設置閾值范圍，如果超過就觸發發送動作。

告警發送按照等級不同，發送方式不同。比如我們定義了三個等級，P0、P1、P2，依次由高到低：

• P0，任何時間都會觸發，并且同時觸發電話和微信告警。
• P1，8:00-23:00 只發微信告警，其他時間觸發連續三次才觸發發送。
• P2，8:00-23:00 發送微信告警，其他時間觸發不發送。

下圖是集群和實例的告警閾值管理頁面(這是集成在數據庫運維平臺內部的一個功能)，針對每個集群和實例可以獨立管理，新建集群的時候會根據所選 CPU 內存配置，默認給出一組與配置對應的告警閾值。

 

集群告警規則管理入口

 

實例告警規則管理入口

 

告警規則管理

接著看一下告警內容 Rewrite，比如上圖看到的額外接收人，除了 DBA 有些開發同學也想接收告警。

但是如果給他們發一個 Thread_running 大于多少的告警，他們可能不明白是什么意思，或者什么情況下會出現這個告警，需要關注什么。

所有我們需要做一下告警內容的重寫，讓開發也能看的明白。下圖就是我們改寫過后的內容。

 

告警內容 Rewrite

還有告警關聯，比如某個宿主機的磁盤 IO 高了，但是可能需要定位是哪個實例導致的，那么我們就可以通過這個告警，然后去監控系統里面分析可能導致 IO 高的實例，并且管理報警。

如圖所示：

 

IO 告警關聯實例信息

最后說一下告警收斂，比如宿主機宕機，那么這個宿主機上面的 MySQL 實例都會觸發宕機告警(MySQL 實例連續三個指標上報周期沒有數據，則判定會為實例異常)，大量的告警會淹沒掉重要告警，所以需要做一下告警收斂。

我們是這樣做的，宕機后由宿主機的告警信息來帶出實例的相關信息，一條告警就能看到所有信息，這樣就能通過一條告警信息的內容，得知哪些集群的實例受影響。

如圖所示：

 

宿主機宕機關聯實例

⑥Graph(畫圖)

Prometheus 完美支持 Grafana，我們可以通過 PromQL 語法結合 Grafana，快速實現監控圖的展示。

為了和運維平臺關聯，通過 URL 傳參的方式，實現了運維平臺直接打開指定集群和指定實例的監控圖。

 

實例監控圖

 

集群監控圖

⑦V-DBA

這是一個 DBA 的自動化程序，可以依賴告警信息實現一些指定操作，這里舉一個過載保護的例子，我們的過載保護不是一直開啟的，只有當觸發了 thread_running 告警以后才會關聯過載保護的動作。

具體方案見下圖：

 

⑧告警管理

在運維平臺上，我們有專門的頁面用于管理告警，在手機端也做了適配，方便 DBA 隨時都能連接到平臺查看處理告警。

從下圖中可以看到當前觸發的告警列表，無顏色標注的標識該告警已經被回復(屬于維護性告警，回復以后不發送)，有顏色的這個代表未被回復告警(圖中的這個屬于 P2 等級告警)。

另外可以注意到，這里的告警內容因為是給 DBA 看，所以沒有做改寫。

 

PC 端

 

手機端

基于告警日志，我們結合 ES 和 Kibana 實現了告警數據分析的功能，這種交互式的數據分析展示，能夠幫助 DBA 輕松完成大規模數據庫運維下的日常巡檢，快速定位有問題的集群并及時優化。

 

告警分析

基于 Prometheus 的其他實踐

基于 Prometheus 的方案，我們還做了其他監控告警相關功能擴展。

①集群評分

由于我們做了告警分級，大部分的告警都是 P2 等級，也就是白天發送，以此來降低夜間的告警數量。

但是這樣一來可能會錯過一些告警，導致問題不能及時暴露，所以就做了集群評分的功能來分析集群健康狀況。

并且針對一個月的評分做了趨勢展示，方便 DBA 能夠快速判斷該集群是否需要優化。

如下圖所示：

 

集群評分

點擊詳情，可以進入該集群的詳情頁面?？梢圆榭?CPU、內存、磁盤的使用情況(這里磁盤空間達到了 262%，意思是超過配額了)。

另外還有 QPS、TPS、Thread_running 昨日和 7 日前的同比曲線，用來觀察集群請求量的變化情況。最下面的注意事項還會標出扣分項是哪幾個，分別是哪些實例。

 

詳情頁

②指標預測

針對磁盤空間做了 7 日內小于 200G 的預測，因為多實例部署，所以需要針對當前宿主機上的實例進行當前數據大小、日志大小、日增長趨勢的計算。

DBA 可以快速定位需要遷移擴容的節點實例。實現方法就是用了 Prometheus 的 predict_linear 來實現的(具體用法可以參照官方文檔)。

 

磁盤空間預警

日志相關

①SlowLog

SlowLog 管理，我們是通過一套系統來進行收集、分析的，因為要拿到原生日志，所以就沒有采用 pt-query-digest 的方式。

架構如下：

 

通過 Agent 收集，然后將原始的日志格式化以后以 LPUSH 方式寫入 Redis(由于數據量并不大，所以就沒有用 Kafka 或者 MQ)，然后再由 slow_log_reader 這個程序通過 BLPOP 的方式讀出，并且處理以后寫入 ES。

這個步驟主要是實現了 SQL 指紋提取、分片庫庫名重寫為邏輯庫名的操作。

寫入 ES 以后就可以用 Kibana 去查詢數據。

 

對接到面向開發的數據庫一站式平臺，業務開發的同學可以查詢自己有權限的數據庫，同時我們也集成了小米開源的 SOAR，可以用這個工具來查看 SQL 的優化建議。

 

通過 ES 進行聚合，可以給用戶訂閱慢查詢的報表，有選擇性的查看相關庫的 TOP 慢 SQL 信息信息，有針對性的鏡像優化。

 

②Processlist，InnoDBStatus 數據采集

為了能夠在故障回溯或者故障時查看當時的會話快照和 InnoDBStatus，我們在監控 Agent 中內置了這個功能，也是每 10 秒一次，區別是會判斷當前 ThreadRunning 是否到達閾值，如果到達才會采集數據，否則不采集。

這樣的設定既解決了無用日志太多的問題，又解決了性能異常時能夠獲取到狀態信息。

下圖是日志采集處理的邏輯，其中日志處理模塊是和慢查詢處理在一個程序中，會話快照的處理邏輯和慢查詢類似，這里就不贅述了。

 

總結

監控系統沒有絕對的誰好誰不好，最重要的是適合自己的團隊，能夠合理利用最小的成本解決問題。

我們從 2016 年開始使用 1.x 版本到線下的 2.x 版本，目前基于 Prometheus 的監控系統，承載了整個平臺所有實例、宿主機、容器的監控。

采集周期 10秒，Prometheus 1 分鐘內每秒平均攝取樣本數 9-10W。

1 臺物理機(不包括高可用容災資源)就可以承載當前的流量，并且還有很大的容量空間(CPU\Memory\Disk)。如果未來單機無法支撐的情況下，可以擴容成聯邦集群模式。

另外本文中提到的監控系統只是我們運維平臺中的一個模塊，并不是一個獨立的系統，從我們實踐經驗來看，最好是可以集成到運維平臺中去，實現技術棧收斂和系統產品化、平臺化，降低使用的復雜的。

最后說說在監控方面我們未來想做的事情，目前我們監控數據有了，但是告警只是發送了指標的內容，具體的根因還需要 DBA 分析監控信息。

我們計劃在第一階段實現告警指標相關性分析后，可以給出一個綜合多個監控指標得出的結論，幫助 DBA 快速定位問題;第二階段能夠更加分析結果給出處理建議。

最終依賴整個監控體系，降低運維的復雜度，打通運維與業務開發直接的溝通壁壘，提升運維效率和服務質量。

作者：閆曉宇

簡介：同程藝龍數據庫技術專家，具有多年互聯網行業 DB 運維經驗，在游戲、O2O 及電商行業從事過 DBA 運維工作。2016 年加入同程藝龍，目前在團隊負責數據庫架構設計及優化、運維自動化、MySQL 監控體系建設、DB 私有云平臺設計及開發工作。