4.3 トリガーシステム

収集データに基づく問題検知と通知の自動化メカニズム

概要

**トリガー(Triggers)**は、Zabbixにおいて収集されたアイテムデータを評価し、問題状況を自動的に検出するルールエンジンです。トリガーは論理式を使用してデータを分析し、設定された条件が満たされた場合にイベントを生成します。

トリガーシステムの基本構成

要素説明
条件判定のロジック{host:item.key.func(param)}<threshold
深刻度問題の重要度レベルInformation, Warning, Average, High, Disaster
ステータストリガーの有効・無効状態Enabled, Disabled
依存関係他のトリガーとの関連性上位システムのトリガーに依存

トリガー式の基本構文

基本的な式構造

ini
# 基本構文
{host:item.key.function(parameter)}operator value

# CPU使用率が80%を超える場合
{web-server:system.cpu.util[,idle].last()}<20

# メモリ使用率が90%を超える場合
{web-server:vm.memory.util.last()}>90

主要な関数一覧

統計関数

ini
# 最新値
last() - 最後に受信した値
last(#3) - 最後から3番目の値

# 平均値
avg(5m) - 5分間の平均値
avg(#10) - 最新10個の値の平均

# 最大・最小値
max(1h) - 1時間の最大値
min(1h) - 1時間の最小値

# 合計値
sum(24h) - 24時間の合計値

変化検出関数

ini
# 値の変化
change() - 前回値からの変化量
diff() - 前回値との差(Boolean)

# 変化率
delta(1h) - 1時間での変化量

時間関数

ini
# データ受信時刻
date() - 現在の日付
time() - 現在の時刻(HHMMSS形式)
now() - 現在のUnixタイムスタンプ

# データ年齢
nodata(10m) - 10分間データが受信されていない

実践的なトリガー式例

システムリソース監視

ini
# CPU使用率が5分間継続して80%を超える
{host:system.cpu.util.avg(5m)}>80

# メモリ使用率が95%を超える
{host:vm.memory.util.last()}>95

# ディスク使用量が90%を超える
{host:vfs.fs.size[/,pused].last()}>90

# スワップ使用量が50MB以上
{host:system.swap.size[,used].last()}>52428800

ネットワーク監視

ini
# ネットワークインターフェースがダウン
{host:net.if.in[eth0].nodata(3m)}=1

# 高いパケットロス率(5%以上)
{host:net.if.in.errors[eth0].delta(5m)}/{host:net.if.in[eth0].delta(5m)}*100>5

# 異常な通信量(平均の3倍以上)
{host:net.if.in[eth0].avg(5m)}/{host:net.if.in[eth0].avg(1h)}>3

サービス可用性監視

ini
# Webサービスが応答しない
{host:net.tcp.service[http].last()}=0

# データベース接続失敗
{host:net.tcp.service[mysql].last()}=0

# HTTPレスポンス時間が5秒以上
{host:web.page.perf[www.example.com].last()}>5

深刻度レベルの設定

深刻度レベルの定義

レベル数値説明使用例
Not classified0分類されていないテスト用トリガー
Information1情報通知システム再起動通知
Warning2警告リソース使用率70%
Average3平均的問題サービス応答遅延
High4重要な問題サービス停止
Disaster5災害レベルシステム全体停止

深刻度別の設定例

Information レベル

ini
# システム再起動検知
Name: System uptime reset detected
Expression: {host:system.uptime.change()}<0
Severity: Information
Description: System has been restarted

# 設定変更検知
Name: Configuration file changed
Expression: {host:vfs.file.cksum[/etc/myapp.conf].diff()}=1
Severity: Information

Warning レベル

ini
# CPU使用率警告
Name: High CPU usage warning
Expression: {host:system.cpu.util.avg(5m)}>70
Severity: Warning
Description: CPU utilization is above 70% for 5 minutes

# ディスク容量警告
Name: Disk space warning
Expression: {host:vfs.fs.size[/,pused].last()}>80
Severity: Warning

Average レベル

ini
# メモリ不足
Name: Memory usage high
Expression: {host:vm.memory.util.last()}>85
Severity: Average
Description: Memory utilization exceeds 85%

# 高負荷状態
Name: High system load
Expression: {host:system.cpu.load[,avg5].last()}>5
Severity: Average

High レベル

ini
# サービス停止
Name: Critical service down
Expression: {host:proc.num[httpd].last()}=0
Severity: High
Description: No httpd processes running

# データベース接続失敗
Name: Database connection failure
Expression: {host:net.tcp.service[mysql].last()}=0
Severity: High

Disaster レベル

ini
# システム応答なし
Name: System unreachable
Expression: {host:agent.ping.nodata(5m)}=1
Severity: Disaster
Description: No response from Zabbix agent for 5 minutes

# ファイルシステム満杯
Name: Filesystem full
Expression: {host:vfs.fs.size[/,pused].last()}>95
Severity: Disaster

複雑なトリガー条件

複数条件の組み合わせ

AND条件

ini
# CPU使用率が高く、かつロードアベレージも高い
{host:system.cpu.util.avg(5m)}>80 and {host:system.cpu.load[,avg5].last()}>3

# メモリ使用率が高く、かつスワップも使用している
{host:vm.memory.util.last()}>90 and {host:system.swap.size[,used].last()}>0

# 営業時間内の高負荷警告
{host:system.cpu.util.avg(5m)}>70 and time()>090000 and time()<180000

OR条件

ini
# 複数のサービスのいずれかが停止
{host:proc.num[httpd].last()}=0 or {host:proc.num[mysqld].last()}=0

# 複数のパーティションのいずれかが満杯に近い
{host:vfs.fs.size[/,pused].last()}>90 or {host:vfs.fs.size[/var,pused].last()}>90

複雑な条件組み合わせ

ini
# 営業時間外の高負荷、または営業時間内の異常な高負荷
({host:system.cpu.util.avg(5m)}>60 and (time()<090000 or time()>180000)) or ({host:system.cpu.util.avg(5m)}>85 and time()>090000 and time()<180000)

# ネットワーク障害の複合判定
({host:net.if.in[eth0].nodata(3m)}=1 and {host:net.if.out[eth0].nodata(3m)}=1) or {host:icmpping.last()}=0

時間ベースの条件

時間帯制限

ini
# 営業時間内のみ監視
{host:web.page.perf[www.example.com].last()}>10 and time()>090000 and time()<180000

# 夜間バッチ処理時間外の高負荷
{host:system.cpu.util.avg(5m)}>70 and not (time()>020000 and time()<040000)

# 平日のみ監視
{host:service.check.last()}=0 and dayofweek()>=2 and dayofweek()<=6

日付・曜日条件

ini
# 平日営業時間の条件
dayofweek()>=2 and dayofweek()<=6 and time()>090000 and time()<180000

# 月末処理期間の条件
date()>=20250125 and date()<=20250131

# 定期メンテナンス時間の除外
not (dayofweek()=1 and time()>020000 and time()<060000)

予測・トレンド分析

フォーキャスト関数

基本的な予測

ini
# 1時間後のディスク使用率が95%を超える予測
{host:vfs.fs.size[/,pused].forecast(1h)}>95

# 6時間後のメモリ使用量が物理メモリを超える予測
{host:vm.memory.size[used].forecast(6h)}/{host:vm.memory.size[total].last()}>1

# 24時間後のログファイルサイズが1GBを超える予測
{host:vfs.file.size[/var/log/messages].forecast(24h)}>1073741824

トレンド分析

ini
# CPU使用率の上昇トレンド検知
{host:system.cpu.util.avg(1h)}-{host:system.cpu.util.avg(6h)}>20

# メモリリークの検出(継続的な増加)
{host:vm.memory.size[used].delta(1h)}>104857600 and {host:vm.memory.size[used].delta(6h)}>629145600

# ディスク使用量の異常増加
{host:vfs.fs.size[/,used].delta(1h)}>1073741824

パーセンタイル分析

ini
# CPU使用率の95パーセンタイルが80%以上
{host:system.cpu.util.percentile(1h,95)}>80

# レスポンス時間の99パーセンタイルが5秒以上
{host:web.page.perf[api.example.com].percentile(1h,99)}>5

# ネットワーク使用率の異常値検出
{host:net.if.in[eth0].percentile(1h,90)}/{host:net.if.in[eth0].avg(1h)}>2

トリガー依存関係

基本的な依存関係設定

ネットワーク依存

ini
# Webサービストリガー
Name: Web service not responding
Expression: {web-server:net.tcp.service[http].last()}=0
Dependencies:
  - Network connectivity to web-server

# ネットワーク接続トリガー
Name: Network connectivity to web-server
Expression: {web-server:icmpping.last()}=0

サービス階層依存

ini
# アプリケーション層
Name: Application service error
Expression: {app-server:log[/var/log/app.log,"ERROR"].nodata(1m)}=0
Dependencies:
  - Database connection failure
  - Web server not responding

# データベース層
Name: Database connection failure
Expression: {db-server:net.tcp.service[mysql].last()}=0
Dependencies:
  - Database server unreachable

# インフラ層
Name: Database server unreachable
Expression: {db-server:icmpping.last()}=0

複雑な依存関係

クラスター環境の依存関係

ini
# 個別ノード障害
Name: Cluster node 1 down
Expression: {cluster-node-1:agent.ping.last()}=0
Dependencies:
  - Cluster network failure

Name: Cluster node 2 down
Expression: {cluster-node-2:agent.ping.last()}=0
Dependencies:
  - Cluster network failure

# サービス層障害
Name: Cluster service degraded
Expression: {cluster-node-1:service.status.last()}=0 or {cluster-node-2:service.status.last()}=0
Dependencies:
  - Cluster node 1 down
  - Cluster node 2 down

# 全体障害
Name: Complete cluster failure
Expression: {cluster-node-1:agent.ping.last()}=0 and {cluster-node-2:agent.ping.last()}=0

ヒステリシス(回復条件)

基本的なヒステリシス設定

ini
# CPU使用率トリガー
Problem expression: {host:system.cpu.util.avg(5m)}>80
Recovery expression: {host:system.cpu.util.avg(5m)}<70
Recovery mode: Recovery expression

# メモリ使用率トリガー(マージン付き)
Problem expression: {host:vm.memory.util.last()}>90
Recovery expression: {host:vm.memory.util.last()}<85

時間ベースの回復条件

ini
# 安定した回復の確認
Problem expression: {host:system.cpu.util.avg(5m)}>80
Recovery expression: {host:system.cpu.util.avg(10m)}<70 and {host:system.cpu.util.max(10m)}<75

# 複数条件の回復
Problem expression: {host:system.cpu.util.avg(5m)}>80 and {host:system.cpu.load[,avg5].last()}>3
Recovery expression: {host:system.cpu.util.avg(10m)}<70 and {host:system.cpu.load[,avg5].avg(5m)}<2

トリガーのデバッグとテスト

式テスターの活用

基本テスト手順

  1. Configuration → Triggers
  2. 対象トリガーの編集
  3. Expression constructor使用
  4. Testボタンでテスト実行

問題の診断方法

一般的な問題と解決策

ini
# データが取得できない場合
Problem: {host:item.key.last()}=0
Check:
  - アイテムが正常に動作しているか
  - データタイプが正しいか
  - エージェントが稼働しているか

# 式の評価エラー
Problem: Unknown function in expression
Check:
  - 関数名のスペルチェック
  - パラメータの形式確認
  - サポートされている関数か確認

デバッグ用トリガー

ini
# データ受信確認用
Name: Debug - Data reception
Expression: {host:item.key.nodata(5m)}=1
Severity: Information
Description: Item data not received for 5 minutes

# 値範囲確認用
Name: Debug - Value range check
Expression: {host:item.key.last()}<0 or {host:item.key.last()}>100
Severity: Information
Description: Value outside expected range (0-100)

パフォーマンス最適化

効率的なトリガー設計

最適化のベストプラクティス

ini
# 効率的な式(推奨)
{host:item.key.last()}>threshold

# 非効率的な式(避ける)
{host:item.key.avg(1h)}>threshold and {host:item.key.avg(2h)}>threshold

計算負荷の軽減

ini
# 軽い評価式
{host:system.cpu.util.last()}>90

# 重い評価式(必要な場合のみ使用)
{host:system.cpu.util.percentile(1h,95)}>80 and {host:system.cpu.util.avg(1h)}>70

トリガー評価の最適化

評価間隔の設定

ini
# 高頻度評価(重要なサービス)
Critical services: 30秒
Security monitoring: 30秒

# 中頻度評価(一般監視)
Resource monitoring: 60秒
Application monitoring: 60秒

# 低頻度評価(静的チェック)
Configuration changes: 300秒
Hardware status: 300秒

まとめ

Zabbixのトリガーシステムは、監視データを基にした高度な問題検知機能を提供します。適切な式の設計、深刻度の設定、依存関係の活用により、効果的なアラートシステムを構築できます。トリガーの最適化とデバッグ手法を活用することで、誤報を最小限に抑えた信頼性の高い監視を実現できます。

次のセクションでは、トリガーによって生成されるイベントとそれに対するアクションについて詳しく説明します。


参考リンク

← 前へ: 4.2 アイテムとデータタイプ | 次へ: 4.4 イベントとアクション →