OSS監視工具徹底比較：你的環境適合哪一種選擇

前言

隨著雲原生化、多雲及微服務架構的普及，系統的複雜性大幅增加。在這樣的環境中，適當的監視工具選擇成為關乎系統穩定運行與商業成功的重要決定。

截至2025年，監視工具選擇中已顯現以下挑戰：

• 環境的多樣化：容器、虛擬機、實體伺服器、網路設備共存
• 可觀察性的需求增加：指標、日誌、追蹤的整合管理
• 運維成本的優化：不僅考慮工具的許可費用，還需考慮運維工時
• 技能組合的差異：DevOps團隊與傳統基礎設施團隊對功能的需求不同

為什麼選擇OSS監視工具

開源監視工具具有以下明確的優勢：

1. 成本效益：不需要許可費 （運維成本需另行考量）
2. 擴展性：可通過插件或 Exporter進行靈活的自定義
3. 透明性：源代碼公開，內部運作可以理解
4. 社群：活躍的社群持續改進
5. 避免供應商鎖定：降低對特定供應商的依賴

不過，OSS並不意味著「免費且簡單」。正確的選擇及適當的運營體系的建立是必要的。

本文目的

本記事將對主要的OSS監視工具從以下觀點進行徹底比較：

• 用途與適用場景：哪些環境最適合
• 架構：數據收集模型、可擴展性
• 限制與注意事項：在導入前應了解的挑戰
• 選擇要點：實用的選擇標準

通過本篇文章，旨在幫助讀者選擇出最適合其自家公司環境的監視工具。

比較對象工具概述

本篇將比較以下OSS監視工具：

主要比較對象

1. Prometheus + Grafana：雲原生環境的事實標準
2. Zabbix：在傳統基礎設施及企業環境中經驗豐富

次要比較對象

1. Nagios：歷史悠久的監視工具
2. Checkmk：基於Nagios的多功能監視工具
3. InfluxDB：時間序列數據庫（作為監視平台基礎）

1. Prometheus + Grafana

概述

Prometheus是由SoundCloud開發，並在2016年被CNCF（Cloud Native Computing Foundation）作為第二個項目采納的時間序列數據庫+監視工具。Grafana是可視化指標的儀表板平台，通常與Prometheus搭配使用。

架構特點

採用拉取模型

Prometheus的最大特徵是拉取模型（Pull-based）進行指標收集：

• Exporter：在每個監視對象上配置Exporter，通過HTTP端點公開指標
• 抓取（Scraping）：Prometheus Server定期從各Exporter獲取指標（預設15秒間隔）
• 服務發現（Service Discovery）：支持Kubernetes、Consul、EC2等動態環境

高維度標籤化

Prometheus採用多維數據模型，可以為指標添加多個標籤：

http_requests_total{method="GET", endpoint="/api/users", status="200"}

這樣可以實現靈活的查詢與聚合。

優勢

1. 最適合Kubernetes / 微服務

• 本地集成：在Kubernetes環境中，可以自動發現Pod和Service
• 動態環境應對：自動應對容器的新增和刪除
• 高基數性：高效處理擁有大量標籤的指標

2. 強大的查詢語言（PromQL）

通過PromQL（Prometheus Query Language），可以進行複雜的聚合與分析：

# 過去5分鐘的HTTP請求成功率
sum(rate(http_requests_total{status=~"2.."}[5m]))
/
sum(rate(http_requests_total[5m]))

3. 豐富的Exporter生態系統

• 官方Exporter：Node Exporter、Blackbox Exporter、HAProxy Exporter等
• 第三方：MySQL、PostgreSQL、Redis、Nginx等中間件均有支持
• 自定義Exporter：輕鬆公開自定義應用程序的指標

4. 與Grafana的整合

• 美觀的儀表板：直觀的可視化效果
• 模板功能：使用變量生成動態儀表板
• 警報整合：與Grafana Alerting、Alertmanager相連接

注意事項與限制

1. 長期數據保留的挑戰

Prometheus的本地存儲預設數據保留為15天：

• 存儲容量：大型環境可能需要數TB以上
• 長期保存：需要Thanos、Cortex、VictoriaMetrics等外部解決方案
• 備份：雖有快照功能，但需設計運營

2. 擴展的複雜性

單一的Prometheus Server有以下限制：

• 指標數量：數百萬指標為上限（依環境而異）
• 抓取對象數量：數千台為現實的上限
• 多集群：需要有統合多個Prometheus Server的機制（如Thanos等）

3. 運維工數

• 安裝與設置：雖有Helm Chart簡化，但仍需理解
• PromQL學習：需要學習成本以便有效利用
• Exporter維護：需對每個監視對象進行Exporter的配置及管理

4. 對推送模型的支持

對於如批次作業等短生命週期的過程監視，需要Pushgateway：

• 額外組件：架構更為複雜
• 指標的持續性：Pushgateway可能成為單點故障的風險

適用場景

Prometheus + Grafana最適合以下環境：
✅ 最適合的環境:

• Kubernetes / 容器環境
• 微服務架構
• 雲原生應用
• DevOps團隊主導的運維
• 頻繁部署且動態擴展的環境

❌ 不適合的環境:

• 以舊式實體伺服器為主的環境
• 需要詳細監視網路設備（以SNMP為主）
• 希望以圖形介面( GUI)為中心的運作
• 必須長期保存資料且無法導入額外解決方案的情況

設定範例（Kubernetes）

# prometheus-values.yaml
prometheus:
  prometheusSpec:
    retention: 15d
    storageSpec:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 50Gi
  resources:
    requests:
      cpu: 500m
      memory: 2Gi
    limits:
      cpu: 2000m
      memory: 8Gi

grafana:
  adminPassword: "your-secure-password"
  persistence:
    enabled: true
    size: 10Gi

alertmanager:
  alertmanagerSpec:
    storage:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 10Gi

# 使用Helm Chart進行安裝
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install prometheus prometheus-community/kube-prometheus-stack \
  -n monitoring \
  --create-namespace \
  -f prometheus-values.yaml

2. Zabbix

概述

Zabbix是由Alexei Vladishev於2001年開發的企業級開源監視工具，擁有超過20年的歷史，並在傳統基礎設施與企業環境中有著豐富實績。

架構特點

同時支持推送與拉取

Zabbix支持推送和拉取兩種模型：

• Zabbix Agent：代理主動將指標推送至伺服器（主動模式）
• Zabbix Server Pull：伺服器從代理處獲取指標（被動模式）
• SNMP / IPMI：監視網路設備和硬體

集中管理架構

• Zabbix Server：集中管理所有監視邏輯、警報及數據處理
• Zabbix Proxy：在大型環境或遠端網站進行分布式監視
• 資料庫：使用MySQL、PostgreSQL、TimescaleDB等關聯數據庫

優勢

1. 對傳統基礎設施的支援能力

Zabbix在監視物理伺服器、虛擬機、網路設備方面擁有強大的能力：

• SNMP監視：路由器、交換機、防火牆等網路設備
• IPMI：伺服器硬體健康狀態（溫度、風扇、電源）
• Windows：原生支持WMI、Perfmon計數器
• Linux：CPU、記憶體、磁碟、進程的詳細監控

2. GUI為中心的操作性

• Web UI：所有設置均可透過GUI完成
• 模板：提供豐富的監視模板（MySQL、Apache、Nginx等）
• 可視化：直觀的螢幕、地圖、圖表生成
• 儀表板：自定義儀表板功能

3. 內建的警報功能

與Prometheus不同，Zabbix有內建的警報功能：

• 觸發器設定：可以透過GUI設置基於閾值的警報
• 通知通道：支持Email、Slack、PagerDuty、SMS等
• 升級：分階段發送警報通知
• 依賴性：考慮主機間的依賴性以抑制警報

4. 長期數據保持

Zabbix使用關聯數據庫，因此長期數據保持為標準功能：

• 數據保持政策：可以為每個項目設定保持期
• 歷史數據：預設保持90天
• 趨勢數據：可長期保存集計數據（以年為單位）
• 分區：可透過TimescaleDB或MySQL分區進行性能優化

5. 無需代理的監視

Zabbix可無需安裝代理進行監視：

• SNMP：網路設備、印表機
• IPMI：伺服器硬體
• SSH / Telnet：透過遠端命令執行進行監視
• Web監視：檢查HTTP場景

注意事項與限制

1. 雲原生対応的限制

Zabbix在容器及Kubernetes環境中的靈活性不如Prometheus：

