Zabbixトリガー設定を初心者向けに完全解説【監視運用の基本】

Zabbixで監視設定を始めると、多くの新人エンジニアが最初につまずくのが「トリガー設定」です。

「CPU使用率が高い時に通知したい」
「サーバ停止を検知したい」
「でも、どの値でアラートを出せばいいの？」

このあたりで悩むケースはかなり多いです。

実際、Zabbixはアイテム設定だけでは監視になりません。
「異常をどう判断するか」を決めるトリガー設定が重要になります。

ただし、適当に設定すると以下のような問題が発生します。

• 誤検知だらけになる
• アラートが大量発生する
• 本当に危険な障害を見逃す
• 運用担当がアラート疲れする

これは実務でもよくある失敗です。

この記事では、監視運用の現場でよく使う考え方を交えながら、初心者向けにZabbixトリガー設定を分かりやすく解説します。

Zabbixトリガーとは何か

トリガーの役割

Zabbixのトリガーとは、「どの状態を異常と判断するか」を決める設定です。

例えば以下のような条件です。

• CPU使用率90%以上
• ディスク使用率80%以上
• ping応答なし
• ログにerror文字列が出現

つまり、アイテムで取得した値を見て、異常判定を行うのがトリガーです。

監視運用ではかなり重要な設定になります。

アイテムとの違い

初心者が混乱しやすいのがここです。

項目	役割
アイテム	データを取得する
トリガー	異常か判断する

例えばCPU使用率監視なら以下です。

• アイテム：CPU使用率を取得
• トリガー：90%以上なら異常

この役割分担を理解すると、設定がかなり分かりやすくなります。

Zabbixトリガー設定の基本

トリガー式とは

トリガーは「式」で判定します。

例えばCPU高負荷なら以下のような式です。

last(/Linux server/system.cpu.util[,system])>90

意味は以下です。

設定	意味
last()	最新値を取得
system.cpu.util	CPU使用率
>90	90%以上

つまり、
「最新のCPU使用率が90%以上なら異常」
という意味になります。

よく使う関数

初心者が最初に覚えるべき関数はそこまで多くありません。

関数	内容
last()	最新値
avg()	平均値
max()	最大値
min()	最小値
nodata()	データ未取得

特に実務でよく使うのはavg()です。

severity（重要度）の考え方

トリガーには重要度があります。

例えば以下です。

重要度	用途例
Information	参考情報
Warning	軽微な異常
Average	要確認
High	重大障害
Disaster	サービス停止レベル

ここを適当に設定すると、運用チームが混乱します。
例えば「ディスク80%使用」でDisasterにすると、アラートだらけになります。

実務では「本当に即対応が必要か」で決めるケースが多いです。

実際にCPU監視のトリガーを設定してみる

CPU高負荷監視の例

よくある設定例です。

avg(/Linux server/system.cpu.util[,system],5m)>90

これは、
「5分平均CPU使用率が90%以上」
という意味です。

なぜ「5分平均」を使うのか

ここは実務でかなり重要です。

CPUは一瞬だけ跳ね上がることがあります。

例えば以下です。

• バックアップ開始
• ウイルススキャン
• バッチ処理
• ログローテート

一瞬100%になっても、障害とは限りません。

そのため、平均値で判定します。

これをしないと誤検知が大量発生します。

実務で多い失敗例

初心者がよくやる設定です。

last()>80

これだと一瞬80%を超えただけでアラートになります。

結果として、

• 通知が鳴り続ける
• 誰もアラートを見なくなる
• 本番障害を見逃す

という状態になります。

監視運用では「アラートを減らす設計」がかなり重要です。

よく使うZabbixのトリガー設定例

サーバダウン監視

max(/Linux server/icmpping,3m)=0

3分間ping応答なしなら異常です。
一時的なネットワーク瞬断を避けるため、少し猶予を持たせます。

ディスク容量監視

last(/Linux server/vfs.fs.size[/,pused])>80

