?一、監控工具簡介

1、Zabbix

Zabbix 是由Alexei Vladishev開源的分布式監控系統，是一個企業級的分布式開源監控方案。2004年3月發布1.0 穩定版，比Prometheus早了10年以上。能夠監控各種網絡參數以及服務器健康性和完整性的軟件。使用靈活的通知機制，允許用戶為幾乎任何事件配置基于郵件的告警。

后端使用數據庫存儲監控配置和歷史數據，可以較為方便地對接數據分析、報表定制等渠道，在前端開放了豐富的 RESTful API 供第三方平臺調用，整體架構符合當前 DevOps 的趨勢。

2、Prometheus

Prometheus是由前Google員工創辦公司SoundCloud開發的開源監控報警系統和時序列數據庫。相對于k8s是Google Borg系統的開源實現，Prometheus是Google BorgMon的開源實現。

Prometheus 由兩個部分組成，一個是監控報警系統，另一個是自帶的時序數據庫（TSDB）。

Prometheus 在開源社區十分活躍，在 GitHub 上擁有四萬多Star，并且系統每隔兩三周就會有一個小版本的更新，Prometheus 與它的“師兄”k8s 自帶云原生的光環，天然能夠友好協作。

二、架構對比

1、Zabbix 架構

Zabbix Server?

核心組件，C 語言編寫，負責接收 Agent、Proxy 發送的監控數據，也支持 JMX、SNMP 等多種協議直接采集數據。同時，它還負責數據的匯總存儲以及告警觸發等。

Zabbix Proxy?

可選組件，對于被監控機器較多的情況下，可使用 Proxy 進行分布式監控，它能代理 Server 收集部分監控數據，以減輕 Server 的壓力。

Zabbix Agentd?

部署在被監控主機上，用于采集本機的數據并發送給 Proxy 或者 Server，它的插件機制支持用戶自定義數據采集腳本。

Agent 可在 Server 端手動配置，也可以通過自動發現機制被識別。數據收集方式同時支持主動 Push 和被動 Pull 兩種模式。

• Database?

用于存儲配置信息以及采集到的數據，支持 MySQL、Oracle 等關系型數據庫。同時，最新版本的 Zabbix 已經開始支持時序數據庫，不過成熟度還不高。

• Web Server?

Zabbix 的 GUI 組件，PHP 編寫，提供監控數據的展現和告警配置。

2、Prometheus架構

• Prometheus Server?

用于定時抓取數據指標（metrics）、存儲時間序列數據(TSDB)，TSDB在存儲監控的性能會優于傳統關系型數據庫。

• Jobs/exporters?

Prometheus 使用各種 exporter 進行監控，exporter 的功能類似于 Zabbix 的 Agent，負責收集監控對象端的數據。

• Pushgateway?

監控端的數據會用push的方式主動傳給此組件，隨后被 Prometheus 服務定時 pull 此組件數據即可。

• Alertmanager?

報警組件，類似于Zabbix的Action，可以進行報警觸發，比如發送短信和郵件。

Web UI 用于多樣的UI展示，一般為Grafana，還有一些例如配置自動發現目標的小組件和后端存儲組件。

三、Zabbix和Prometheus優劣 

1、Zabbix的優勢

• 產品成熟?

由于誕生時間長且使用廣泛，擁有豐富的文檔資料以及各種開源的數據采集插件，能覆蓋絕大部分監控場景，支持很多不同類型的設備和平臺。

• 采集方式豐富?

支持Agent、SNMP、JMX、SSH 等多種采集方式，以及主動和被動的數據傳輸方式，Agent可以更好地進行統一標準化配置。

• 較強的擴展性?

支持 Proxy 分布式監控，有Agent 自動發現功能，插件式架構支持用戶自定義數據采集腳本。

• 配置管理方便?

能通過Web界面進行監控和告警配置，操作方便，上手簡單。

2、Prometheus的優勢

• 較強的處理能力?

監控數據直接存儲在 Prometheus Server 本地的時序數據庫中，單個實例可以處理數百萬的 Metrics。

• 靈活的數據模型?

引入了Tag，屬于多維數據模型，聚合統計更方便，支撐不同團隊個性化展現。

• 強大的查詢語句?

PromQL 允許在同一個查詢語句中，對多個 Metrics 進行加法、連接和取分位值等操作。

• 支持云環境?

能自動發現容器，同時 K8s 和 Etcd 等項目都提供了對 Prometheus 的原生支持，是目前容器監控最流行的方案。

3、對比

Zabbix 屬于老牌的監控系統，資料多，功能全面且穩定，90%以上的配置可以通過Web 端統一操作和實現，比強依賴于配置文件的 Prometheus 要更為方便。

Prometheus有靈活的數據模型、更成熟的時序數據庫，大數據量情況下性能更高。支持和Grafana 做快速集成，組合美觀且強大的可視化體驗，支持為不同團隊提供更個性化的展現。

純容器的環境，毫無疑問Prometheus是更適合的選擇，Prometheus是天生為容器化平臺打造的監控系統，環境很復雜，有各種操作系統、硬件、中間件、數據庫、機房等，那么Zabbix更適合的監控平臺，Zabbix兼顧了監控的深度和廣度，實現了統一監控平臺的目的；但當監控服務器上萬，或者監控周期較長，超過了一年，需要面向不同團隊靈活可視化展現時，Prometheus又有很強的優勢。

四、Zabbix使用現狀