• 動態環境：Pod和Service的自動發現需要額外設定
• 高基數性：大量標籤/標籤的指標處理效率不高
• 容器監視：雖有Docker、Kubernetes的模板，但不是原生集成

2. 可擴展性的限制

Zabbix的擴展存在以下挑戰：

• 數據庫負載：大量指標可能成為DB瓶頸
• Zabbix Server負載：單伺服器處理能力有限
• Zabbix Proxy：雖可進行分佈，但需設計

3. 查詢語言的靈活性

• 計算指標：基本運算可以，但不如PromQL靈活
• 複雜聚合：需要外部工具（如Grafana）進行高級分析

4. 大型環境下的設置複雜性

• 模板管理：在大型環境下，模板管理會複雜
• 項目數量：每個主機需要管理數百至數千的項目
• 性能調整：需要對快取、進程數進行優化

適用場景

Zabbix最適合以下環境：
✅ 最適合的環境:

• 以物理伺服器、虛擬機為主的基礎設施
• 監視網路設備（路由器、交換機）
• Windows環境的詳細監視
• 企業環境（金融、製造、通信等）
• 希望以GUI為中心的運作
• 長期數據保持為必需的情況

❌ 不適合的環境:

• 以Kubernetes / 容器為主的環境
• 高頻率部署和動態擴展
• DevOps團隊主導且重視IaC的情況
• 微服務架構

設定範例（Docker Compose）

# docker-compose.yml
version: '3.8'

services:
  zabbix-server:
    image: zabbix/zabbix-server-mysql:alpine-6.4-latest
    container_name: zabbix-server
    environment:
      DB_SERVER_HOST: mysql
      MYSQL_DATABASE: zabbix
      MYSQL_USER: zabbix
      MYSQL_PASSWORD: zabbix_password
      MYSQL_ROOT_PASSWORD: root_password
    ports:
      - "10051:10051"
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - zabbix-server-data:/var/lib/zabbix
    depends_on:
      - mysql

  zabbix-web:
    image: zabbix/zabbix-web-nginx-mysql:alpine-6.4-latest
    container_name: zabbix-web
    environment:
      DB_SERVER_HOST: mysql
      MYSQL_DATABASE: zabbix
      MYSQL_USER: zabbix
      MYSQL_PASSWORD: zabbix_password
      ZBX_SERVER_HOST: zabbix-server
      PHP_TZ: Asia/Tokyo
    ports:
      - "80:8080"
    depends_on:
      - zabbix-server

  mysql:
    image: mysql:8.0
    container_name: zabbix-mysql
    environment:
      MYSQL_DATABASE: zabbix
      MYSQL_USER: zabbix
      MYSQL_PASSWORD: zabbix_password
      MYSQL_ROOT_PASSWORD: root_password
    volumes:
      - mysql-data:/var/lib/mysql
    command:
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_bin
      - --default-authentication-plugin=mysql_native_password

volumes:
  zabbix-server-data:
  mysql-data:

# 安裝Zabbix Agent（被監控伺服器）
# Ubuntu / Debian
wget https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.4-1+ubuntu22.04_all.deb
sudo dpkg -i zabbix-release_6.4-1+ubuntu22.04_all.deb
sudo apt update
sudo apt install -y zabbix-agent

# 設定
sudo vi /etc/zabbix/zabbix_agentd.conf
# Server=<Zabbix Server IP>
# ServerActive=<Zabbix Server IP>
# Hostname=<主機名稱>

sudo systemctl restart zabbix-agent
sudo systemctl enable zabbix-agent

3. 其他OSS監視工具（概要）

Nagios

概要：於1999年發布的歷史悠久的監視工具。廣泛用於許多企業環境。
優勢：

• 插件生態系統成熟（Nagios Plugins）
• 簡單且易於理解的架構
• 社群龐大
  注意事項：
• UI老舊，基於配置檔
• 擴展性有限
• 不適合雲原生環境
  適用場景：小至中型的傳統基礎設施，持續使用現有Nagios環境

Checkmk

概要：基於Nagios的RAW版（免費）和企業版（收費）。
優勢：

• 大幅擴展Nagios功能
• 自動發現功能（主機、服務）
• 出色的Web UI
• 豐富的插件
  注意事項：
• RAW版有功能限制
• 基於Nagios的架構限制仍然存在
  適用場景：從Nagios遷移，或中型企業環境

InfluxDB

概要：時間序列數據庫（TSDB）。主要作為監視平台的基礎使用，而非監視工具。
優勢：

• 高速的寫入和讀取性能
• SQL類似的查詢語言（InfluxQL、Flux）
• 降采樣功能
• 通過Telegraf進行數據收集
  注意事項：
• 不是監視工具，而是數據庫
• 警報功能需要另行使用Kapacitor
• 集群功能僅在企業版（收費）中提供
  適用場景：自定義監視平台構建、物聯網數據管理、Prometheus的長期存儲

徹底比較：選擇標準別

比較表：全貌

比較軸1: 數據收集模型

拉取模型（Prometheus、Nagios、Checkmk）

優勢：

• 監控伺服器可控制收集（即使對象故障也能檢測到）
• 網路流量由監控伺服器進行控制

劣勢：

• 短生命作業（批處理）的監視較為困難
• 跨越防火牆的監視較複雜

推送模型（Zabbix、InfluxDB + Telegraf）

優勢：

• 短生命作業的監視更加便捷
• 跨越防火牆的監視更為簡單

劣勢：

• 需要更改代理端的設置
• 大量代理的推送可能會增加伺服器負擔

比較軸2: 可擴展性

Prometheus的擴展策略

Thanos:

• 整合多個Prometheus Server
• 將長期數據存儲至S3等對象存儲
• 全球查詢視圖

# 使用Thanos Sidecar的配置範例
prometheus:
  prometheusSpec:
    thanos:
      objectStorageConfig:
        key: thanos.yaml
        name: thanos-objstore-config

Cortex / Mimir:

• 支持多租戶
• 水平擴展
• 整合長期存儲

Zabbix的擴展策略

Zabbix Proxy:

• 進行遠程站點或大量主機的分散監視
• Proxy至Server定期數據轉移

資料庫優化:

• 透過TimescaleDB（PostgreSQL擴展）提高性能
• 透過分區處理大量數據

比較軸3: 可視化・儀表板

比較軸4: 容器 / Kubernetes 兼容性

Prometheus + Grafana

• kube-prometheus-stack：通過Helm Chart簡易安裝
• 服務發現：自Kubernetes API自動發現
• kube-state-metrics：公開Kubernetes資源的指標
• Node Exporter：節點層級的指標

Zabbix

• Zabbix Agent 2：Docker插件、Kubernetes插件
• 模板：有Docker、Kubernetes的模板
• 限制：動態Pod檢測不如Prometheus靈活

比較軸5: 網路設備 / 傳統基礎設施適應性

結論：在監視傳統基礎設施（如物理伺服器、網路設備、Windows）時，Zabbix或Checkmk絕對優勢。

選擇要點與實務建議

步驟1: 整理自有基礎設施架構

以下檢查清單可助你分析自家環境：

環境類型

運營體系

數據需求

步驟2: 評估團隊技能與運維工數

所需技術組合

運維工數分配

Prometheus + Grafana:

• 配置與更新Exporter
• 調整PromQL查詢
• 維護Grafana儀表板
• 更新Alertmanager規則
• 管理擴展（如Thanos等）

Zabbix:

• 管理模板
• 新增主機與項目
• 調整觸發器
• 優化資料庫性能
• 升級版本

步驟3: 針對未來擴展該設計

若計畫遷移到雲端

目前使用內部伺服器，但未來會計畫遷移至雲端：
✅ 推薦：Prometheus + Grafana

• 雲原生環境遷移順暢
• 與AWS、Azure、GCP的管理服務整合良好
• 當容器化加速時也能符合需求

⚠️ 注意：Zabbix

• 若將來繼續使用Zabbix，需管理虛擬機的相關問題
• 隨著容器化的進展，需考慮轉往Prometheus

多雲策略

使用多個雲供應商的情況下：
✅ Prometheus + Thanos：統一監視多個叢集
✅ Zabbix：不受雲端影響，持續監視

步驟4: 成本分析（TCO：總擁有成本）

OSS監視工具通常是「無需許可費」，但必須考量運營成本的TCO。

成本比較（每年，1000個主機規模的範例）

思考：

• Zabbix的運維工時較少，TCO最低
• Prometheus + Grafana的運維工時較高，但雲原生迫切所需
• 商業SaaS雖然運維工時少，但許可費用高昂

步驟5: 原型

原文出處：https://qiita.com/keitah/items/70e6b63e4c504b4796fa