Splunk ITSIを使いこなす - パート2：アラートの基本

まずは現在地を確認しておきましょう。このブログ記事は、Splunk IT Service Intelligence (ITSI)のしきい値とアラートのベストプラクティスを紹介する全3回シリーズの第2回です。第1回では、KPIの作成としきい値の設定について詳しく説明しました。今回は、アラートの生成と検証について詳しく説明します。

アラート設定のベストプラクティス

ここでもKISS (Keep It Simple：シンプルに保つ)！

アラート設定は複雑になりがちなので、まずはシンプルに保つことが重要です。アラートが複雑になりすぎないようにするために避けるべきことを次に示します。

• 重要イベントの集計ポリシーを複雑にしない
• マルチKPIアラートに複数のKPIを含めない(最大でも2つにとどめる)
• 考え得るすべての状況に対してアラートを生成しようとしない
• アラートを階層化しない(ただちに対処すべきアラートと翌日に回してよいアラートを分けるなど)

これらの「避けるべきこと」を踏まえて、ここからは「すべきこと」を見ていきましょう。

重要なビジネスサービスの健全性スコアが「致命的」になったときにアラートを生成する

ITSIで、可能であればサブサービスを含めずに、組織にとって特に重要なサービスを厳選して、それらのサービス健全性スコアが「致命的」になったときに重要イベントを生成します。さらに、重要イベントの集計ポリシーを作成し、その重要イベントに基づいてアラートを生成します。

サービス内のKPIが「致命的」になったときにアラートを生成する

サービス内のKPIが「致命的」の状態になったときにアラートを生成することを検討します。この場合も、特定の重要なKPIが「致命的」になったときに重要イベントを生成して、重要イベントの集計ポリシーを作成し、その重要イベントに基づいてアラートを生成します。この条件では負担が大きすぎる場合は、マルチKPIアラートを使って、KPIが過去15分間に5回以上「致命的」になったときにのみ重要イベントを生成することもできます。

チームの要望に応じてサービスのアラートを生成する

アラート対応を担当するチームが特定の状態についてアラートを受け取りたいと希望した場合は、そのアラートの生成を検討します。アラートを柔軟に設定できるITSIと、マシンデータを監視するための独自の機能を備えたSplunkなら、他のツールで対応できない環境でもアラートを生成できます。ただし、あまり無茶な設定をすると誤検知の発生率が高まります。

設定したアラートを文書化する

重要なサービスごとに、設定したアラートを文書化することをお勧めします。ITSIでは、さまざまな設定、マルチKPIアラート、重要イベントの集計ポリシーの結果としてアラートが生成されるうえ、時間が経つにつれてこれらの条件が増えていくため、作成の経緯をたどることのできる文書が後で役立ちます。

文書には少なくとも次の項目を記載します。

• 目標とするアラートロジックの説明
• アラートを作成した当初の理由、アラートを必要としている人、アラートが必要だと考える理由
• アラートに関連付けられたマルチKPIアラートへの参照
• アラートに関連付けられた重要イベントの集計ポリシーへの参照

アラート検証のベストプラクティス

「検証モード」で実行する

前回説明したようにKPIのしきい値では設定をリアルタイムで検証できますが、アラートの設定はそれほど簡単に検証できません。そのため、検証期間を設けるのが最善策です。検証プロセスでは、生成されたアラートを30～90日間かけて運用し、夜中に担当者を呼び出すことになっても妥当だと思えるレベルまで設定の信頼度を高めます。過剰に発生する誤検知のアラートをさかのぼって調べ、どの設定に一番問題がありそうかを特定し、KPIのしきい値やアラートの設定を調整して、誤検知をできるだけ減らします。

ITSIのアラートチケット量を過去の平均と比較する

検証期間中に、ITSIで生成されるアラートの量を、これまで他のツールで生成されていた平均的なアラート量と比較して、監視担当者に過度な負担をかけることにならないかどうかを確認することをお勧めします。たとえば、これまでサービスの問題に関するチケットの発行数が1カ月あたり平均400件ほどの環境で、ITSIのアラートがたった1日で100件生成されれば、アラートの設定に問題がある可能性が高いため調整を検討します。また、他のシステムで問題が検出されるのと同じタイミングでITSIでもアラートが生成されるかどうかも検証します。もちろん、そのアラートが適切なものという前提で取り組みます。

アラート量が多いからといって必ずしも誤検知とは限らない

ITSIでは新しいタイプのメトリクスで監視を行いアラートを生成できるため、これまで監視できなかった問題を検知できます。そのため、サービスの監視を開始すると、潜在的な問題も高い確率で検出されます。潜在的な問題は、通常、KPIの重大度の計算に影響し、結果としてアラートにつながります。誤検知だと判断する前に、本当にサービスに問題がないかどうかをよく確認しましょう。  

まとめ

「パート2：アラートの基本」は以上です。常識的なことばかりだったかもしれませんが、重要なのはとにかくシンプルに保つことです。シンプルに始めて、運用が安定したら、ニーズに合わせて複雑な設定を徐々に導入し、ITSI環境を強化していきましょう。

次でこのシリーズのブログ記事は最後となります。ぜひ、「パート3：動的しきい値」もご覧ください。

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。