Zabbix初心者が「自動監視・データ分析」までを一気に駆け抜けるための実践ロードマップ
CentOS Stream 9へのZabbix 7.0 インストール手順
ここではまず、Linux OS(CentOS Stream 9)上に最新のZabbix 7.0 (LTS) をインストールする手順を記載します。
従来のOSではApacheやPHPを個別に手動インストールしていましたが、現在の主流である公式リポジトリを利用する方法では、Zabbixパッケージの導入時に必要な依存ソフト(httpd, php等)が自動的に構成されるため、より確実で簡潔な手順となります。
スポンサーリンク
作業の大きな流れは、①OSの事前準備 ⇒ ②DB(MariaDB)の構築 ⇒ ③Zabbixリポジトリの導入 ⇒ ④ZabbixサーバとWebフロントエンドの設定 の順で進めます。
1. 事前作業:ホスト名の設定
システムの識別を容易にするため、ホスト名を設定します。
[root@localhost ~]# hostnamectl set-hostname sv01.srv.tv
[root@localhost ~]# hostname
sv01.srv.tv
コードは注意してご使用ください。
2. データベース(MariaDB)の導入
Zabbixのデータを格納するデータベースを先に準備します。
# MariaDBのインストールと起動
[root@sv01 ~]# dnf install -y mariadb-server
[root@sv01 ~]# systemctl enable --now mariadb
# 初期設定(パスワード設定など)
[root@sv01 ~]# mysql_secure_installation
3. Zabbixリポジトリの登録とインストール
公式サイトが提供する最新のリポジトリを登録し、Zabbixサーバ、Webフロントエンド、エージェントをまとめてインストールします。この際、必要なバージョンのApacheやPHPも依存関係として自動的に導入されます。
# Zabbix公式リポジトリの登録
[root@sv01 ~]# rpm -Uvh https://zabbix.com
[root@sv01 ~]# dnf clean all
# サーバ、フロントエンド、エージェントのインストール
[root@sv01 ~]# dnf install -y zabbix-server-mysql zabbix-web-mysql zabbix-apache-conf zabbix-sql-scripts zabbix-selinux-policy zabbix-agent2
4. データベースの初期化と設定
Zabbix用のDBユーザーを作成し、初期スキーマ(テーブル構造)をインポートします。
# DB作成と権限付与(MySQL上で実行)
mysql> create database zabbix character set utf8mb4 collate utf8mb4_bin;
mysql> create user zabbix@localhost identified by 'password';
mysql> grant all privileges on zabbix.* to zabbix@localhost;
mysql> quit;
# 初期データのインポート
[root@sv01 ~]# zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix
5. 各種サービスの起動とWeb画面へのログイン
Zabbixサーバの設定ファイル(/etc/zabbix/zabbix_server.conf)にDBパスワードを追記した後、各サービスを再起動します。
[root@sv01 ~]# systemctl restart zabbix-server zabbix-agent2 httpd php-fpm
[root@sv01 ~]# systemctl enable zabbix-server zabbix-agent2 httpd php-fpm
以降は、ブラウザから http://(サーバのIPアドレス)/zabbix にアクセスし、画面の指示に従ってセットアップを完了させます。
ブラウザにアクセスした後のセットアップ(Web GUIウィザード)は、主にZabbixサーバとデータベースを紐付ける最終確認の作業です。
以下のステップで進めてください。
Zabbix Webセットアップ手順
1. 言語の選択 (Welcome)
ブラウザで http://(サーバのIPアドレス)/zabbix を開くと、まず歓迎画面が表示されます。
- Language: 「Japanese (ja_JP)」を選択すると、以降の画面が日本語になります(※OS側に日本語ロケールが入っていない場合は選択できません)。
- 「Next step」をクリックします。
2. 前提条件のチェック (Check of pre-requisites)
Zabbixの動作に必要なPHPの設定(メモリ制限やタイムゾーンなど)が満たされているか自動チェックされます。
- ポイント: 以前の手順と異なり、公式パッケージ(
zabbix-apache-conf)を使っている場合は、最初からすべて「OK」になっているはずです。 - すべて「OK」であることを確認して「Next step」へ。
3. データベース接続の設定 (Configure DB connection)
先ほどMariaDBで作成した情報を入力します。
- Database type: MySQL (MariaDBの場合もこれを選択)
- Database host: localhost
- Database name: zabbix
- User: zabbix
- Password: (手順4で設定したパスワード)
- 「Next step」をクリック。ここでエラーが出る場合は、パスワード間違いや、DB側で権限付与(grant)が正しく行われていない可能性があります。
4. 設定の確認 (Settings)
- Zabbix server name: 任意(監視画面のタイトルに表示される名前です)。
- Default time zone: 「(UTC+09:00) Asia/Tokyo」を選択します。
- 「Next step」へ。
5. インストール要約 (Pre-installation summary)
これまでの入力内容が表示されます。問題なければ「Next step」をクリックすると、設定ファイル(/etc/zabbix/web/zabbix.conf.php)が自動生成されます。
6. 完了 (Install)
「Congratulations! You have successfully installed Zabbix frontend.」と表示されれば成功です。「Finish」をクリックしてください。
初回ログイン
セットアップ完了後、ログイン画面が表示されます。初期の特権管理者アカウントは以下の通りです。
- ユーザー名:
Admin(※Aは大文字) - パスワード:
zabbix

