Zabbix監視設定を初心者向けに完全解説【実務対応】
「Zabbixを導入したけど、監視設定の流れが分からない」
新人エンジニアが最初につまずきやすいポイントです。
Zabbixは非常に高機能な監視ツールですが、
「とりあえず設定しただけ」では実務で役立つ監視にはなりません。
例えば以下のような問題は、初心者がよく経験します。
- アラートが大量に飛ぶ
- 障害なのに通知されない
- CPU監視だけ設定して満足してしまう
- 何を監視すべきか分からない
- 誤検知が多く運用担当に嫌がられる
実際の運用現場では、
「異常を検知すること」だけでなく、
「不要な通知を減らすこと」も非常に重要です。
この記事では、Zabbixの監視設定について、
初心者エンジニア向けに実務視点で分かりやすく解説します。
単なる設定手順ではなく、
- なぜその設定が必要なのか
- どこでハマりやすいのか
- 運用で何が問題になるのか
まで含めて説明していきます。
Zabbix監視設定の基本を理解しよう
Zabbixの監視設定とは
Zabbixの監視設定とは、
「何を」「どの条件で」「どう通知するか」を決める作業です。
例えば以下のような設定を行います。
| 監視対象 | 内容 |
|---|---|
| CPU | 使用率が高すぎないか |
| メモリ | 空き容量不足になっていないか |
| ディスク | 容量逼迫していないか |
| サービス | nginxやApacheが停止していないか |
| ネットワーク | サーバ疎通があるか |
監視設定が適切でないと、
障害を見逃したり、不要な通知が増えたりします。
そのため、単純な設定作業ではなく、
「運用を考えた設計」が重要になります。
監視設定の全体像
Zabbixの基本的な流れは以下です。
- ホスト登録
- テンプレート適用
- アイテム設定
- トリガー設定
- 通知設定
初心者はこの流れが頭の中で整理できず、
途中で混乱しやすいです。
特に多いのが、
- アイテムとトリガーの違いが分からない
- テンプレートの役割が理解できない
という状態です。
初心者が最初に理解すべきポイント
結論から言うと、以下だけ先に理解すると整理しやすくなります。
| 用語 | 役割 |
|---|---|
| アイテム | データ取得 |
| トリガー | 異常判定 |
| アクション | 通知実行 |
例えば、
- CPU使用率を取得する → アイテム
- CPU90%以上で異常 → トリガー
- Slack通知する → アクション
という流れです。
トリガーって監視設定そのものじゃないの？
そこを混同しやすいんだよね。
アイテムが「データ取得」、トリガーが「異常判定」なんだ。
Zabbix監視設定の流れ
ホストを登録する
まず監視対象サーバを登録します。
Linuxサーバなら以下を設定するケースが一般的です。
- ホスト名
- IPアドレス
- エージェント接続設定
- ホストグループ
ここでありがちなミスは、
DNS名と実際のホスト名が一致していないことです。
実務では監視対象が数百台になることもあります。
そのため、
- サーバ名ルール
- グループ名ルール
を最初に決めておくと運用が楽になります。
テンプレートを適用する
初心者は最初から手動設定しがちですが、
実務ではテンプレート利用が基本です。
例えばLinuxサーバなら、
- Linux CPU監視
- メモリ監視
- ディスク監視
などがまとめて適用できます。
テンプレートを使う理由は以下です。
- 設定漏れ防止
- 運用統一
- 大量サーバ対応
逆にテンプレートを理解せず適用すると、
不要監視が大量に増えることがあります。
例えば、
- 不要ファイルシステム監視
- 利用していないサービス監視
などです。
監視項目が多すぎると、
Zabbixサーバ自体が重くなるケースもあります。
関連記事：
アイテムを設定する
アイテムは監視データ取得設定です。
代表例：
| アイテム | 内容 |
|---|---|
| system.cpu.util | CPU使用率 |
| vm.memory.size | メモリ使用量 |
| vfs.fs.size | ディスク容量 |
ここで初心者がハマるのが更新間隔です。
例えば1秒ごと取得にすると、
監視負荷が大きくなります。
実務では一般的に以下が多いです。
| 監視項目 | 更新間隔 |
|---|---|
| CPU | 1分 |
| メモリ | 1分 |
| Ping | 30秒 |
| ログ監視 | 30秒〜1分 |
「細かく取れば良い」ではありません。
必要以上に短くすると、
- DB肥大化
- Zabbix負荷増加
- パフォーマンス低下
につながります。
トリガーを設定する
トリガーは異常判定です。
例えばCPU90%以上で5分継続時に障害とする場合：
avg(/Linux server/system.cpu.util,5m)>90
重要なのは「継続時間」です。
初心者は瞬間値だけで設定しがちです。
しかし実務では、一瞬CPUが90%を超えることは普通にあります。
継続条件を入れないと誤検知だらけになります。
CPU90%なら即アラートで良くない？
バッチ処理で一瞬上がるだけでも通知されるよ。
「継続して異常か」を見るのが大事なんだ。
関連記事：
通知設定を行う
最後に通知設定です。
メールやSlack連携を行います。
ここで非常に多いのが、
- メディア設定漏れ
- ユーザー権限不足
- アクション条件ミス
です。
特に「障害は発生しているのに通知されない」は実務でも頻発します。
設定後は必ずテスト通知を実施しましょう。
実務でよく使うZabbix監視設定例
CPU使用率監視
もっとも基本的な監視です。
ただしCPUだけ見ても意味はありません。
例えば、
- 高負荷原因
- バッチ時間帯
- 通常時負荷
も考慮が必要です。
実務では以下が多いです。
| 条件 | 意味 |
|---|---|
| 80% 5分継続 | Warning |
| 90% 10分継続 | High |
メモリ使用率監視
Linuxではキャッシュ利用があるため、
単純な使用率だけでは判断しにくいです。
初心者は「使用率90%=危険」と考えがちですが、
Linuxでは正常な場合もあります。
そのため、
- availableメモリ
- swap使用率
も合わせて見ることが多いです。
ディスク容量監視
実務で非常に重要です。
ディスクフルは障害につながりやすいためです。
ただし、ログ肥大化で一時的に増えるケースもあります。
そのため、
- 80% Warning
- 90% High
程度から始めるケースが一般的です。
プロセス監視
nginxやApacheなどの停止監視です。
特に重要なのは、
「プロセスがある = 正常」
ではない点です。
実際には、
- 応答停止
- ハング
- タイムアウト
も発生します。
そのため、
- プロセス監視
- ポート監視
- Web監視
を組み合わせることがあります。
Ping監視
最もシンプルな死活監視です。
ただしPingだけでは、
- アプリ障害
- DB障害
は検知できません。
初心者はPing監視だけで安心しがちなので注意です。
初心者がハマりやすいポイント
誤検知が多発する
実務で最も嫌われるのが誤検知です。
通知が多すぎると、
運用担当が通知を見なくなります。
これを「アラート疲れ」と呼ぶことがあります。
対策：
- 継続条件を入れる
- メンテナンス設定を使う
- 閾値を現実的にする
閾値が厳しすぎる
CPU70%で即障害などは典型例です。
実際には正常時負荷を見て調整します。
まずは監視データを数日取り、
通常値を把握するのが重要です。
テンプレートを理解せず使う
テンプレート適用だけで満足する初心者は多いです。
しかし実務では、
- 不要監視削除
- 項目調整
- 閾値調整
が必要になります。
「テンプレート = 完成品」ではありません。
障害通知が届かない
実務でかなり多いです。
特に以下を確認しましょう。
- SMTP設定
- メディア設定
- ユーザー設定
- アクション条件
- 権限設定
Zabbixの運用負荷を減らす監視設計の考え方
全部監視すれば良いわけではない
初心者ほど監視項目を増やしがちです。
しかし監視項目が多すぎると、
- 誤検知増加
- 運用負荷増加
- 原因分析困難
になります。
重要なのは、
「障害対応に必要な監視」
を優先することです。
通知疲れを防ぐ
通知は少ないほど良いです。
本当に対応が必要な障害だけ通知しましょう。
例えば、
- 一時的高負荷
- 一瞬のパケットロス
を毎回通知すると運用が破綻します。
障害対応しやすい監視名にする
意外と重要です。
悪い例：
High CPU良い例：
WEB01 CPU使用率90%以上継続障害対応時に状況把握しやすくなります。
監視設定後に確認すべきポイント
実際にデータ取得できているか
最新データが更新されているか確認します。
未取得なら以下を疑います。
- Firewall
- Zabbix Agent停止
- ポート疎通
- ホスト名不一致
アラートが正常に飛ぶか
テスト用トリガーで確認しましょう。
本番障害で初めて気づくケースは危険です。
復旧通知が届くか
障害通知だけ確認して終わる初心者は多いです。
しかし実務では「復旧通知」も重要です。
復旧通知がないと、
「今どうなってる？」
が分からなくなります。
まとめ
Zabbix監視設定で重要なのは、
単に「監視すること」ではありません。
- 必要な異常を検知する
- 不要通知を減らす
- 障害対応しやすくする
ことが大切です。
初心者のうちは、
「全部監視したい」
と思いがちですが、
実務では監視の整理も重要なスキルです。
まずは、
- CPU
- メモリ
- ディスク
- サービス監視
など基本監視から始め、
徐々に運用しやすい監視設計を目指しましょう。
Related Posts:
