開源的監控產品有很多，其中最知名的，當屬早期的 Zabbix 和現在的 Prometheus。Zabbix 是 2001 年發佈的，至今已經 20 多年，很多細節打磨的相當到位，Prometheus 是 2014 年發佈的，相對年輕，依託於之前 Google Borgmon 的先進經驗和靈感，Prometheus 在雲原生監控領域有着非常好的表現。
　　咦？你怎麼沒有提到你們自己開源的 Nightingale？Nightingale 的確是我們主推的監控產品，姑且可以看做是 Prometheus 生態的補充者，一般使用 Prometheus 的用户很多都會同時部署 Nightingale，二者是協同關係，這類用户一般使用 Nightingale 做告警引擎，使用 Grafana 看圖。但要説社區影響力，顯然 Zabbix 和 Prometheus 更厲害，這一點毋庸置疑。
　　對 Zabbix 和 Prometheus 的選型對比，實際不僅僅是對比這兩個軟件本身，而是在對比兩個生態。我們從一些關鍵點來對比這兩個監控系統。
　　性能容量對比
　　Zabbix 使用 MySQL 或 Postgres 存儲時序數據，因為 2001 年，還沒有時序庫呢，所以 Zabbix 的數據存儲是關係型數據庫。這就導致了 Zabbix 在數據量大的時候，性能會有問題，因為關係型數據庫不是為時序數據設計的。而 Prometheus 使用的是自家的 TSDB，專門為時序數據設計，性能更好，而且 Prometheus 有很多優化措施，比如 WAL、Compaction 等，可以保證在大數據量的情況下，性能依然很好。
　　如果 Prometheus 本身性能扛不住了，或者需要集羣方案，Prometheus 生態有 VictoriaMetrics，有 Thanos、GrepTimeDB 等。在容量方面，Prometheus 完勝，這點相信大家都有共識。
　　監控數據採集
　　Zabbix 期望做一個大一統的監控系統。所以採集方面更多是依賴自身的力量，而 Prometheus 卡位清晰，把紛繁複雜的採集工作交給社區來完成，社區裏涌現了非常多的 Exporter，比如 Node Exporter、Blackbox Exporter、MySQL Exporter 等等，這些 Exporter 為 Prometheus 提供了豐富的監控數據。
　　Zabbix 把監控數據的採集配置，內置到了產品中，用户可以在 Zabbix 的頁面裏配置哪些機器啓用哪些採集項。由於監控數據的採集種類繁多，採集方式多樣，而且有數據二次處理的需求，Zabbix 要解決所有這些需求，整體就顯得比較複雜，比如 Zabbix 的 LLD（Low Level Discovery）功能、數據的 Process、Mapping、主 item 等等邏輯，都內置到產品配置中了，看起來挺齊全，但是學習成本也比較高。
　　而 Prometheus 生態的玩法完全不同，Prometheus 定義了一個數據模型規範，由社區實現採集器（Exporter），然後對接起來即可，Exporter 解決數據的採集、轉換等問題。所以 Prometheus 服務端不需要做很複雜的數據採集的配置，只需要配置好監控對象的地址即可，這樣的設計讓 Prometheus 的學習成本大大降低。但是，不同的 Exporter 的處理邏輯各異，一致性不好，甚至配置文件的格式都是不同的，這也是 Prometheus 的一個缺點。
　　另外，Zabbix 因為發佈的時間比較早以及創始人的銀行運維背景，Zabbix 對各類老舊 OS 支持的比較好，比如 AIX、BSD 等，而 Prometheus 主要是支持 Linux 和 Windows。
　　另外，Zabbix 是典型的面向資產的管理方式，添加一個機器、網絡設備，然後給這個機器、網絡設備綁定模板，自動應用模板中的採集項，這在早幾年確實是合理的，但是隨着微服務、Kubernetes 等技術的普及，服務端環境變得越來越動態化。Prometheus 生態提供的服務發現以及指標帶有標籤的數據模型，更適合這種動態環境。
　　Zabbix 雖然也支持採集各類中間件的數據，但主要是通過各類採集腳本來實現的，相比 Prometheus 生態的各類 Exporter，Zabbix 的方式顯得有些笨重。而且數據完備性不如 Prometheus 的各類 Exporter。
　　Prometheus 只支持採集存儲數值型時序數據，而 Zabbix 還支持採集字符串，在一些場景下還蠻有用的。如果是元信息類的數據，Prometheus 生態的話可以考慮放到標籤中，如果數據可以枚舉，則可以考慮使用數字代表一些字符串，比如 1 表示 up，0 表示 down。而 Zabbix 直接自持字符串類型的數據，使用起來更加順滑。
　　數據可視化
　　Zabbix 是內置提供了數據可視化方案，可以在 Zabbix 中查看各個 item（即監控指標）的最新數據，可以通過儀表盤查看指標的數據。Zabbix 內置的儀表盤整體功能相對簡單，可以應對日常監控需求。但也僅此而已了。
　　Prometheus 生態更多的是採用 Grafana 作為儀表盤可視化工具。Grafana 有兩個點非常吸引人：
　　Grafana 支持多種數據源。不僅僅是 Prometheus，還有 InfluxDB、Elasticsearch、Loki、MySQL 等，Grafana 是面向數據的，不僅僅是監控場景，而 Zabbix 的可視化僅服務於監控這個場景，這是一個很大的區別。
　　Grafana 生態好。GrafanaLabs 官網提供了一個倉庫，可以找到很多人貢獻的儀表盤，雖然有些儀表盤質量參差不齊，但是總體來説，Grafana 的生態是非常好的。而 Zabbix 的儀表盤更多還是 Zabbix 自己在搞，社區參與度遠沒有 Grafana 高。
　　當然，有些小夥伴説 Grafana 的圖表看起來更炫酷啊，確實是。不過個人觀點來講，這不是關鍵點。數據的價值更多的是帶來洞察，讓你從數據中發現一些有價值的信息，而不是圖表看起來多炫酷。炫酷當然也挺好，是個加分項，尤其是給一些不怎麼懂的老闆看的時候。
　　告警
　　告警這塊分兩部分，一個是告警規則的配置，另一個是事件的分發。
　　告警規則配置
　　Zabbix 中的告警規則稱為 Trigger，Trigger 可以綁定在 Host 上，也可以掛到 Template 上，再把 Template 綁定到 Host 上。另外，配合宏變量的機制，可以很方便實現不同的機器不同的閾值。對於需要細顆粒度的控制，Zabbix 的 Trigger 是非常強大的。
　　Prometheus 相比 Zabbix，更多像是批量處理，也弱化了機器這個概念。如果不同的機器有不同的閾值，只能通過 Label 或者機器名稱的正則來做區分。對機器層面細粒度的閾值控制，不太方便。
　　舉個例子：假設給 DBA 的 100 台機器配置 CPU 使用率超過 90% 的告警，但是 DBA 的 100 台機器中包含 2 台 Redis 的機器，比較特殊，希望 CPU 超過 80% 就告警。在 Zabbix 中，通過宏變量，給這倆機器配置不同的閾值就可以了。而在 Prometheus 中，通常是通過標籤來實現，因為實例名通常都是 IP 地址，不太適合做正則匹配。你可能會配置如下兩個規則：
　　cpu_usage_active{service="redis"} > 80
　　cpu_usage_active{service!="redis"} > 90
　　假設後面 service="mysql" 的機器和 service="mongo" 的機器，其閾值都不同，那麼就需要配置多個規則。
　　當然，終歸是可以解決的。但是，有的時候打標籤不方便，因為標籤會影響時序數據，標籤改變，時序數據就斷了，就會產生新的時序數據，這個時候就會非常難受。後面夜鶯會增加一種告警規則配置方式，不但可以通過標籤來區分機器，也支持通過業務組來區分機器，一個機器可以掛多個業務組，同時支持閾值繼承覆蓋，來解決這類相對麻煩的需求。
　　事件分發
　　Zabbix 中可以管理人員信息，可以配置不同的告警事件發給不同的人，但是對告警聚合降噪、抑制支持的不好。而 Prometheus 的告警事件分發，需要依賴 Alertmanager，Alertmanager 是一個獨立的組件，專門用來處理告警事件的分發，支持很多的告警事件處理方式，比如郵件、短信、Webhook 等，而且支持告警的聚合、抑制等功能。
　　不過 Alertmanager 的配置是通過配置文件管理的，如果要把全公司的所有團隊的分派需求都在一個 Alertmanager 裏管理，就比較費勁了。通常不同的團隊單獨一套 Prometheus + Alertmanager，相對好管理一些，但是很多業務團隊的重心顯然不可能是維護監控系統，所以這塊還是有待改進。
　　實際上，告警事件分發這塊，最佳實踐是使用一個單獨的告警 OnCall 產品來做，因為一個公司通常不止 Zabbix、Prometheus 兩套監控系統，可能還有各類雲監控、還有日誌監控等，即便只有 Prometheus，也容易會有多套 Prometheus，這時候一個統一的告警 OnCall 產品是非常有必要的。這個方面的產品，國外首推 PagerDuty，國內首推 FlashDuty，用於統一實現告警事件的收斂降噪、抑制、屏蔽、多條件分發、認領、升級、協同、自動化處理、和 IM 整合等功能。
　　結語，如何選擇 Zabbix、Prometheus
　　如果你們公司相對傳統，是自建機房，而且只有服務器和網絡設備的監控需求，而且量也不太大，比如設備規模小於 1000 台，建議選用 Zabbix。其他所有場景都建議選擇 Prometheus。
　　比如你們要監控微服務、Kubernetes，要監控各類中間件，體量比較大，都建議選用 Prometheus。另外，從個人的發展角度來看，學習 Prometheus 對於未來的就業也會更有幫助。
　　當然，你也可以一起使用，Zabbix 用來監控網絡設備，Prometheus 用來監控機器、微服務、中間件、Kubernetes，這樣也是一個不錯的選擇。因為網絡設備這塊，通常是非常獨立的功能，通常只有網工去管理相關的告警規則，做網絡設備維護，其他人頂多就是看看數據，用 Zabbix 就挺好。而機器、微服務、中間件、Kubernetes 這塊，使用 Prometheus 更靈活，數據採集更完備。