Zabbixでサーバを監視していると、再起動後に「system.uptime」トリガーが誤ってアラートを出すことがあります。
これは、監視停止中にサーバを再起動した際、古い稼働時間データが残っているために差分が負となり、「再起動した」と誤判定される仕様によるものです。
この記事では、この誤検知が起きる仕組みをわかりやすく解説し、現場で使える3つの対処法(トリガーの一時無効化、条件式の調整、テンプレート更新)を具体的に紹介します。
Zabbix運用で頻発するsystem.uptime誤アラートを防ぎ、安定した監視を実現するための実践ガイドです。
Zabbixでサーバ再起動後に誤ってアラートが出る原因とは

Zabbixでサーバを監視していると、再起動後に「system.uptime」トリガーが誤って発報することがあります。
この章では、なぜこのような誤アラートが発生するのか、その仕組みと背景を分かりやすく解説します。
system.uptimeトリガーの仕組みを理解しよう
Zabbixの「system.uptime」は、サーバが起動してからの経過時間(秒)を取得するアイテムです。
多くのテンプレートでは、次のような条件で再起動を検知するトリガーが設定されています。
change(/Template_Windows/system.uptime)<0
これは、前回値よりも現在値が小さい場合、つまり稼働時間が短くなった場合に「再起動した」と判断します。
つまり、system.uptimeがリセットされたこと=再起動だとZabbixが解釈しているわけです。
| 条件式 | 意味 |
|---|---|
| change() < 0 | 前回値より小さい場合にアラートを出す |
| system.uptime | 稼働時間(秒)を取得 |
| トリガー名 | システムが再起動しました |
このトリガーは仕組み上、再起動時だけでなく「古い値が残っている状態で小さい値を受け取る」と誤検知する可能性があります。
再起動時に「change() < 0」が発生する理由
再起動直後はsystem.uptimeが0に近い値を返します。
前回の監視で保存された値が「長時間稼働していた」状態のままだと、差分が大きくマイナスになります。
その結果、Zabbixは「再起動した」と誤って判断し、アラート通知を出してしまうのです。
つまり、system.uptimeの差分だけを見て再起動を判断しているため、監視が一時停止していた場合に誤検知が起きやすいのです。
| 状態 | system.uptime値 | 結果 |
|---|---|---|
| 再起動前(監視停止中) | 86400(24時間) | 保存されたまま |
| 再起動後(監視再開) | 300(5分) | 差分が-86100 → change()<0 |
このように、Zabbixが保持する前回値が古いままの状態だと、再起動していなくても「再起動した」と誤って判断されてしまうことがあります。
監視を無効にして再起動すると誤アラートが出るケース

次に、監視を無効にしている間にサーバを再起動した場合、なぜ誤検知が発生するのかを具体的に見ていきましょう。
メンテナンスモード中の動作と値の保持について
Zabbixでは、ホストをメンテナンスモードに入れるとデータ収集が一時的に停止されます。
つまり、system.uptimeの更新も止まり、Zabbixサーバは「最後に取得した値」を保持したままになります。
再起動後に監視を再開すると、Zabbixはその古い値と新しい値を比較し、差分がマイナスであるため「再起動検知」と判断してしまうのです。
| タイミング | system.uptimeの状態 |
|---|---|
| メンテナンス開始前 | 値を記録(例:432000秒) |
| メンテナンス中(再起動) | 更新停止 |
| 監視再開 | 値が小さくなっている → 誤検知 |
つまり、監視を停止した状態で再起動すると、Zabbixは「古いデータ」と「新しい稼働時間」のギャップを誤って再起動と判断するのです。
Zabbixが再起動を誤検知する流れ
誤アラートが発生する典型的な流れを整理すると、以下のようになります。
- サーバを再起動する前に監視を無効化(メンテナンスモードなど)
- 再起動後、Zabbixが古い稼働時間を保持したまま監視を再開
- 新しいsystem.uptimeが小さいため、差分が負になる
- Zabbixが「再起動」と誤認してアラートを発報
この挙動はZabbixの仕様によるもので、バグではありません。
再起動時に監視が停止していた場合、差分の比較が正しく行えないため、Zabbixとしては「再起動の可能性あり」と判断してしまうのです。
根本的に防ぐには、監視の再開タイミングやトリガー条件の見直しが必要になります。
誤アラートを防ぐための実践的な対処法