公司按照業務線已經劃分多套zabbix，運行穩定，但監控數據分散，無法集中化管理，多維度可視化能力較弱，數據存儲周期過短，不方便容量預測和管理。

實時監控數據

監控趨勢圖

主機組

?

1、Zabbix 數據庫表結構

1）配置數據

① hosts表

存儲被監控主機的信息。

常用字段介紹如下：

• Hostid：唯一標識Host在Zabbix及數據庫中的id。不同表之間的關聯也要用hostid。
• Proxy_hostid：若啟用“proxy-server”架構，才會出現被監控機器的proxy_hostid。
• Host：被監控機器的名字。
• Status：機器目前的狀態。“0”為正常監控，“1”為disable。

② items表

存儲所有監控項，利用hostid在items表中查詢該主機有那些監控項，itemid為監控項的id，name為監控項的名稱，key_為鍵值，也就是表達式，怎么對監控項取值。

• itemid：item的id。
• type：item的type，和前端見面配置item的type的對應。數據庫中，這一列的值是0到17的數字，分別代表不同的類型。
• hostid：item所在的host的hostid。如果該item是屬于template，那么這里顯示的是templateid。
• name：item的名字。
• key_：item的key。
• status：item的狀態。
• value_type：item返回值的類型，配置item時候配置的“Type of Information”。

③ hosts_groups表

存儲了host（主機）與host groups（主機組）的關聯關系。

④ Host_groups表

主機組，zabbix上主機組命名規范化，方便多維度查找。

姓名_部門_產品_集群名

⑤ problem表

存儲問題事件。

查詢當前未恢復的問題事件Top10  并將時間戳轉換為格式化時間。

SELECT p.eventid as 事件id,FROM_UNIXTIME(p.clock,'%Y-%m-%d %H:%i:%s') as clock,p.name as 觸發事件,p.severity as 事件等級 FROM problem p WHERE p.source='0' AND p.object='0' AND NOT EXISTS (SELECT NULL FROM event_suppress es WHERE es.eventid=p.eventid) AND p.r_eventid IS NULL ORDER BY p.eventid DESC LIMIT 10;

2）歷史數據

Zabbix系統針對每個監控項在每次采集時所收集到的數據，這個數據保存Zabbix系統數據庫的歷史表中。監控的主機的數量較多的時候，zabbix系統每臺產生的數量是非常龐大的，這對數據庫是一種負擔。建議對數據庫進行分區或盡量減小歷史數據的保留天數，以免給數據庫系統帶來很大的壓力。

①history表：?存儲信息類型為浮點數的監控項歷史數據。

• history_log表：?存儲信息類型為日志的監控項歷史數據。
• history_str表：?存儲信息類型為字符的監控項歷史數據。
• history_text表：?存儲信息類型為文本的監控項歷史數據。
• history_uint表：?存儲信息類型為數字(無正負)的監控項歷史數據。

② history表結構

• itemid: 監控項唯一標識id。
• clock: 時間戳整數部分。
• value：監控項的值。
• ns：納秒數。

查詢 2022/06/07 00:00:00 -2022/06/08 00:00:00 itemid 29175 浮點數監控項歷史數據。

select itemid,from_unixtime(clock) as time,value from  history where itemid=29175 and clock >= unix_timestamp('2022/06/07 00:00:00') and clock <= unix_timestamp('2022/06/08 00:00:00');

五、super_exporter

為了解決zabbix存在的不足，我們進行了zabbix和Prometheus融合監控項目，通過為每套zabbix數據庫開發部署一套super_exporter，定期從數據庫抓取該zabbix下的所有監控服務器性能數據，上報給Prometheus。為了減輕主數據庫壓力，提升響應速度，為每套zabbix新增一個獨立從庫，專門為super_exporter抓取數據使用。

prometheus配置抓取任務，主機多的情況下，單個zabbix下總監控項會達到上萬，性能優化后確?？倛绦袝r間不超過30s。

Metrics返回該zabbix管理的所有監控主機對應的多個監控項性能指標，涉及dba,host,產品部門，產品，集群，機房等標簽。

super_exporter從hosts表獲取本zabbix實例管理的監控主機集合，從hstgrp表獲取主機對應運維負責人、部門、產品、集群名等業務層多維數據。從zabbix實例本身部署情況獲取機房位置等數據，從items獲取需要集中管理的監控項，從history類表抓取最近采集周期的監控數據。

六、Grafana展現

通過抓取zabbix匯聚的監控數據，存于TSD時序數據庫，利用PromQL語言進行相關監控項的多標簽聚合計算。使用grafana靈活強大的多維度可視化能力，方便及時地進行性能風險識別，進行長生命周期的資源容量預估。

通過數據行列轉化，實例健康指數積分計算和排序，風險實例頭部展示，臨近性能值趨勢對比，實時查看實例整體運行情況。

實時聚合多機房zabbix監控告警，集中化展現當前告警項；同時記錄歷史告警，審計告警趨勢。

zabbix和prometheus融合，能夠結合zabbix的成熟生態、配置靈活性和Prometheus的存儲、展現優勢，提供更強大的監控能力，支撐家庭業務百億級人機物連接相關監控數據存儲。單個Prometheus支持百萬級Metrics,但隨著接入zabbix的增多，監控數據時間存儲周期拉長，未來將引入Thanos進行Prometheus長期化存儲。同時super_exporter未來對接cmdb系統，匹配更多的業務標簽數據，支持更多維的統計計算能力，滿足公司不同團隊的定制化數據展示需求。?