【重要】
ログイン後、セキュリティのために必ず [管理] (Administration) > [ユーザー] (Users) から Admin のパスワードを変更してください。
監視対象のサーバー(ホスト)をZabbixに登録し、実際にデータの収集を開始する手順を解説します。
Zabbixでは、監視される側のサーバーを「ホスト」と呼びます。今回は、最も一般的で詳細な情報が取れる「Zabbixエージェント」を使った登録の流れを説明します。
1. 監視対象サーバー(ターゲット)の下準備
まず、監視したいサーバー側に「Zabbixエージェント」をインストールし、Zabbixサーバからの通信を許可する設定を行います。
- エージェントのインストール(監視対象サーバーで実行)
Zabbixサーバと同じバージョンのリポジトリを登録してインストールします。bash[root@target ~]# rpm -Uvh https://zabbix.com [root@target ~]# dnf install -y zabbix-agent2コードは注意してご使用ください。 - 設定ファイルの編集 (
/etc/zabbix/zabbix_agent2.conf)
以下の箇所を書き換えます。Server=192.168.x.x(ZabbixサーバのIPアドレスを指定)ServerActive=192.168.x.x(同上)Hostname=sv02.srv.tv(このサーバー自身の名前。後ほどWeb画面で入力するものと一致させる)
- 起動と有効化bash
[root@target ~]# systemctl enable --now zabbix-agent2コードは注意してご使用ください。
2. Zabbix Web管理画面での登録手順
ブラウザからログインし、以下の手順でホストを作成します。
① ホスト作成画面を開く
- 左メニューの [データ収集] (Data collection) > [ホスト] (Hosts) をクリック。
- 右上の [ホストの作成] (Create host) ボタンをクリックします。
② 基本情報を入力
- ホスト名: 手順1で設定した
Hostname(例:sv02.srv.tv)を入力します。 - テンプレート: 監視項目のセットです。最初は 「Linux by Zabbix agent」 を選択してください。これでCPU、メモリ、ディスク等の主要な監視が自動設定されます。
- ホストグループ: 整理用のグループです。「Linux servers」などを選択(または新規作成)します。
- インターフェース: [追加] > [エージェント] をクリックし、監視対象サーバーの IPアドレス を入力します。
③ 保存
一番下の [追加] (Add) ボタンをクリックして完了です。
3. 監視が成功しているか確認する
- ステータスの確認
[ホスト] の一覧画面で、登録したホストの 「可用性」 欄にある 「ZBX」 というアイコンが 緑色 に点灯すれば成功です(反映まで1〜2分かかることがあります)。 - データの確認
左メニューの [監視] (Monitoring) > [最新データ] (Latest data) を開き、ホストを選択して適用すると、CPU使用率やメモリ残量などの数値がリアルタイムで届いているのが確認できます。
Zabbixで異常を検知した際に、管理者へメールで通知を飛ばす設定を解説します。
設定は大きく分けて「①送り方の設定(メディアタイプ)」「②誰に送るかの設定(ユーザー)」「③いつ送るかのルール(アクション)」の3ステップです。
ステップ1:送り方の設定(メディアタイプ)
まず、Zabbixがどのメールサーバを使って送信するかを設定します。
- 左メニュー [通知] (Alerts) > [メディアタイプ] (Media types) をクリック。
- 一覧から 「Email」 を探してクリックします。
- [メディアタイプ] タブで、利用するメールサーバの情報を入力します。
- SMTPサーバー:
localhost(サーバ内でPostfix等が動いている場合) や、Gmail等の外部SMTPサーバ。 - SMTPサーバーポート:
25や587など。 - 送信時のメールアドレス:
zabbix@example.comなど(送信元として表示されるアドレス)。
- SMTPサーバー:
- [更新] をクリックして保存します。
ステップ2:宛先の設定(ユーザー)
次に、通知を受け取るユーザーにメールアドレスを紐付けます。
- 左メニュー [管理] (Users) > [ユーザー] (Users) をクリック。
- 通知を送りたいユーザー(例:
Admin)をクリックします。 - [メディア] タブに切り替え、[追加] をクリックします。
- タイプ: 「Email」を選択。
- 送信先: 実際のメールアドレスを入力。
- 時間帯:
1-7,0000-2400(24時間365日送る設定)のままでOKです。 - 指定した深刻度のときに通知: 「障害」や「致命的な障害」にチェックを入れます。
- [追加] > [更新] をクリック。
ステップ3:通知ルールの設定(アクション)
最後に、「どんな時に通知を出すか」というルールを作成します。
- 左メニュー [通知] (Alerts) > [アクション] (Actions) > [トリガーアクション] をクリック。
- 右上の [アクションの作成] (Create action) をクリック。
- [アクション] タブ:
- 名前:
Auto mail notificationなど。
- 名前:
- [実行内容] (Operations) タブ:
- 実行内容 の枠内にある [追加] をクリック。
- ユーザーに送信: [追加] を押し、ステップ2のユーザーを選択。
- 次のメディアのみ使用: 「Email」を選択。
- 下の [追加] をクリックして確定。
- 最後に一番下の [追加] ボタンをクリックして保存します。
4. テスト方法
正しく設定できたか確認するには、監視対象のサーバーで意図的に「障害」を発生させます。
- 例: 監視対象サーバーの Zabbixエージェントを停止 させてみる。bash
[root@target ~]# systemctl stop zabbix-agent2コードは注意してご使用ください。 - 数分後、Zabbixのダッシュボードに「障害」が表示され、設定したメールアドレスに通知が届けば成功です。
- 確認後はエージェントを再起動(
start)し、復旧通知が来ることも確認しましょう。
Zabbixで「CPU使用率が80%を超えたらアラートを出す」といった判定ルールのことを「トリガー」と呼びます。
テンプレート(Linux by Zabbix agentなど)を適用している場合、標準的なしきい値がすでに設定されていますが、サーバーの用途に合わせて個別に変更する方法は2通りあります。
状況に合わせて使い分けてください。
方法1:特定のサーバー(ホスト)だけ個別に変更する
「このサーバーだけは負荷が高いのが普通なので、しきい値を緩めたい」という場合に最適です。
- 左メニュー [データ収集] (Data collection) > [ホスト] (Hosts) をクリック。
- 対象サーバーの行にある [トリガー] (Triggers) をクリックします。
- 一覧から変更したい項目(例:
High CPU utilizationなど)を探してクリックします。 - [条件式] (Expression) 欄を確認します。
- 例:
last(/Linux by Zabbix agent/system.cpu.util) > 90 - この末尾の数字(90)を
80などに書き換えます。
- 例:
- 一番下の [更新] (Update) をクリックして保存します。
方法2:「マクロ」を使ってスマートに変更する(推奨)
最近のZabbixテンプレートでは、数字を直接書き換えるのではなく、「マクロ(変数)」という仕組みでしきい値を管理するのが主流です。これを使うと、条件式をいじらずに数字だけを安全に変更できます。
- [ホスト] 一覧から、対象サーバーの 名前 をクリックして設定画面を開きます。
- 上部のタブから [マクロ] (Macros) を選択します。
- [継承したマクロとホストマクロ] (Inherited and host macros) をクリックします。
- 一覧の中から、CPUに関連するマクロを探します。
- 例:
{$CPU.UTIL.CRIT}(値が 90 になっているはずです)
- 例:
- その項目の右側にある [変更] (Change) をクリックし、値を
80に書き換えます。 - 一番下の [更新] (Update) をクリックします。
【メリット】
この方法で変更すると、テンプレート全体のルールは壊さず、そのサーバー専用のしきい値として上書き保存されるため、管理が非常に楽になります。
補足:複数のサーバーを一気に変えたい場合
もし「全サーバーのしきい値を一括で80%にしたい」という場合は、ホストごとではなく [テンプレート] (Templates) 画面から同様の手順でマクロの値を変更してください。
これで、自分の環境に合わせた「ちょうど良い通知タイミング」に調整できるようになります。
特定のサービス(ApacheやMariaDB/MySQLなど)が動作しているかを監視するには、主に「プロセスの生存確認」または「ポートの応答確認」という2つのアプローチがあります。
Zabbixの標準テンプレートには、これらを簡単に設定できる仕組みが備わっています。
方法1:標準テンプレートを活用する(推奨)
Zabbixには、主要なサービス専用のテンプレートがあらかじめ用意されています。これを使えば、自分で複雑な設定をする必要はありません。
- [データ収集] (Data collection) > [ホスト] (Hosts) をクリック。
- 対象のサーバー(ホスト)の名前をクリックして設定画面を開きます。
- [テンプレート] (Templates) 欄の「追加」で、監視したいサービス名を入力して選択します。
- Apacheの場合:
Apache by Zabbix agent - MySQL/MariaDBの場合:
MySQL by Zabbix agent
- Apacheの場合:
- [更新] をクリックします。
※サービスによっては、監視用ユーザーの作成などの追加設定(マクロの設定)が必要な場合がありますが、基本的にはこれで「プロセスが止まったらアラート」が出るようになります。
方法2:特定のプロセスをピンポイントで監視する
専用テンプレートを使わず、「特定の名前のプロセスが1つ以上動いているか」を監視する手順です。
① アイテム(データの収集)の作成
- [ホスト] 一覧から、対象サーバーの [アイテム] (Items) > [アイテムの作成] をクリック。
- 以下の通り入力します。
- 名前:
Apache process check(任意) - キー:
proc.num[httpd](※httpdプロセスの数を数える設定) - データ型: 数値 (整数)
- 監視間隔:
1m(1分おき)
- 名前:
- [追加] をクリック。これで「プロセス数」が収集され始めます。
② トリガー(障害判定)の作成
- 同じホストの [トリガー] (Triggers) > [トリガーの作成] をクリック。
- 以下の通り入力します。
- 名前:
Apache is down on {HOST.NAME} - 深刻度: 致命的な障害 (High)
- 条件式:
last(/ホスト名/proc.num[httpd])=0- ※「最新のプロセス数が0なら障害」という意味です。
- 名前:
- [追加] をクリック。
方法3:ネットワーク越しにポートを監視する(外部監視)
エージェントを使わず、Zabbixサーバから「80番ポート(HTTP)や3306番ポート(MySQL)に接続できるか」を確認する方法です。
- [ホスト] > [アイテムの作成] で以下のキーを使います。
- HTTPの場合:
net.tcp.service[http] - MySQLの場合:
net.tcp.service[tcp,,3306]
- HTTPの場合:
- このキーは、サービスが動いていれば 「1」、止まっていれば 「0」 を返します。
- トリガーの条件式を
last(...) = 0とすれば、サービス停止を検知できます。
まとめ:どちらを使うべき?
- 詳細に状況を知りたい場合: 方法1(標準テンプレート)。リクエスト数やメモリ使用量なども一緒に見られます。
- とにかく「動いているか」だけ知りたい場合: 方法2(プロセス監視) または 方法3(ポート監視)。設定がシンプルで負荷も低いです。
これで、特定のサービスがダウンした際に即座にメール通知を受け取れるようになります。
システム運用の現場で非常に重要となる、「ログ監視(異常の予兆検知)」と「ネットワーク機器監視(SNMP)」の2点について解説します。
1. ログ監視:特定のキーワード(Errorなど)を検知する
外部監視(ポート監視)では「サービスが動いているか」は分かりますが、「内部でエラーが多発しているか」までは分かりません。ログ監視を組み合わせることで、致命的なダウンが起こる前に異常に気づけます。
設定の流れ:
- アイテムの作成: 監視対象ホストに以下のアイテムを追加します。
- タイプ:
Zabbixエージェント (アクティブ)※ログ監視は必ずアクティブ型を使います。 - キー:
log[/var/log/httpd/error_log,Error]- 第1引数:ログのフルパス
- 第2引数:検知したい文字列(正規表現も可)
- データ型: ログ
- タイプ:
- トリガーの作成:
- 条件式:
count(/ホスト名/log[...],1m) > 0 - 意味:「直近1分間に “Error” という文字が1回でも記録されたら障害とする」
- 条件式:
注意点: Zabbixユーザーにログファイルへの読取権限が必要です(chmod や setfacl で設定します)。
2. ネットワーク機器の監視(SNMP監視)
ルーターやスイッチなど、Zabbixエージェントをインストールできない機器は SNMP(Simple Network Management Protocol) を使って監視します。
設定の流れ:
- 機器側の準備:
- ルーター等の設定画面で「SNMP有効」にし、コミュニティ名(合言葉のようなもの。例:
public)を設定します。
- ルーター等の設定画面で「SNMP有効」にし、コミュニティ名(合言葉のようなもの。例:
- Zabbix側の登録:
- ホスト作成: [インターフェース] で「SNMP」を選択し、機器のIPアドレスを入力。
- テンプレート:
Network Generic Device by SNMPや、メーカー専用(Cisco, Yamahaなど)のテンプレートを選択。 - マクロ:
{$SNMP_COMMUNITY}というマクロに、先ほど決めたコミュニティ名(publicなど)を入力します。
これにより、各ポートの通信量(トラフィック)や死活状態を自動でグラフ化できます。
3. 「外部監視」をさらに確実にするために
これらを組み合わせることで、多角的な監視体制が構築できます。
- ポート監視: 外から見て扉(ポート)が開いているか?
- ログ監視: 中で「助けて(Error)」という声が上がっていないか?
- SNMP監視: 通り道(ネットワーク機器)が渋滞したり切れたりしていないか?
この3つを押さえれば、インフラ監視の基礎は完璧です。
Zabbixの「ダッシュボード」は、バラバラな監視データを1か所に集約し、システムの健康状態をひと目で把握するための「司令塔」のような画面です。
自分好みの専用モニターを作るイメージで進めてみましょう。
1. ダッシュボードの新規作成
- 左メニューの [監視] (Monitoring) > [ダッシュボード] (Dashboard) をクリック。
- 右上の [ダッシュボードの作成] (Create dashboard) ボタンを押します。
- 名前(例:
システム全体監視)を入力して「保存」します。これで真っ白なキャンバスが用意されます。
2. 「ウィジェット」の追加
ダッシュボードは、「ウィジェット」と呼ばれる部品を並べて作ります。画面上の適当な場所をクリック(または右上の「ウィジェットの追加」)して、以下の代表的なパーツを置いてみましょう。
① 障害状況(現在起きている問題)
- タイプ: [障害] (Problems) を選択。
- 内容: 現在発生しているアラートがリスト表示されます。
- 用途: 「今、何が起きているか」を最優先で確認するため、画面の上部に置くのが定石です。
② グラフ(データの推移)
- タイプ: [グラフ] (Graph) または [SVGグラフ] を選択。
- データセット: 監視対象の「ホスト」と、見たいデータ(CPU利用率など)の「アイテム」を選びます。
- 用途: 負荷の推移やネットワークのトラフィックを視覚的に捉えるために使います。
③ ホストの可用性(死活状態)
- タイプ: [ホストの可用性] (Host availability) を選択。
- 内容: 監視しているサーバーやネットワーク機器が、現在オンライン(緑)かオフライン(赤)かをアイコンで表示します。
④ アイテムの値(現在の数値)
- タイプ: [アイテムの値] (Item value) を選択。
- 内容: 「現在の気温」や「現在のメモリ使用量(%)」など、特定の数値をデカデカと表示します。
3. レイアウトの調整
- 追加したウィジェットは、ドラッグ&ドロップで場所を移動したり、端を引っ張ってサイズを変更したりできます。
- 配置が決まったら、必ず右上の [変更を保存] (Save changes) をクリックしてください。これを忘れると配置が消えてしまいます。
長期にわたってZabbixを運用する際、最も注意すべきなのがデータベースの肥大化です。何も考えずにデータを溜め続けると、数ヶ月でディスクがいっぱいになり、システムが停止してしまいます。
これを防ぐための「ヒストリ」と「トレンド」の使い分けと設定方法を解説します。
1. 「ヒストリ」と「トレンド」の違いを知る
Zabbixには、データの保存形式が2種類あります。
- ヒストリ (History):
- 収集した生データそのものです(例:1分おきのCPU使用率 1.5%, 1.8%, 2.2%…)。
- 詳細な分析ができますが、データ量が非常に多く、ディスクを激しく消費します。
- 目安: 7日〜30日程度に設定するのが一般的です。
- トレンド (Trend):
- 1時間ごとの統計データ(最大値・最小値・平均値)です。
- データ量が劇的に少なく(1項目につき1時間に1レコードのみ)、ディスクをほとんど使いません。
- 目安: 365日〜数年間に設定し、長期的な傾向分析に使います。
2. 保存期間の設定方法
設定は「アイテム」ごと、または「テンプレート」単位で行います。
- 左メニュー [データ収集] (Data collection) > [テンプレート] (またはホスト) をクリック。
- 対象の [アイテム] (Items) 一覧を開きます。
- 変更したいアイテム(例:
CPU utilization)をクリックします。 - 以下の項目を書き換えます。
- ヒストリの保存期間 (History storage period):
7d(7日間) など - トレンドの保存期間 (Trend storage period):
365d(365日間) など
- ヒストリの保存期間 (History storage period):
- [更新] をクリックして保存します。
💡 効率的な設定のコツ:
複数のアイテムを一括で変更したい場合は、アイテム一覧で左側のチェックボックスを入れ、下部の [一括更新] (Mass update) ボタンを使うと便利です。
3. ハウスキーパー(自動掃除)の確認
設定した保存期間を過ぎた古いデータを、Zabbixが自動で削除してくれる機能を「ハウスキーパー」と呼びます。
- 左メニュー [管理] (Administration) > [一般] (General) > [ハウスキーピング] (Housekeeping) を選択。
- 「ヒストリ」と「トレンド」の [Enable internal housekeeping] (内部ハウスキーピングを有効にする) にチェックが入っていることを確認します。
- ここで「データの保存期間を上書き」にチェックを入れると、各アイテムの設定を無視して、Zabbix全体で一律の保存期間を強制することも可能です。
4. 運用上のアドバイス:DBの「パーティショニング」
非常に大規模な環境(監視項目が数千〜数万)になると、ハウスキーパーによる削除処理自体がデータベースに大きな負荷をかけるようになります。
その場合は、OS/DBレベルで「テーブルパーティショニング」という高度な設定を行い、日ごとにデータを切り分けて管理・削除する手法が推奨されます。
Zabbixには、ダッシュボードの内容を定期的にPDF化してメール送信する「定時レポート(Scheduled reports)」という便利な機能があります。
これを利用するには、Zabbixサーバとは別に「Zabbix Web Service」というコンポーネントの導入が必要です。少し手順が多いですが、順を追って解説します。
1. Zabbix Web Service の導入(サーバ側作業)
PDFを作成するために、Google Chrome(ブラウザ)を制御して画面をキャプチャする仕組みをインストールします。
再起動bash[root@sv01 ~]# systemctl restart zabbix-server コードは注意してご使用ください。
パッケージのインストール(CentOS Stream 9の場合)bash[root@sv01 ~]# dnf install -y zabbix-web-service google-chrome-stable コードは注意してご使用ください。
サービスの起動と有効化bash[root@sv01 ~]# systemctl enable --now zabbix-web-service コードは注意してご使用ください。
Zabbixサーバ設定の変更 (/etc/zabbix/zabbix_server.conf)
以下の行のコメントアウトを外し、設定します。
WebServiceURL=http://localhost:10053/report
StartReportWriters=3(レポート作成用プロセスの数)

2. Zabbix Web画面での連携設定
Zabbixの管理画面に、PDF作成機能を使うためのURLを教えます。
- 左メニュー [管理] (Administration) > [一般] (General) > [その他] (Other) を選択。
- Frontend URL に、ブラウザからアクセスする際のURLを入力します。
- 例:
http://192.168.x.x/zabbix
- 例:
- [更新] をクリック。
3. レポート作成の予約
いよいよ、どのダッシュボードをいつ送るかを設定します。
- 左メニュー [レポート] (Reports) > [定時レポート] (Scheduled reports) をクリック。
- 右上の [レポートの作成] (Create report) をクリック。
- 設定内容を入力:
- 名前:
週次稼働レポートなど - ダッシュボード: 送信したいダッシュボードを選択
- 期間: 「前日」「前週」「前月」など(グラフの範囲が決まります)
- 繰り返し: 「毎日」「毎週」など
- 開始時間: 送信したい時刻
- 受信者: 送信先のユーザー(またはユーザーグループ)を選択
- 名前:
- [追加] をクリックして保存します。
4. テスト送信
作成したレポートの一覧画面で、対象のレポートにチェックを入れ、下部の [テスト送信] (Test) ボタンを押すと、即座にPDFが作成されメールで届きます。
- PDFが届かない場合:
zabbix-web-serviceが動いているか、また手順2のFrontend URLが正しいか(サーバ自身がそのURLにアクセスできるか)を確認してください。
これで、毎週月曜日の朝に「先週のサーバ負荷状況」が自動でPDFとして届くような運用が可能になります。上司への報告用や、自身の振り返り用に非常に重宝する機能です。
Zabbix API(JSON-RPC)を使いこなせると、GUIでチマチマ操作するのが馬鹿らしくなるほど運用が楽になります。特におすすめの「実戦で使える便利なTips」を3つ厳選して紹介します。
1. 大量ホストの一括登録・更新(自動化)
100台のサーバをGUIで1台ずつ登録するのは苦行です。APIを使えば、CSVファイルやExcelのリストから一瞬で登録できます。
- Tips: AnsibleやTerraformなどの構成管理ツールと組み合わせるのが定番です。
- できること:
- 新しくサーバを立てたら、自動でZabbixにホスト登録し、テンプレートを適用する。
- 全ホストの「マクロ(しきい値)」を一括で書き換える。
2. 特定条件の「障害一覧」を外部ディスプレイに表示
Zabbixのダッシュボードも良いですが、APIを使えば「特定のグループの、重度の障害だけ」を抽出して、独自のWEBサイトや社内ポータルに埋め込めます。
- Tips:
problem.getメソッドを使用します。 - 活用例:
- Slack/Teamsへの独自整形通知: 標準機能よりリッチな情報(過去の傾向グラフ付きなど)を添えて通知する。
- サイネージ化: オフィスの壁掛けモニタに、現在発生中の重要障害だけを巨大な赤文字で表示させる。
3. 監視設定の「バックアップ」と「世代管理」
「誰がいつ設定を変えたかわからない」「設定を戻したい」という時に、APIで設定をエクスポートしておくと助かります。
- Tips:
configuration.exportメソッドを使用します。 - 運用例:
- 毎日深夜に、全ホスト・全テンプレートの設定をJSON形式で引っこ抜き、GitHubやGitLabにコミットする。
- これにより、「誰がいつ、しきい値を何から何に変えたか」がGitの履歴(diff)として完璧に残ります。
おまけ:簡単に試す方法(Python編)
Pythonなら pyzabbix というライブラリを使うと、驚くほど短いコードで操作できます。
python
from pyzabbix import ZabbixAPI
zapi = ZabbixAPI("http://192.168.x.x/zabbix")
zapi.login("Admin", "zabbix")
# 全てのホスト名を取得して表示
for host in zapi.host.get(output="extend"):
print(host['name'])
※コードは注意してご使用ください。
「AnsibleやTerraformとZabbixを組み合わせる」というのは、インフラの構築と同時に「監視の設定も自動で完了させる」という、現代的な運用(Monitoring as Code)の核心部分です。
手動でホスト登録する手間を省くだけでなく、「監視の漏れ」を物理的にゼロにするのが最大のメリットです。それぞれ得意分野が異なるので、使い分けを解説します。
1. Terraform × Zabbix:インフラ作成と同時に「器」を作る
Terraformは、クラウド(AWS/Azure等)や仮想マシンの「作成」が得意です。
- 仕組み:
zabbixプロバイダーを使用します。 - 具体例:
- Terraformで新しいWEBサーバー(EC2など)を1台起動する。
- 同時に、Zabbix APIを叩いて「ホスト登録」「テンプレート適用」「ホストグループ追加」を自動で行う。
- メリット: サーバーが完成した瞬間、すでにZabbixの管理画面にそのサーバーが現れ、監視が始まっている状態になります。「監視登録を忘れていて、障害に気づかなかった」というミスが防げます。
2. Ansible × Zabbix:中身の設定と「エージェント」の導入
Ansibleは、OSの中身の設定(設定ファイルの書き換えなど)が得意です。
- 仕組み: Ansible公式の
community.zabbixコレクションを使用します。 - 具体例:
- 新しいサーバーに
zabbix-agent2をインストールする。 - 設定ファイル(
zabbix_agent2.conf)内のServerやHostnameを、各サーバーごとに適切な値に書き換える。 - エージェントを起動し、ファイアウォールを開ける。
- 新しいサーバーに
- メリット: 何百台あっても、すべてのエージェント設定を「一寸の狂いもなく」一瞬で整えられます。
3. 【実戦】最強の組み合わせフロー
多くの現場では、以下のように役割を分担させて自動化します。
- Terraform がサーバーを立て、Zabbix側に「監視するよ」と宣言する(ホスト登録)。
- Ansible がサーバーの中に入り、エージェントを入れて「Zabbixサーバと通信してね」と設定する。
- Zabbix がデータを受け取り、監視がスタートする。
4. 便利なTips:自動登録(Auto Registration)
APIを直接叩かなくても、Zabbixには「アクティブエージェントの自動登録」という機能があります。
- 設定: Zabbix側で「特定の名前(例:
web-*)から通信が来たら、自動でWEB用テンプレートを適用してホスト登録する」というアクションを作っておきます。 - 運用: Ansibleでエージェントを入れ、設定ファイルに
HostMetadata=web-serverと書くだけで、あとは放置で勝手に監視対象に加わります。
「構成管理ツール × Zabbix」を導入すると、サーバーが増える=監視が自動で増える というサイクルが出来上がります。
AnsibleでZabbixの設定を自動化するためのPlaybook(プレイブック)の書き方を、初心者の方でもイメージしやすいように解説します。
Ansibleは「やりたいこと(状態)」をリスト形式で書くだけで、その通りにサーバーをセットアップしてくれる道具です。
1. 準備:Zabbix用「部品」の導入
Ansibleには、Zabbixを操作するための便利な専用パーツ(コレクション)が用意されています。これを使うのが一番簡単です。
監視対象サーバー(または操作端末)で以下を実行して、パーツを取り寄せます。
bash
ansible-galaxy collection install community.zabbix
※コードは注意してご使用ください。
2. 具体的なPlaybookの例
今回は、「新しいサーバーにZabbixエージェントを入れ、設定を済ませて起動する」という基本の流れを自動化する書き方です。
install_zabbix_agent.yml という名前でファイルを作成します。
yaml
---
- name: Zabbixエージェントをインストールして設定する
hosts: all # ターゲットとなる全サーバーが対象
become: yes # 管理者権限(sudo)で実行
tasks:
# ステップ1:Zabbixのリポジトリ(インストール元)を登録
- name: Zabbixリポジトリのインストール
dnf:
name: https://zabbix.com
state: present
disable_gpg_check: yes
# ステップ2:エージェント本体をインストール
- name: Zabbixエージェント2のインストール
dnf:
name: zabbix-agent2
state: present
# ステップ3:設定ファイルを書き換える(ここが肝心!)
- name: ZabbixサーバのIPアドレスを設定
lineinfile:
path: /etc/zabbix/zabbix_agent2.conf
regexp: '^Server='
line: 'Server=192.168.1.10' # あなたのZabbixサーバのIPに書き換え
- name: アクティブチェック用のIPアドレスを設定
lineinfile:
path: /etc/zabbix/zabbix_agent2.conf
regexp: '^ServerActive='
line: 'ServerActive=192.168.1.10'
# ステップ4:サービスを起動し、自動起動も有効にする
- name: Zabbixエージェントを起動
systemd:
name: zabbix-agent2
state: started
enabled: yes
# ステップ5:ファイアウォール(10050番ポート)を開ける
- name: 10050番ポートを許可
firewalld:
port: 10050/tcp
permanent: yes
state: enabled
immediate: yes
※コードは注意してご使用ください。
3. このPlaybookのすごいところ
- 「べき等性(べきとうせい)」: このPlaybookを2回実行しても、すでに設定が終わっていれば何もしません。壊れる心配がないのがAnsibleの強みです。
- 一斉適用: サーバーが10台あっても100台あっても、一回のコマンドで全台同じ状態になります。
4. 実行方法
以下のコマンドを打つだけで、リストに書いた作業が全自動で進みます。
bash
ansible-playbook -i サーバーリストのファイル install_zabbix_agent.yml
※コードは注意してご使用ください。
「Zabbixサーバ側の画面にホストを自動登録する」には、大きく分けて「Zabbixの標準機能(自動登録)」を使う方法と、「Ansibleのモジュール(API)」を使う方法の2通りがあります。
初心者の方には、設定がシンプルで拡張性が高い「1. アクティブエージェントの自動登録」が最もおすすめです。
方法1:Zabbixの標準機能「自動登録」を使う
監視対象のサーバーにエージェントを入れた瞬間、サーバー側が「自分を監視して!」と名乗り出て、Zabbixが自動でリストに追加する仕組みです。
① Zabbix Web画面での設定(アクションの作成)
- [通知] (Alerts) > [アクション] (Actions) > [自動登録アクション] を選択。
- 右上の [アクションの作成] をクリック。
- 名前:
Linuxサーバ自動登録など。 - 実行条件: 「ホストメタデータに
Linuxが含まれる」などの条件を追加。
- 名前:
- [実行内容] タブで以下を追加:
- ホストを追加
- ホストグループに追加:
Linux servers - テンプレートとリンク:
Linux by Zabbix agent active
- [追加] をクリック。
② Ansibleでの設定(エージェント側の仕込み)
先ほどのPlaybookに、以下の1行(メタデータ)を追加するだけです。
yaml
- name: ホストメタデータ(合言葉)を設定
lineinfile:
path: /etc/zabbix/zabbix_agent2.conf
regexp: '^HostMetadata='
line: 'HostMetadata=Linux' # ここがZabbix側の条件と一致すれば自動登録される
※コードは注意してご使用ください。
方法2:Ansibleの「Zabbixホストモジュール」を使う
Ansibleから直接ZabbixのAPIを叩いて、「このホストを登録しろ」と命令する方法です。
Playbookの書き方(追加分)
yaml
- name: Zabbixサーバにホストを直接登録する
community.zabbix.zabbix_host:
server_url: http://192.168.1
login_user: Admin
login_password: zabbix_password
host_name: "{{ ansible_hostname }}"
visible_name: "{{ ansible_hostname }}"
status: enabled
interfaces:
- type: 1
main: 1
useip: 1
ip: "{{ ansible_default_ipv4.address }}"
dns: ""
port: "10050"
link_templates:
- "Linux by Zabbix agent"
host_groups:
- "Linux servers"
state: present
delegate_to: localhost # このタスクだけは自分のPC(操作端末)から実行する
※コードは注意してご使用ください。
どちらの方法が良いですか?
- 方法1(自動登録)がおすすめなケース:
- オートスケーリングなどで、サーバーが頻繁に増減する場合。
- AnsibleからZabbixサーバへのAPI通信経路を意識したくない場合。
- 方法2(Ansibleモジュール)がおすすめなケース:
- 登録時に「ホスト名」だけでなく「インベントリ情報(設置場所や担当者など)」も細かく流し込みたい場合。
- 監視対象を完全にAnsibleの管理下(コード管理)に置きたい場合。
Zabbix APIを外部(Ansibleや自作プログラム)から利用する際、以前は「ユーザー名とパスワード」を毎回送る方式が主流でしたが、現在は「APIトークン」を使用するのがセキュリティ上のベストプラクティスです。
APIトークンを使うメリットと、具体的な設定・管理のコツを解説します。
1. APIトークンとは?(なぜ安全なのか)
APIトークンは、パスワードの代わりに使用する長いランダムな文字列です。
- パスワードを隠せる: Ansibleの設定ファイルなどに、生(なま)のパスワードを記述しなくて済みます。
- 有効期限を設定できる: 「1ヶ月だけ有効なトークン」を発行し、漏洩リスクを下げられます。
- 権限を絞れる: 特定のユーザー専用のトークンを作ることで、「参照しかできないトークン」や「特定のグループだけ操作できるトークン」といった運用が可能です。
- 即座に無効化できる: 万が一トークンが漏れても、そのトークンだけを削除すれば、ユーザー本体のアカウント(ログインパスワード)への影響はありません。
2. APIトークンの発行手順(Zabbix 6.0以降)
- 左メニュー [管理] (Users) > [APIトークン] (API tokens) を選択。
- 右上の [APIトークンの作成] (Create API token) をクリック。
- 設定を入力:
- 名前:
Ansible-Auto-Registrationなど(用途がわかる名前)。 - ユーザー: トークンを使用するユーザー(例:
Adminまたは専用のAPI用ユーザー)。 - 有効期限: 必要に応じて設定(無期限も可能ですが、定期更新が推奨です)。
- 名前:
- [追加] をクリックすると、一度だけトークン文字列が表示されます。
- 重要: この文字列は二度と表示されません。必ずコピーして安全な場所(パスワードマネージャーなど)に保管してください。
3. Ansibleでの安全な使いこなし術
トークンをPlaybookに直接書くと、Gitなどにアップした際に丸見えになってしまいます。これを防ぐのが Ansible Vault(アンシブル・ボルト) です。
① トークンを暗号化して保存
bash
# 暗号化した変数ファイルを新規作成
ansible-vault create group_vars/all/vault.yml
※コードは注意してご使用ください。
中身にトークンを記述します:
yaml
vault_zabbix_api_token: "ここに発行したトークンを貼り付け"
コードは注意してご使用ください。
② Playbookでの利用例
yaml
- name: Zabbixサーバにホストを登録する
community.zabbix.zabbix_host:
server_url: http://192.168.1
# パスワードの代わりにトークンを使用!
api_token: "{{ vault_zabbix_api_token }}"
host_name: "{{ ansible_hostname }}"
# ...(以下略)
※コードは注意してご使用ください。
実行時に --ask-vault-pass を付ければ、安全に暗号を解いて実行してくれます。
4. 運用の Tips
- 専用ユーザーを作る:
Adminユーザーのトークンを使い回すのではなく、api_userのような「API専用のユーザー」をZabbix上に作り、必要最低限の権限(User Role)だけを与えるのが最も安全です。 - IP制限: 可能であれば、Zabbixサーバ側のファイアウォールで、APIを叩く端末(操作端末やAnsibleサーバ)からのアクセスのみを許可するように絞りましょう。
サーバーのメンテナンス(OSアップデートや再起動など)を行う際、監視を止め忘れると「大量の障害アラート」が飛んでしまい、本当の異常を見逃す原因になります。
APIを使って、「作業開始時にメンテナンスモードをONにし、終了時にOFFにする」という自動化は、現場で最も重宝されるTipsの一つです。
1. メンテナンスモード自動化の仕組み
Zabbix APIの maintenance.create メソッドを使用します。
Ansibleを使えば、専用のモジュールがあるため、複雑なJSONを書かずに実行できます。
2. AnsibleでのPlaybook例
作業の「前」に実行してメンテナンスを開始し、「後」に実行して終了させるイメージです。
① メンテナンスを開始するタスク
yaml
- name: メンテナンスモードを開始する
community.zabbix.zabbix_maintenance:
server_url: http://192.168.1
api_token: "{{ vault_zabbix_api_token }}"
name: "Scheduled Maintenance for {{ ansible_hostname }}"
state: present
# メンテナンスするホストを指定
host_names:
- "{{ ansible_hostname }}"
# メンテナンス期間(秒)。念のため1時間(3600秒)などに設定
active_since: "{{ ansible_date_time.epoch }}"
active_till: "{{ (ansible_date_time.epoch | int) + 3600 }}"
# 期間中の動作(データ収集は続けるが通知はしない設定)
maintenance_type: 0
※コードは注意してご使用ください。
② メンテナンスを終了するタスク
作業が終わったら、メンテナンス設定を削除して通常監視に戻します。
yaml
- name: メンテナンスモードを終了(削除)する
community.zabbix.zabbix_maintenance:
server_url: http://192.168.1
api_token: "{{ vault_zabbix_api_token }}"
name: "Scheduled Maintenance for {{ ansible_hostname }}"
state: absent
※コードは注意してご使用ください。
3. 実戦での活用 Tips:CI/CDとの連携
このAPI操作を、普段の「デプロイ作業」や「パッチ適用作業」のフローに組み込むのが理想的です。
- 自動化の黄金パターン:
- APIでメンテナンス開始: アラートを抑制。
- 本番作業: サービス停止、アップデート、再起動など(ここで一時的に通信が切れてもアラートは飛ばない)。
- 動作確認: 正常動作を確認。
- APIでメンテナンス終了: 監視を通常状態に戻す。
4. 注意点:メンテナンスの「名前」
Zabbixのメンテナンス設定は 「名前(Name)」 で管理されます。
複数のサーバーで同時に作業する場合、名前が重複しないように ansible_hostname などの変数を使って、「誰のメンテナンスか」を一意にするのがコツです。
過去の障害履歴をCSVで出力する機能は、月次の報告書作成や、頻発している障害の傾向分析に非常に役立ちます。Zabbixの標準画面(GUI)ではCSV出力が限定的な場合が多いため、APIとPythonを組み合わせるのが最も自由度が高く、効率的です。
ここでは、初心者の方でもコピー&ペーストで試せるPythonスクリプトの例を中心に解説します。
1. 障害履歴取得の流れ
Zabbix APIの event.get メソッドを使用します。
「障害(Problem)」そのものではなく、その元となった「イベント(Event)」の履歴をさかのぼることで、過去にいつ発生し、いつ復旧したかのリストを取得できます。
2. PythonによるCSV出力スクリプト例
このスクリプトは、過去30日間の「深刻度が警告(Warning)以上」の障害を抽出し、zabbix_events.csv というファイルに保存します。
python
import csv
import time
from pyzabbix import ZabbixAPI
# --- 設定 ---
ZABBIX_URL = 'http://192.168.x.x/zabbix'
API_TOKEN = 'あなたのAPIトークンをここに貼り付け'
# Zabbixに接続
zapi = ZabbixAPI(ZABBIX_URL)
zapi.session.auth = API_TOKEN
# 過去30日間のタイムスタンプを計算
time_from = int(time.time()) - (30 * 24 * 60 * 60)
# 過去のイベント(障害発生)を取得
events = zapi.event.get(
time_from=time_from,
source=0, # トリガー由来のイベント
object=0, # トリガー
value=1, # 障害発生(1=障害, 0=復旧)
selectHosts=['host', 'name'],
output=['eventid', 'clock', 'name', 'severity'],
sortfield='clock',
sortorder='DESC'
)
# CSVファイルに書き出し
with open('zabbix_events.csv', mode='w', newline='', encoding='utf-8-sig') as f:
writer = csv.writer(f)
# ヘッダー
writer.writerow(['発生日時', 'ホスト名', '障害内容', '深刻度'])
for e in events:
# 日時を読みやすい形式に変換
dt = time.strftime('%Y-%m-%d %H:%M:%S', time.localtime(int(e['clock'])))
host_name = e['hosts'][0]['name'] if e['hosts'] else '不明'
writer.writerow([dt, host_name, e['name'], e['severity']])
print(f"完了! {len(events)} 件の障害履歴を出力しました。")
※コードは注意してご使用ください。
3. 実戦で役立つTips
① 復旧時刻もセットで出したい場合
上記のスクリプトは「発生」のみを追っていますが、event.get で取得した eventid をもとに problem.get を組み合わせると、「いつ直ったか(継続時間)」も計算してCSVに含めることができます。
② 深刻度(Severity)の読み替え
APIから返ってくる severity は数字(0〜5)です。
- 2:警告 (Warning)
- 3:軽度の障害 (Average)
- 4:重度の障害 (High)
- 5:致命的な障害 (Disaster)
CSVに書き出す際に、これらを文字に置換してあげると、Excelで見たときに非常にわかりやすくなります。
③ 自動実行(Cron)との組み合わせ
このスクリプトを Linux の cron に登録しておけば、毎月1日の朝に「先月分の障害レポートCSV」を自動で生成し、共有フォルダに保存しておくといった運用が可能です。
「CSV出力したデータを自動集計する」には、Pythonのデータ分析ライブラリであるpandasを使うのが最も強力で簡単です。
Excelのピボットテーブルと同じ操作(グループ化、集計、カウント)を数行のコードで行い、その結果を直接Excelファイル(.xlsx)として保存できます。
1. 準備:必要なライブラリのインストール
集計用の pandas と、Excel出力用の openpyxl をインストールします。
bash
pip install pandas openpyxl
※コードは注意してご使用ください。
2. Pythonでの自動集計スクリプト例
先ほどの障害履歴CSV(zabbix_events.csv)を読み込んで、「どのホストで」「何の障害が」「何回起きたか」を集計するコードです。
python
import pandas as pd
# 1. CSVデータの読み込み
df = pd.read_csv('zabbix_events.csv')
# 2. 深刻度の数値を文字に変換(読みやすくするため)
severity_map = {0: '未分類', 1: '情報', 2: '警告', 3: '軽度', 4: '重度', 5: '致命的'}
df['深刻度'] = df['深刻度'].map(severity_map)
# 3. ピボットテーブルの作成(Excelの操作と同じ!)
# 行:ホスト名と障害内容、 値:発生日数をカウント
summary = df.pivot_table(
index=['ホスト名', '障害内容'],
columns='深刻度',
values='発生日時',
aggfunc='count',
fill_value=0
)
# 4. 集計結果をExcelファイルとして保存
with pd.ExcelWriter('zabbix_monthly_report.xlsx') as writer:
df.to_sheet(writer, sheet_name='全履歴', index=False) # 元データ
summary.to_excel(writer, sheet_name='障害集計') # 集計データ
print("Excelレポートの作成が完了しました!")
※コードは注意してご使用ください。
3. この方法でできる「高度な集計」Tips
① 障害の多い「ワースト3」を抽出
summary.sort_values(by='警告', ascending=False).head(3) と書くだけで、頻発しているホストを即座に特定できます。
② 曜日・時間帯別の傾向分析
「月曜日の朝だけバックアップ失敗の障害が多い」といった傾向も、発生日時から「曜日」を抽出してピボットテーブルの行に加えるだけで可視化できます。
③ グラフの自動挿入
Pythonの xlsxwriter ライブラリを組み合わせれば、集計結果をもとにExcel内に棒グラフや円グラフを自動で描画した状態で出力することも可能です。
4. 運用の自動化(究極の形)
これまでの手順をすべてつなげると、以下のような「完全自動レポートシステム」が完成します。
- API で前月分の障害データを取得
- pandas でピボット集計&グラフ化
- メール送信(SMTPライブラリ)で関係者にExcelを添付して送信
まとめ
これでZabbixの導入から、Ansibleによる自動化、APIを使った高度なデータ分析まで、一通りの運用サイクルを網羅しました!
■Zabbixの公式サイト(日本語版)は、以下のURLです。
- Zabbix 公式サイト (日本語): https://www.zabbix.com/jp/
- Zabbix Enterprise (日本国内向けサポート・製品情報): https://enterprise.zabbix.co.jp/
免責事項
本記事に掲載されている情報は、執筆時点での動作検証に基づいたものです。OSやソフトウェアのバージョンアップにより、設定方法や画面構成が異なる場合があります。
本記事の内容を基に実施した設定や操作によって生じた、いかなる損害についても当サイトは一切の責任を負いかねます。作業の際は、必ず事前にデータのバックアップを取り、ご自身の責任において実施してください。
✈️ [こちらもcheck!] 巨大地震の停電を生き抜く!スマホ充電に最適なポータブル電源4選