ディスク使用率80%以上を監視します。

ただし実務では以下も考えます。

• どの速度で増加しているか
• ログ肥大化か
• 一時ファイルか

単純な閾値だけでは判断できないことも多いです。

メモリ監視

avg(/Linux server/vm.memory.size[pavailable],5m)<20

利用可能メモリが20%未満なら警告です。
Linuxはキャッシュを積極利用するため、単純な使用率だけでは判断しにくい点に注意です。

ログ監視

log[/var/log/messages,error]

error文字列を検知します。
ただしログ監視は誤検知しやすいです。

例えば以下があります。

• harmless error
• 一時的warning
• アプリ固有メッセージ

ログ監視は運用しながら調整するケースが多いです。

誤検知を減らすための考え方

一瞬の値でアラートを出さない

これはかなり重要です。

実務では以下をよく使います。

• avg()
• count()
• max()

「継続して異常か」を見る考え方です。

メンテナンス時間を考慮する

監視停止設定を忘れると、メンテ中に大量通知が飛びます。
新人時代に一度は経験するポイントです。

特に以下は注意です。

• OS再起動
• パッチ適用
• NW機器メンテ
• DB再起動

メンテナンス設定は運用では必須です。

閾値を厳しくしすぎない

初心者ほど「厳しく監視しよう」としがちです。

ですが実際は逆です。
厳しすぎると誤検知が増えます。

結果として、

• 通知を無視する
• メールを見なくなる
• 本当に危険な障害を見逃す

という運用崩壊につながります。

運用負荷を減らすためのZabbixトリガー設計

通知が多すぎる問題

実務で一番つらいのはこれです。
監視サーバが「狼少年化」します。

例えば、

• 深夜に大量通知
• 毎日同じWarning
• 復旧と障害を繰り返す

こうなると誰も真面目に見なくなります。

本当に見るべきアラートを決める

レベル	対応
Disaster	即対応
High	早め対応
Warning	営業時間対応

全部を即通知しないことも重要です。

障害対応しやすいメッセージにする

トリガー名はかなり重要です。

悪い例：

CPU Alert
→これだけだとCPUの何が悪くてアラートしているか分からない

良い例：

Webサーバ CPU使用率90%以上が5分継続
→どこのサーバのCPUがどうなっているからアラートが出ているか分かりやすい

これだけで障害対応速度がかなり変わります。

Zabbixのトリガー設定で初心者がハマりやすいポイント

トリガーが発火しない

原因として多いのは以下です。

• アイテム未取得
• 関数ミス
• ホスト名違い
• データ不足

特にavg()は一定時間データが必要です。

設定直後は発火しないことがあります。

復旧しない

これもかなり多いです。

例えば以下です。

last()>80

値が79.9にならない限り復旧しません。
実務ではヒステリシス設定を使うケースもあります。

データ取得間隔との関係

例えば取得間隔60秒なのに、

avg(30s)

を設定しても意味がありません。

取得間隔とトリガー条件はセットで考えます。

Zabbixテンプレート化も重要

手動設定が増える問題

サーバ台数が増えると、毎回手動設定はかなり大変です。
また設定漏れも発生します。

テンプレート運用のメリット

テンプレート化すると以下が楽になります。

• 設定統一
• 監視品質向上
• 運用負荷削減
• 設定漏れ防止

関連記事として、
「Zabbixテンプレート作成を初心者向けに完全解説」
も合わせて読むと理解しやすいです。

まとめ

Zabbixトリガー設定は、
「どの状態を異常とするか」
を決める重要な設定です。

特に初心者は、

• 閾値を厳しくしすぎる
• 一瞬の値で通知する
• 通知を増やしすぎる

という失敗をしやすいです。

監視運用では、
「正しく異常を検知する」
だけでなく、

「不要通知を減らす」

ことも非常に重要です。

まずはシンプルな監視から始めて、運用しながら調整していくのがおすすめです。