重要なアップデート：このブログ記事で取り上げるコンセプトは今でも有効ですが、ITSI Content Pack for Monitoring and Alertingがリリースされ、ここで説明するすべての機能が事前パッケージ形式で提供されるようになりました。このコンテンツパックの使い方については、コンテンツパックのドキュメント、またはこのコンテンツパックのリリースに関するブログをご確認ください。
私は以前、Splunk IT Service Intelligence (ITSI)のしきい値の基本とアラートのベストプラクティスに関するいくつかのブログ記事を書きました。これらの記事では、基本的な考え方に重点を置き、実装については解釈の余地を多く残していました。それに、私が経験を積み、方法論が進化すれば、私が提供するガイダンスも進化していきます。
そこでこのブログ記事では、より具体的な内容に踏み込み、すべてのサービスを対象にする組織レベルのアラートの設計方法について説明します。単一のサービスまたはKPIに基づくアラートを作成するのではなく、ITSI環境内のすべてのサービスとKPIに適用できる包括的な設計を目指します。パフォーマンス、メンテナンス性、柔軟性など、この設計のメリットをすぐに実感していただけると思います。
面白いことに、この設計は偶然にも、.conf18の講演「Say Goodbye to Your Big Alert Pipeline, and Say Hello to Your New Risk-Based Approach (大掛かりなアラートパイプラインに別れを告げて、リスクベースの新しいアプローチを向かえ入れる)」で説明した、一般的なリスクベースセキュリティ設計戦略を反映したものになりました。このブログで紹介する設計を取り入れる場合は、こちらの講演の録画もご覧になることをお勧めします。そのアプローチとここで紹介するアプローチを組み合わせて考えれば、アラートに関するさらに多くのアイデアが見つかるでしょう。
今後は、リスクベースのアプローチに沿ってガイダンスを改訂し、こちらのブログで紹介していく予定です。製品や方法論の進化とともに、設計の技術的な詳細も少しずつ、場合によっては劇的に変わるでしょう。いずれにしても、環境内で運用するサービス、KPI、アラートが確実に増えている場合、この戦略が正しい方向への第1歩であると感じたなら、アプローチの転換を検討すべきタイミングです。
設計の概要
アラートの設計には2つの主要なコンセプトがあります。詳細に入る前に、設計の概要とこれらのコンセプトを確認しておきましょう。
コンセプト1：サービス、KPI、エンティティの注視すべきすべての変化について「重要イベント」を生成します(実際には連鎖的に大量に生成されます)。そのために大きな役割を果たすのがカスタム相関ルールです。また、すべてのサービス、KPI、エンティティを評価する相関ルールを作成します。これにより、パフォーマンスとメンテナンス性を確保し、環境内で統一された戦略を構築できます。
コンセプト2：重要イベントに、グループ化とアラート生成のロジックに役立つ属性を適用します。この属性とは、itsi_tracked_alertsインデックスに保存されたフィールド/値ペアです。これを実現するために、ルックアップ、計算済みフィールド、相関サーチのevalステートメントなど、Splunkの一般的なコアコンセプトを使用します。適用した属性は、重要イベントの集計ポリシー、アラートアクションルール、エピソードレビューで利用できます。
まとめると次のようになります。まず、サービス、KPI、エンティティで発生した問題を検出する複数の相関サーチを作成します。問題が検出されると、重要イベントが生成されます。ノイズを削減するために、これらの重要イベントに各種の属性を適用し、それに基づいて集計ポリシーロジックで関連イベントをグループ化します。最後に、集計ポリシーでアラートアクションを設定して、適切なアラートルールに基づいてNOCへのアラートを生成します。
覚えておくべきインデックス
すべてのSplunkソリューションがそうであるように、ITSIでもデータのほとんどが複数の主要インデックスに保存され、設定や相関ルールで参照されます。ITSIで使われる主要インデックスとそこに保存されるデータの概要を以下に示します。
- itsi_summary：ITSIでKPIまたはサービスの健全性スコアサーチが実行されるたびに、値と重大度を含む結果情報がここに保存されます。
- itsi_tracked_alerts：ITSIで生成される重要イベントとそのすべての関連情報がここに保存されます。
- itsi_grouped_alerts：重要イベントの集計ポリシーによって1つ以上の重要イベントがグループ化されると、グループ情報(group_idとevent_id)がイベントとしてここに保存されます。
手順の概要
Splunkのマーケティングチームはブログを短くすることを望んでおり、確かにあまり長いと読むのも大変だと思うので、手順を5つのステップに分け、それぞれ別のブログで詳しく説明することにします。5つのステップすべてを終えれば、効果的なアプローチを実装し、必要に応じて変更や強化ができるようになります。5つのステップは以下のとおりです。
- サービスの健全性スコアが低下したときに重要イベントを生成する
- 重要イベントにalert_group属性を適用して、関連イベントをグループ化する
- その他の注意すべき変化を検出する追加の相関サーチを作成する
- alertable属性を使ってアラートルールを作成する
- 1エピソードに1回ずつアラートにスロットリングを適用する
テストの準備方法
この設計を実装して環境に変更を加えるときは、早い段階から何度もテストをしたいと思うでしょう。私が担当しているあるお客様が非常にシンプルで効果的な方法を実践しているのでお教えします。それは、テスト用のサービスを作成して、テスト用の1つ以上のKPIを設定するというものです。テストのためにサービスに障害を起こす必要があるときは、テスト用サービスを使ってしきい値を変更し、障害をシミュレーションすればよいのです。同様に、重要イベントの集計ポリシー(NEAP)を作成するときは、テスト用サービスからのイベントのみを対象としたテスト用のNEAPを作成します。こうすれば、非常に簡単に隔離環境を用意して変更をテストできます。
準備はできましたか？ではステップ1に進みましょう。
