• HOME
  • Zabbixでサーバー監視テンプレートを設定する（公式テンプレートの適用・マクロ調整・WordPress用テンプレート作成）

2026年7月21日

  • シェア
  • ツイート

    • 2026年7月21日

    Zabbixでサーバー監視テンプレートを設定する（公式テンプレートの適用・マクロ調整・WordPress用テンプレート作成）

    Zabbix のテンプレートは、監視項目（アイテム）・障害の条件（トリガー）・グラフ・自動検出ルールをひとまとめにした設定の型です。サーバー監視は、まず公式テンプレートをホストに割り当て、しきい値をマクロで自分の環境に合わせ、足りない部分だけ自作テンプレートで補う、という順に進めると管理が楽になります。この記事では、その3段階を WordPress サーバーを例に説明します。Agent の導入とホスト登録が済んでいることが前提です。

    テンプレートの仕組みを押さえる

    テンプレートをホストに割り当てる（リンクする）と、テンプレートに定義されたアイテムやトリガーがホストに複製されます。テンプレート側を直すと、リンクしているすべてのホストに反映されます。ホストごとに直接アイテムを作ると、台数が増えたときに同じ修正を何度も繰り返すことになるため、設定はできるだけテンプレート側に寄せます。

    テンプレートに含まれる主な要素は次のとおりです。

    • アイテム: 取得する値（CPU 使用率、ディスク使用率、プロセス数など）と取得間隔
    • トリガー: アイテムの値が条件を満たしたら障害とみなすルール
    • ローレベルディスカバリー（LLD）: ファイルシステムやネットワークインターフェースを自動で見つけ、見つかった数だけアイテムやトリガーを作る仕組み
    • マクロ: しきい値などを変数にしたもの。{$NAME} の形で書きます
    • グラフ・ダッシュボード: テンプレートに付属する表示用の設定

    テンプレートは複数をホストに割り当てられます。「OS の監視」「Web サーバーの監視」「DB の監視」と役割ごとに分けておくと、構成の違うサーバーにも組み合わせで対応できます。

    手順1: 公式テンプレートを割り当てる

    Zabbix には OS やミドルウェア向けの公式テンプレートが多数付属しています。名前は「監視対象 by 取得方法」の形式で、たとえば次のようなものがあります（収録内容と名前は版によって変わります。2026年10月現在の 7.x 系を想定しています）。

    • Linux by Zabbix agent / Linux by Zabbix agent active
    • Nginx by Zabbix agent、Apache by Zabbix agent
    • MySQL by Zabbix agent 2（Agent 2 のプラグインで取得）
    • Website certificate by Zabbix agent 2（TLS 証明書の有効期限など）

    ホストの設定画面でテンプレート欄に名前の一部を入力すると候補が出ます。WordPress サーバーなら、まず Linux 用を割り当て、Web サーバーと DB のテンプレートを追加するのが基本形です。

    ミドルウェアのテンプレートは、Zabbix 側の設定だけでは値が取れないことがあります。Nginx のテンプレートなら stub_status のページ、MySQL なら監視用の DB ユーザーが必要です。各テンプレートの説明欄やマクロ一覧に、必要な準備と接続先を指定するマクロが書かれているので、割り当てる前に目を通します。たとえば Nginx の stub_status は、監視サーバーやローカルからだけ見えるように制限します。

    location = /basic_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}

    MySQL の監視ユーザーには、必要な権限だけを与えます。管理者ユーザーを監視に使い回すのは避けます。

    CREATE USER 'zbx_monitor'@'localhost' IDENTIFIED BY 'your-monitor-password';
