Zabbix(ザビックス)は、サーバー・ネットワーク機器・アプリケーション・クラウドの状態を1つの画面で監視できる、無料のオープンソース監視ツールです。データの収集、異常の判定、通知、グラフやダッシュボードでの可視化までを1つのソフトウェアで行います。この記事では、仕組みと監視できる項目、有償サポートの費用、PrometheusやJP1との違い、2026年10月時点の版とサポート期限、Ubuntuでの導入手順までを順に説明します。
まとめ:Zabbixの要点
- 読み方は「ザビックス」。ラトビアのZabbix LLCが開発するOSSで、7.0からライセンスはAGPLv3です。
- エージェントとSNMP等の両方で集める統合監視。サーバーとネットワーク機器が混在する環境を1製品で見られるのが強みです。
- ライセンス費用は無料。かかるのは監視サーバーなどの設備費と運用の工数で、開発元のサポートを付けるならSilverが年払いで月€245($325)からです。監視台数による課金はありません。
- 本番は7.0 LTS(最新は7.0.32)。フルサポートは2027年6月30日まで。8.0 LTSは2026年10月21日にrc2が出た段階で、正式版は2026年第4四半期の予定です。
- 2026年10月のPHP脆弱性はPHP側の更新で対処。OSベンダーが出すPHPの修正版を適用します(上流は8.3.36など)。Zabbix本体も7.0.29より前なら7.0.32へ上げます。
Zabbixの定義・読み方・ライセンス
Zabbixは、監視対象から値を定期的に集めて保存し、条件を超えたら担当者へ通知するソフトウェアです。収集・判定・通知・可視化を1製品で担うので「統合監視ツール」と呼ばれます。
読み方と開発元
読み方は「ザビックス」です。Alexei Vladishev氏が開発し、2001年に公開しました。開発元のZabbix LLCは2005年設立で、ラトビアのリガに本社を置きます(Zabbix社のプレスリリースの会社概要による)。
無料で使える範囲とライセンス
ソフトウェア本体は無料で、監視するホスト数・メトリクス数・ユーザー数による課金もありません。公式のライセンスページによると、7.0以降はGNU AGPLv3、6.4までの版はGPLv2で配布されています。改変せずに配布パッケージのまま使うなら、AGPLv3への変更で運用が変わることはありません。ソースを改変したZabbixをネットワーク越しに利用者へ使わせる場合は、AGPLv3第13条の条件(改変したソースを利用者が入手できるようにすること)を確認してください。
有償サポートの費用
ライセンス以外にかかるのは、監視サーバーとデータベースの設備費、構築と運用の工数、必要に応じて契約する技術サポートや導入支援の費用です。開発元の技術サポートは公式のサブスクリプションページで次のように公開されており、どのプランも監視台数・メトリクス数の上限はありません。
| プラン | 料金(年払いの月額) | 対応時間 | 初回応答(最大) | 緊急時の応答 |
|---|---|---|---|---|
| Silver | €245($325) | 8×5 | 1日 | なし |
| Gold | €660($825)から | 8×5 | 4時間 | なし |
| Platinum | 個別見積 | 24×7 | 4時間 | 2時間 |
| Enterprise | 個別見積 | 24×7 | 4時間 | 1.5時間 |
| Global | 個別見積 | 24×7 | 2時間 | 1時間 |
夜間・休日の障害に開発元の応答が必要ならPlatinum以上が条件です。Silverは問い合わせが年8件までです。上の価格は英語版ページのもので、日本では2012年10月に東京で設立された日本法人Zabbix Japan LLCが、ベーシック・シルバー・ゴールド・プラチナの4区分で提供しています(日本向けサブスクリプションページ)。
Zabbixの仕組み(構成要素とデータの流れ)
データは「エージェントや機器 → (プロキシ) → サーバー → データベース」と流れ、Webフロントエンドが結果を表示します。
Zabbixを構成する5つのコンポーネント
| コンポーネント | 役割 |
|---|---|
| Zabbixサーバー | 収集・条件判定・通知の中枢 |
| データベース | 設定と収集データを保存 |
| Webフロントエンド | 設定と閲覧の画面(PHP製) |
| Zabbixエージェント | 監視対象のOS内部の値を集める |
| Zabbixプロキシ | 拠点ごとに代理収集(任意) |
データベースはMySQL・MariaDB・PostgreSQLなどから選びます。小規模ならサーバー・データベース・フロントエンドを1台にまとめて動かせます。拠点が分かれている、または台数が増えてサーバーの負荷が高いときにプロキシを追加します。
エージェント監視とエージェントレス監視
- エージェント監視:監視対象にエージェントを入れて、CPU・メモリ・ディスク・プロセス・ログなどOS内部の値を取ります。サーバーが問い合わせるパッシブと、エージェントから送るアクティブの2方式があります。
- エージェントレス監視:ソフトを入れずに外から状態を取ります。ネットワーク機器はSNMP、ハードウェアはIPMI、JavaアプリはJMX、死活はICMP pingを使います。
Zabbix agentとagent 2の違い
エージェントには、C言語製の従来のZabbix agentと、Go言語で書き直したZabbix agent 2があります。公式ドキュメントによると、agent 2はTCP接続の数を減らし、チェックを並行して実行し、機能をプラグインで追加できる設計です。従来のagentの置き換えとして設計されていますが、C言語で書いたロード可能モジュール(LoadModule)は使えません。Ubuntu向けの公式リポジトリにはMongoDB・PostgreSQL・MSSQLのプラグインが別パッケージで用意されています。
選び方は対応OSで決まります。7.0の要件表では、agent 2の対応はLinuxとWindowsだけです。AIX・Solaris・FreeBSD・macOSなどは従来のagentを使います。LinuxとWindowsの新規導入ではagent 2を選び、既存のagentは無理に置き換えなくて構いません。
ホスト・アイテム・トリガー・アクションの関係
| 用語 | 意味 |
|---|---|
| ホスト | 監視対象(サーバー・機器) |
| アイテム | 取得する値(CPU使用率など) |
| トリガー | 異常と判定する条件式 |
| テンプレート | アイテムとトリガーの雛形 |
| アクション | トリガー発火時の処理(通知など) |
トリガーは関数(/ホスト/アイテムキー,期間)演算子 しきい値の形で書きます(公式ドキュメントのトリガー式)。たとえば、ホストweb01のCPUのアイドル率が5分間の平均で10%を下回ったら(使用率がおよそ90%を超えたら)発火させる式は次のとおりです。
avg(/web01/system.cpu.util[,idle],5m)<10
system.cpu.utilを引数なしでエージェントから取ると、既定ではユーザー空間の使用率(user)だけが返ります。CPU全体を見たいときは、この例のようにアイドル率から判定するか、公式テンプレートの「CPU utilization」アイテムを使います。last()で最新値だけを見ると一瞬の上昇でも通知が飛ぶので、CPUやメモリには期間を取る関数を使います。
Zabbixでできること(監視項目・可視化・通知)
監視対象ごとの監視項目と取得方法
| 対象 | 主な監視項目 | 取得方法 |
|---|---|---|
| Linux・Windowsサーバー | CPU・メモリ・ディスク・プロセス・ログ | エージェント |
| ネットワーク機器 | ポートの通信量・エラー・死活 | SNMP |
| Web・DB・ミドルウェア | 応答時間・接続数・クエリ数 | エージェント・HTTP |
| 仮想化・クラウド | VMware・AWS・Azureの各値 | テンプレート |
| Webサイト | 応答コード・応答時間 | Webシナリオ |
多くの製品には公式テンプレートが用意されており、ホストに割り当てるとアイテムとトリガーがまとめて入ります。最初はテンプレートのまま動かし、しきい値を自社の運用に合わせて調整するのが早道です。外部から見た応答の監視の考え方は外形監視とは?内部監視との違いと監視項目・実装、導入判断を実装目線で解説、メトリクスの種類としきい値の決め方はメトリクス監視とは|4種のメトリック型・収集方式・アラート閾値の設計と導入判断を実装目線で解説で扱っています。
ネットワーク機器の監視(SNMP)
スイッチやルーターは、機器側でSNMPを有効にし、Zabbixにホストを登録してSNMPインターフェースとテンプレートを割り当てます。ポートごとの通信量やエラー数は、ローレベルディスカバリ(LLD)が自動でアイテムを作るので、48ポートの機器でも1つずつ登録する必要はありません。機器を追加したときに自動で登録する「ネットワークディスカバリ」もあり、台数の多い拠点ネットワークの監視に向きます。
ダッシュボードと可視化
Zabbixはグラフ・ネットワークマップ・障害一覧などのウィジェットを並べたダッシュボードを標準で作れるので、Grafanaを別に立てなくても監視を始められます。
アラート通知の流れ
通知は、トリガー(条件判定)、アクション(誰に何をするか)、メディアタイプ(メール・SMS・Webhookなどの送り方)の3つで決まります。SlackやTeamsへの通知はWebhookのメディアタイプで送ります。深刻度や時間帯で送り先を分けられるので、夜間は重大な障害だけ当番に送る、といった運用ができます。
他の監視ツールとの違い(Prometheus・Grafana・Nagios・JP1・Datadog)
選び方の出発点は、監視対象の性質です。コンテナが頻繁に増減する環境ならPrometheus、サーバーとネットワーク機器が混在する安定した環境ならZabbix、監視基盤を自社で運用したくないならSaaS型のDatadogです。
| ツール | 種別 | 得意な対象 | 費用 |
|---|---|---|---|
| Zabbix | 統合監視(OSS) | サーバー+ネットワーク機器 | 無料(サポート有償) |
| Prometheus | メトリクス監視(OSS) | コンテナ・Kubernetes | 無料 |
| Grafana | 可視化 | 複数データソースの表示 | 無料〜 |
| Nagios | 死活・状態監視 | シンプルな監視 | Core無料・XI有償 |
| JP1 | 統合運用管理(商用) | 大規模・ジョブ管理込み | 有償 |
| Datadog | SaaS監視 | クラウド・APM | ホスト等の従量課金 |
ZabbixとPrometheusの違い
Prometheusは、監視対象が公開するメトリクスをサーバーが定期的に取りに行くプル型で、Kubernetesのサービスディスカバリと組み合わせて動的な環境を追いかけます。通知はAlertmanager、画面はGrafanaと、役割ごとに別のコンポーネントを組み合わせます。Zabbixはプッシュ(アクティブ)とプル(パッシブ)の両方に対応し、SNMPでネットワーク機器も見られ、通知と画面も本体に入っています。Prometheus側の構築手順はPrometheusで監視を構築する手順|exporter設計・PromQL・保持期間の見積りにまとめています。
ZabbixとGrafanaの違い
Grafanaはデータを集めない可視化ツールで、Zabbixと競合する製品ではありません。Zabbixと他のデータソースを1画面にまとめたいときに、ZabbixをデータソースにしてGrafanaで表示します。マネージド版はAmazon Managed Grafanaとは?料金・対応バージョン・作成手順とGrafana Cloudとの違い、ログまで同じ画面で見る場合はGrafana Lokiとは?仕組み・Alloyでの導入手順とLogQLの書き方【v3.7】で扱っています。
ZabbixとNagios・JP1の違い
無料のNagios Coreはプラグインを足して監視項目を増やす設計で、データの蓄積やグラフはZabbixのほうが標準で揃っています(有償のNagios XIはグラフやダッシュボードを備えます)。JP1は日立製作所の商用製品で、監視に加えてジョブ管理やバックアップ管理まで同じ製品群で揃えられ、国内ベンダーのサポートが付きます。ライセンス費用をかけてでも1社に保守を任せたい大規模システムはJP1、費用を抑えて自社か構築会社で運用するならZabbix、という分かれ方です。
ZabbixとDatadogの違い
DatadogはSaaSなので、監視サーバーやデータベースの構築・バージョンアップ・容量管理が要りません。代わりにホスト数やデータ量に応じて利用料が増えます。自社で動かすZabbixは監視対象を増やしてもライセンス費用は増えませんが、監視サーバーの増強と運用は自社の負担です。Zabbix社が基盤を運用するZabbix Cloudもあり、運用を任せたいがZabbixを使いたい場合の選択肢になります。Datadogの料金体系と機能はDatadogとは?何ができるか・仕組み・料金とCloudWatch/Zabbixとの違いで比べています。
Zabbixのメリット・デメリットと向いていないケース
Zabbixを選ぶ利点(費用・統合性・機器対応)
- 台数が増えてもライセンス費用は増えない:監視対象の追加で課金されません。増えるのは監視サーバーの性能と保存容量です。
- 1製品で完結する:収集・通知・画面が本体に入っており、組み合わせの設計が要りません。
- ネットワーク機器まで見られる:SNMPとLLDで、サーバーと機器を同じ画面で扱えます。
Zabbixの欠点と運用の注意点
- データベースが重くなる:アイテムが増えると履歴データが膨らみます。保存期間を決め、大規模ならPostgreSQLにTimescaleDBを組み合わせるなどの設計が必要です。
- 最初の設計に時間がかかる:ホスト・アイテム・トリガー・テンプレートの関係を理解し、通知ルールを決めるまでに手間がかかります。
- 監視基盤そのものの運用が残る:Zabbixサーバー・データベース・PHPのバージョンアップと脆弱性対応は自社の仕事です。
サーバーの規模の目安は、公式の要件ページに次のように載っています(1メトリクス=アイテム1つ+トリガー1つ+グラフ1つとして数えた目安)。
| 規模 | 監視メトリクス | CPU | メモリ |
|---|---|---|---|
| Small | 1,000 | 2コア | 8GiB |
| Medium | 10,000 | 4コア | 16GiB |
| Large | 100,000 | 16コア | 64GiB |
| Very large | 1,000,000 | 32コア | 96GiB |
Zabbixが向くケース・向かないケース
向いているのは、物理サーバー・仮想マシン・ネットワーク機器が混在するオンプレミス中心の環境を、費用を抑えて1つの画面で監視したい場合です。向いていないのは、Kubernetes上でコンテナが分単位で入れ替わる環境(Prometheusのほうが素直に扱えます)と、監視基盤の保守を担当する人がいない組織です。後者で「無料だから」とZabbixを入れると、バージョンアップが止まり、サポートの切れた版のまま運用が続く失敗になりがちです。監視とオブザーバビリティの違いはオブザーバビリティ(可観測性)とは?監視・APM・テレメトリとの違いと使い分けで補足しています。
Zabbixのバージョンとサポート期限(7.0 LTS・7.4・8.0)
Zabbixには、5年間サポートされるLTS版と、約1年でサポートが終わる通常版があります。公式のライフサイクルページの日付は次のとおりです(2026年10月28日時点)。
| 版 | リリース | フルサポート終了 | 限定サポート終了 |
|---|---|---|---|
| 8.0 LTS | 2026年第4四半期(予定) | 2029年第4四半期 | 2031年第4四半期 |
| 7.4 | 2025年7月1日 | 8.0 LTSの公開まで | 2027年第1四半期 |
| 7.0 LTS | 2024年6月4日 | 2027年6月30日 | 2029年6月30日 |
| 6.0 LTS | 2022年2月8日 | 2025年2月28日 | 2027年2月28日 |
本番環境は7.0 LTSを選びます。リリースノートで確認できる最新の修正版は7.0.32、通常版は7.4.16です。6.0 LTSはすでにフルサポートが終わっており、限定サポートの終わる2027年2月28日までに7.0か8.0へ移す計画が必要です。
8.0 LTSの状況と主な変更
8.0は2026年10月21日に8.0.0rc2(正式版の直前の候補版)が公開された段階です。開発版ドキュメントの新機能一覧には、OpenTelemetryを使うAPM(アプリケーション性能監視)、履歴の保存先としてのClickHouse、AIエージェントからZabbixへ接続するMCPサーバーが載っています。
移行で注意するのは要件の引き上げです。8.0の要件表ではPHPが8.2.0以上、MySQLが8.4.0以上、PostgreSQLが15.0以上になり、7.0の下限(PHP 8.0.0・MySQL 8.0.30・PostgreSQL 13.0)から上がります。Ubuntu 24.04の標準パッケージのMySQLは8.0系なので、8.0へ上げる前にデータベースの更新が必要です。7.0のフルサポートは2027年6月30日まであるので、8.0の正式版が出たら、まず検証環境で自社のテンプレートと連携先の動作を確かめてから移行時期を決めます。
脆弱性への対応(2026年10月のPHP脆弱性とZabbix本体)
2026年10月のPHP脆弱性
2026年10月21日、PHPの開発チームは、認証なしでリモートからコードを実行されるおそれがある2件の重大な脆弱性(CVE-2026-109618・CVE-2026-109619)を修正した8.5.12・8.4.27・8.3.36・8.2.35を公開しました(PHP公式サイト)。翌22日のZabbix社の声明は、PHPはZabbixのパッケージに含まれない別のソフトウェアなので、PHPやOSのベンダーの修正を、インターネットに公開している環境から優先して適用するよう案内しています。
- やること:Zabbixのフロントエンドが動くサーバーのPHPを、OSのパッケージ更新(Ubuntuなら
apt upgrade)でベンダーの修正版に上げる。Zabbix本体の更新では直りません。 - PHP 8.0・8.1の場合:Zabbix 7.0はPHP 8.0.0〜8.5.Xに対応しますが、PHPのサポート一覧では8.0・8.1はすでにサポート対象外です。OSベンダーが修正を出していなければ、8.2以降へ上げる必要があります。
- 公開範囲の見直し:Zabbixの画面をインターネットに直接公開していると影響が大きくなります。社内ネットワークかVPN経由に限るのが基本です。
Zabbix本体の脆弱性と修正版
Zabbix本体の脆弱性は公式のセキュリティアドバイザリで公表され、LTSの修正版で直ります。たとえば、サーバーとプロキシがアクティブagentのハートビートでTLSの認証条件を確かめていなかったCVE-2026-59786(ZBX-28196)は7.0.29と7.4.13で、7.4のセッション署名鍵が初期データに固定値で入っていたCVE-2026-23933(ZBX-28071)は7.4.11で修正されました。7.0系を使っているなら、7.0.29より前の版は7.0.32まで上げます。
Zabbix 7.0 LTSの導入手順(Ubuntu 24.04・MySQL)
Ubuntu 24.04に、Zabbixサーバー・フロントエンド(Apache)・agent 2を1台で入れる最小構成です。2026年10月28日にDockerのubuntu:24.04イメージで下のパッケージ導入とスキーマ投入を実行し、7.0.32が入ること、203個のテーブルとAdminユーザーが作られること、/zabbixで初期設定画面が返ることを確認しました(systemctlでの起動はコンテナでは試せないため実機で行ってください)。
公式リポジトリの登録とパッケージ導入
sudo apt install mysql-server
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu24.04_all.deb
sudo dpkg -i zabbix-release_latest_7.0+ubuntu24.04_all.deb
sudo apt update
sudo apt install zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts zabbix-agent2
データベースの作成と初期データの投入
MySQLにデータベースとユーザーを作ります。初期データの投入中だけlog_bin_trust_function_creatorsを1にし、終わったら0に戻します(公式のデータベース作成手順)。
sudo mysql
mysql> create database zabbix character set utf8mb4 collate utf8mb4_bin;
mysql> create user 'zabbix'@'localhost' identified by '任意のパスワード';
mysql> grant all privileges on zabbix.* to 'zabbix'@'localhost';
mysql> SET GLOBAL log_bin_trust_function_creators = 1;
mysql> quit;
zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix
sudo mysql -e "SET GLOBAL log_bin_trust_function_creators = 0;"
設定ファイルの編集と起動
/etc/zabbix/zabbix_server.confのDBPassword=に、上で決めたパスワードを書いてから起動します。
sudo systemctl restart zabbix-server zabbix-agent2 apache2
sudo systemctl enable zabbix-server zabbix-agent2 apache2
ブラウザでhttp://サーバーのIP/zabbixを開くと初期設定の画面が出ます。データベースの接続情報を入れて完了させ、ユーザー名Admin・パスワードzabbixでログインしたら、最初にAdminのパスワードを変えます。
別のサーバーを監視するときは、そのサーバーにagent 2を入れ、/etc/zabbix/zabbix_agent2.confでZabbixサーバーのアドレスを指定します。
Server=192.0.2.10
ServerActive=192.0.2.10
Hostname=web01
Serverはパッシブ監視で問い合わせを受け付ける相手、ServerActiveはアクティブ監視の送り先、Hostnameは画面で登録するホスト名と一致させます。パッシブ監視ではZabbixサーバーから監視対象のTCP 10050番へ、アクティブ監視では監視対象からZabbixサーバーのTCP 10051番へ通信できるようにファイアウォールを開けます。画面ではホストを作成し、インターフェースに「エージェント」とIPアドレス・ポート10050を入れ、「Linux by Zabbix agent」などのテンプレートを割り当てると監視が始まります。
台数が多い環境での監視設計や、Zabbixを含む監視基盤の保守を外部に任せたい場合は、システムの保守運用・内製化支援で相談を受け付けています。
よくある質問
Zabbixは何ができますか?
サーバーのCPU・メモリ・ディスク、ネットワーク機器の通信量と死活、Webやデータベースの応答、VMwareやクラウドの値を集め、条件を超えたらメールやチャットで通知し、グラフやダッシュボードで表示します。
Zabbixは無料で使えますか?
ソフトウェアのライセンス費用は無料で、監視台数による課金もありません。別にかかるのは監視サーバーの設備費と運用の工数で、開発元の技術サポートは英語版の価格表でSilverが年払いの月€245($325)からです。
ZabbixとJP1の違いは何ですか?
ZabbixはOSSで本体が無料、運用は自社か構築会社が担います。JP1は日立製作所の商用製品で、監視に加えてジョブ管理なども揃い、ベンダーのサポートが付きます。費用を抑えたいならZabbix、保守を1社に任せたい大規模システムならJP1が候補です。
Zabbixの欠点は何ですか?
監視項目が増えるとデータベースが重くなること、最初の設計と学習に時間がかかること、監視基盤のバージョンアップや脆弱性対応を自社で行う必要があることです。
Zabbixの最新バージョンはどれですか?
2026年10月28日時点で、本番向けのLTSは7.0(最新の修正版は7.0.32)、通常版は7.4.16です。8.0 LTSは2026年10月21日にrc2が公開された段階で、正式版は2026年第4四半期の予定です。