スケジュールドレポートとアラート

このページの内容

1. スケジュールドレポート

前節までで作ったレポートは、手動で開けばその場で実行されます。しかし「毎朝9時に前日のアクセス集計を自動で作りたい」といった運用では、毎回人が実行するのは現実的ではありません。そこで使うのがスケジュールドレポート(Scheduled Report)です。

レポートの編集画面からスケジュールを有効化すると、指定した時刻・間隔でSplunkが自動的にサーチを実行してくれます。「毎日」「毎週月曜」「1時間ごと」などのプリセットのほか、 cron形式で細かく指定することもできます。

スケジュール実行するサーチの例

index=web status>=500 | stats count by host

スケジュールドレポートには、実行完了時に結果をメール送信するなどのアクションも設定できます。定期的な集計の配信に向いています。

スケジュールされたサーチは自動で走るため、対象期間を広げすぎたり短い間隔で回しすぎたりすると、システムに負荷をかけます。期間と頻度は必要十分な範囲に設定しましょう。

アラート(Alert)は、サーチを定期的に実行し、その結果が条件を満たしたときに発報(通知)する仕組みです。スケジュールドレポートが「結果を定期的に届ける」ものだとすれば、アラートは「異常なときだけ知らせる」ものだと考えると分かりやすいでしょう。

たとえば「サーバーエラー(500番台)が短時間に多発したら管理者に知らせる」といった監視を自動化できます。アラートも「Save As > Alert」から、通常のサーチをもとに作成します。

SPL ― アラートのもとにするサーチ

index=web status=500 | stats count

アラートの中心となるのがトリガー条件(Trigger Conditions)です。「どういう結果になったら発報するか」を決めます。最もよく使うのは結果の件数による条件です。

たとえば先ほどのstats countの結果に対し、「countが10より大きいときに発報」と設定すれば、エラーが10件を超えたときだけ通知が飛びます。あわせて実行スケジュール(例: 5分ごと)も指定します。

閾値を低くしすぎると通知が鳴りやまず(アラート疲れ)、高くしすぎると異常を見逃します。運用しながら適切な値に調整していくことが大切です。

トリガー条件を満たしたときに何をするかを決めるのが通知アクション(Trigger Actions)です。代表的なものを挙げます。

これらは組み合わせて設定できます。たとえば「メールで担当者に通知しつつ、発報履歴にも残す」といった運用が一般的です。

アラートの設計や通知アクションの具体的な設定、ロール管理を含めた運用面は、本サイトの今後の章でより詳しく扱う予定です。本節では「定期実行 → 条件判定 → 通知」という全体の流れをつかんでおきましょう。