GRANT REPLICATION CLIENT, PROCESS, SHOW DATABASES, SHOW VIEW ON *.* TO 'zbx_monitor'@'localhost';

    割り当てて数分たったら、最新データの画面でアイテムに値が入っているか確認します。「サポートされていません」と表示されるアイテムがあれば、そのアイテムにマウスを合わせるとエラーの理由が見られます。多くは権限不足か、接続先マクロの設定漏れです。

    手順2: しきい値をマクロで調整する

    公式テンプレートのトリガーは、しきい値をマクロで受け取るように作られています。たとえば Linux 用テンプレートでは、ディスク使用率の警告と重大のしきい値、CPU 使用率、メモリ使用率などがマクロになっています。正確なマクロ名と初期値は、テンプレートの「マクロ」タブで確認してください。

    しきい値を変えたいときに、テンプレートのトリガー式を直接書き換えてはいけません。公式テンプレートを新しい版に差し替えたときに変更が消えるうえ、すべてのホストに影響します。代わりに、ホスト側で同じ名前のマクロを定義して上書きします。

    ホストのマクロ設定の例
{$VFS.FS.PUSED.MAX.WARN} = 85
{$VFS.FS.PUSED.MAX.CRIT} = 95

    マクロにはコンテキストを付けられます。特定のマウントポイントだけしきい値を変える、といった指定ができます。

    {$VFS.FS.PUSED.MAX.WARN:"/var/log"} = 70

    マクロの優先順位は「ホスト → リンクしたテンプレート → グローバル」の順で、ホストに書いた値が最優先です。どの値が効いているかは、ホストのマクロ画面で継承した値も含めて表示させると確認できます。

    通知が多すぎるときの考え方

    公式テンプレートをそのまま使うと、最初の数日は通知が多く感じられることがあります。通知を減らしたいからといってトリガーを片端から無効にすると、本当の障害を見逃します。次の順で見直します。

    1. しきい値がその環境に合っているか（マクロで調整）
    2. 一瞬の値で判定していないか（平均や一定時間の継続で判定するトリガーかどうか）
    3. 重要度が適切か（警告レベルは通知せず画面で見るだけ、など、アクション側で振り分ける）
    4. その監視が本当に不要か（不要なら、そのトリガーだけを無効化する）

    手順3: WordPress 用のテンプレートを自作する

    OS やミドルウェアの監視だけでは、「サーバーは元気なのにサイトがエラーを返している」状態に気づけません。そこで、サイトの応答を確認する自作テンプレートを用意します。

    テンプレートの作成画面で名前（例: Template WordPress site）とテンプレートグループを決めて保存し、その中に次の要素を作ります。

    Web シナリオでトップページとログイン画面を確認する

    Web シナリオは、Zabbix サーバー（またはプロキシ）から URL にアクセスし、ステータスコードや応答時間、ページに含まれる文字列を確認する機能です。テンプレートに作っておけば、ホストに割り当てるだけで使えます。

    • シナリオ名: WordPress top
    • ステップ1（名前: Top page）: URL に https://{$WP.URL}/、要求するステータスコードに 200、要求文字列にサイト名など表示されるはずの文字列
    • ステップ2（名前: Login page）: URL に https://{$WP.URL}/wp-login.php、要求するステータスコードに 200

    URL をマクロ {$WP.URL} にしておけば、ホストごとにドメインを変えるだけで使い回せます。要求文字列を入れておくと、ステータスコードは 200 なのに真っ白な画面やエラーメッセージが出ている、という状態も検知できます。

    Web シナリオを作ると、失敗したステップの番号や応答時間のアイテムが自動で作られます。これを使ってトリガーを書きます。トリガー式は「関数(/ホストまたはテンプレート名/アイテムキー, 期間)」の形式です。

    # シナリオのいずれかのステップが失敗した
last(/Template WordPress site/web.test.fail[WordPress top])<>0

# トップページの応答時間が5分平均で3秒を超えた
avg(/Template WordPress site/web.test.time[WordPress top,Top page,resp],5m)>3

    アイテムキーの引数にはシナリオ名とステップ名を使うため、名前を変えるとトリガーも直す必要があります。トリガーを書いたら、テンプレートを割り当てたホストの最新データで、実際に値が入っているかを確かめます。

    PHP-FPM のプロセスを監視する

    PHP-FPM が落ちると、Nginx は 502 を返します。Agent のアイテムキー proc.num でプロセス数を数え、0 になったら障害にします。

    アイテムキー: proc.num[php-fpm8.3]
トリガー式: last(/Template WordPress site/proc.num[php-fpm8.3])=0

    プロセス名は PHP の版や OS で変わります。対象サーバーで ps -e | grep php を実行し、実際のプロセス名に合わせます。

    テンプレートを書き出して保管する

    作ったテンプレートは、一覧画面から YAML などの形式で書き出せます。書き出したファイルを Git などで管理しておくと、変更の履歴が残り、別の Zabbix サーバーへの移行や、誤って壊したときの復旧が楽になります。

    公式テンプレートの更新と外し方

    Zabbix 本体をアップグレードしても、すでに取り込まれている公式テンプレートは自動では新しくなりません。新しい版のテンプレートを使いたい場合は、公式の配布元から該当するテンプレートを取得して取り込みます。取り込み時に既存の設定が上書きされるため、事前にテンプレートを書き出してバックアップしておき、検証用のホストで動作を確かめてから本番のホストへ広げます。

    ホストからテンプレートを外す操作には、「リンクを外す」と「リンクを外してクリア」の2種類があります（表記は版によって異なります）。前者はアイテムがホストに残り、後者はアイテムと収集済みのデータも消えます。過去のグラフを残したいかどうかで選び分けます。

    まとめ

    • テンプレートはアイテム・トリガー・LLD・マクロをまとめた設定の型。設定はホストではなくテンプレート側に寄せる
    • まず公式テンプレート（Linux、Web サーバー、DB）を割り当て、必要な準備（stub_status や監視用 DB ユーザー）を整える
    • しきい値はトリガー式を書き換えず、ホスト側のマクロで上書きする。コンテキスト付きマクロで対象ごとに調整できる
    • サイトの応答は自作テンプレートの Web シナリオで確認し、要求文字列で真っ白な画面も検知する
    • 自作テンプレートは書き出して保管し、公式テンプレートの更新はバックアップと検証のあとに行う
    Views: 49

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