Zabbixでsystem.uptimeの誤アラートを防ぐには、トリガーや監視設定を少し工夫するだけで効果的に回避できます。
ここでは、現場でよく使われる実践的な対策を紹介します。
トリガーを一時的に無効化する方法
最も簡単で確実な方法は、サーバを再起動する際にsystem.uptimeトリガーを一時的に無効化することです。
再起動後、一定時間(例えば10分)経過してから再度有効化すれば、誤検知を防ぐことができます。
| 操作手順 | 内容 |
|---|---|
| 1. トリガーを無効化 | Zabbixフロントエンドで対象ホストのトリガーを一時停止 |
| 2. サーバを再起動 | メンテナンスやパッチ適用などの作業を実施 |
| 3. 10分後にトリガーを有効化 | system.uptimeが安定してから監視を再開 |
この方法のポイントは、「system.uptimeが安定して更新されるまで待つ」ことです。
再起動直後は監視エージェントが完全に立ち上がるまでタイムラグがあるため、即座に有効化すると誤検知が起きることがあります。
条件式を変更して誤検知を回避する方法
もう一つのアプローチは、トリガーの条件式を調整することです。
たとえば、次のように「uptimeが一定以上経過してから再起動を判定する」ようにすれば、短時間の停止では誤検知しにくくなります。
change(/Template_Windows/system.uptime)<0 and last(/Template_Windows/system.uptime)>600
この条件式では、稼働時間が600秒(10分)以上経過している場合にのみ再起動を検出します。
つまり、再起動直後やテスト時のような短時間の稼働ではアラートを抑制できるわけです。
| 条件 | 意味 |
|---|---|
| change() < 0 | 再起動の兆候 |
| last() > 600 | 10分以上稼働している場合のみ判定 |
Zabbix 5.0以降の公式テンプレートでは、すでにこの条件式が適用されています。
古いバージョンを利用している場合は、テンプレートの更新を検討するのも有効です。
Zabbix 5.0以降での改善点
Zabbix 5.0以降では、テンプレート内のトリガー条件式が見直され、再起動検出の精度が向上しています。
特に、WindowsテンプレートやLinuxテンプレートの「system.uptime」トリガーは誤検知しにくい設計に変更されています。
| バージョン | トリガー条件式 | 誤検知の可能性 |
|---|---|---|
| 4.x以前 | change() < 0 | 高い |
| 5.x以降 | change() < 0 and last() > 600 | 低い |
もし古いテンプレートを使用している場合は、Zabbix公式リポジトリから最新テンプレートを適用することで誤検知の多くを防げます。
再起動検知のベストプラクティス

ここからは、system.uptimeの誤検知を防ぐための運用面でのベストプラクティスを紹介します。
単に条件式を修正するだけでなく、運用ルールを整えることで、より安定した監視体制を築くことができます。
メンテナンス設定とトリガー管理のコツ
メンテナンスモードを使う際は、「トリガーを抑制する」設定を有効にしておくのが基本です。
これにより、監視対象が再起動してもZabbixがアラートを発報しません。
| 設定項目 | 推奨値 |
|---|---|
| メンテナンスモード | データ収集を停止し、トリガーを抑制 |
| 期間設定 | 再起動作業時間+10分程度 |
| 通知設定 | メンテナンス中は通知を送信しない |
再起動作業の直前にメンテナンスモードを設定し、完了後に自動で解除されるようにしておくのが理想です。
他の監視項目との連携で信頼性を高める
system.uptimeだけでなく、ZabbixエージェントやICMP ping、CPU稼働率など他の項目を組み合わせると、再起動の判定精度を上げられます。
例えば、ping応答とuptimeの両方がリセットされた場合のみ再起動と判断するルールを作成すると、誤検知を大幅に減らせます。
| 項目 | 役割 |
|---|---|
| system.uptime | 稼働時間の計測 |
| icmpping | ネットワーク応答の有無 |
| agent.ping | Zabbixエージェントの動作確認 |
1つの指標だけで判断せず、複数のデータを組み合わせることで誤検知を防ぐのがポイントです。
こうした工夫を取り入れることで、Zabbixの監視をより信頼性の高いものにできます。
まとめ:Zabbixのsystem.uptime誤検知を防ぎ、安定した監視を実現する
この記事では、Zabbixでsystem.uptimeトリガーが誤ってアラートを出してしまう原因と、その対処法を詳しく解説しました。
最後に、ポイントを整理しておきましょう。
| ポイント | 内容 |
|---|---|
| 誤検知の原因 | 監視停止中に再起動し、古いsystem.uptime値が残るため |
| 主な対処法 | トリガーの一時無効化、条件式の変更、テンプレート更新 |
| 推奨設定 | メンテナンスモードでトリガー抑制を有効化 |
| 再発防止策 | system.uptime以外の項目と併用して再起動を検知 |
Zabbixの誤アラートは、仕組みを理解し、運用ルールを少し見直すだけで大きく減らせます。
特に再起動時は「system.uptimeの差分」が誤検知を起こしやすいため、監視再開のタイミングや条件式の工夫が効果的です。
また、Zabbix 5.0以降では公式テンプレートが改善されているため、古いバージョンを使っている場合はアップデートを検討しましょう。
シンプルな再起動検知も、運用の工夫ひとつで安定した監視に変わります。
日常のメンテナンスやトラブル対応をスムーズに進めるために、今回紹介した対策をぜひ取り入れてみてください。

