新しいSplunk IT Service Intelligence (ITSI)のライセンスを手に入れたら、すぐにでも使ってみたいですよね。でも、初めてのサービス作成から有意義で信頼できるアラートの生成までの道のりを着実に歩むには、ちょっとした注意と十分な計画が必要です。このブログでは、その実践に向けたガイダンスを複数回に分けてご紹介します。最初はもちろん、基本からです。
ITSIのKPI/サービス階層
サービスの問題を有意義なアラートにつなげる方法を理解するために、KPIとサービスの階層を簡単におさらいしておきましょう。この知識はアラートの設定時にも必要になるので、基本として身に付けておくことが大切です。ITSIサービスは次のように設計されています。
- ITSIサービス
- サービス健全性スコア
- KPI (オプション)
- 依存サービス(オプション。「サブサービス」とも呼ばれます)
各サービスには常に健全性スコアが設定され、健全性スコアは、サービスに定義されたKPIとサブサービスの状態に基づいて計算されます。KPIはオプションで、定義する場合はしきい値を設定する必要があります。依存サービスもオプションで、実体は、このサービスが依存する他の設定済みのITSIサービスへの参照です。
用語の整理
しきい値とアラート
まずは、しきい値とアラートの違いを理解しておきましょう。ITSIでは、この2つは関連していますが異なる概念です。しきい値はKPIにのみ適用され、「状態」とも呼ばれるKPIの重大度が「標準」から「致命的」、「高」、「低」などに変わる基準を示します。KPIの重大度はサービスアナライザーダッシュボードやディープダイブなどの画面に表示されますが、それ自体はアラートを生成しません。
アラートは、明示的な設定に従って、KPIの重大度やサービスの健全性スコアが変化したときに生成されます。アラートの設定については後の回で詳しく説明しますが、今のところは、しきい値とは異なる概念であることだけを理解してください。
アラートと重要イベント
小うるさいことを言うようで恐縮ですが、そもそもアラートとは何でしょうか？メール？テキストメッセージ？チケットシステムに送るチケット？それともNOCの警告灯の赤い点滅でしょうか？意外と定義が難しいものです。ITSIでは、2層のアプローチでアラートが生成されます。まず、重要イベントが作成され、次に、それに基づいて1つ以上の一般的なアラートが生成されます。KPIの状態やサービスの健全性スコアを継続的に監視するようにITSIを設定すると、問題や懸念が検出されたときに重要イベントが作成されます。
重要イベントは、少なくとも一般的な意味でのアラートとは異なり、重要イベントレビューダッシュボードに表示される、注意が必要な単なるイベントです。設定の最終段階で、重要イベントの集計ポリシーを使って1つ以上の重要イベントから、メールやチケットなどの一般的なアラートを生成するように明示的に指定します。以上のプロセスをまとめると次のようになります。
最重要事項：エンティティの適切なグループ分け
サービスに含めるエンティティの選択は、各KPIの集計とエンティティごとの結果に直接影響します。そのため、しきい値とアラートの精度を高めるには、適切なエンティティを1つのサービスにまとめることが重要です。一般的には、動作パターンが似ているエンティティを1つのサービスにまとめます。当然、異なるエンティティはそれぞれ独自のサブサービスに分けます。適切な分類方法を例で説明しましょう。
- 2つの異なるデータセンターで運用されるエンティティ：通常、データセンター固有のサブサービスに分けます
- バッチサーバーや特定の処理専用サーバー：通常、汎用サーバーとは別のサービスにそれぞれ分けます
- 異なるアーキテクチャ層(DB、Web、アプリケーションなど)に属すエンティティ：別々のサービスに分けます
なぜこのように分けるのでしょうか？バッチサーバーの例で考えてみましょう。重要なビジネスアプリケーションを支える20台のアプリケーションサーバーをSplunk ITSIで監視しているとします。そのうち3台は、夜間バッチジョブの処理専用に使用しています。もし20台のサーバーを1つのサービスのエンティティとして定義してしまうと、バッチサーバーは他のサーバーと動作パターンが大きく異なるため、平均CPU使用率などのKPIの集計がほとんど無意味になります。そのため、適切なしきい値の設定も難しくなります。さらに、エンティティごとのしきい値や異常検出の利用時にも正確さが失われます。この場合は、3台のバッチサーバーをサブサービスとして分け、残りの17台を1つのサービスにまとめるのが妥当です。
KISS (Keep It Simple：シンプルに保つ)
本題であるしきい値とアラートの設定方法に入る前に、「シンプルに保つ」という原則を覚えておいてください。KPIが多すぎたりアラートポリシーが複雑すぎたりすると、いずれ収拾がつかなくなります。そのことを念頭に、少なくとも最初のうちは、以下のガイダンスも概ねシンプルにまとめています。
KPIとしきい値のベストプラクティス
組織で使う重大度を決める
ITSIでは、「標準(Normal)」、「致命的(Critical)」、「高(High)」、「中(Medium)」、「低(Low)」、「情報(Info)」の6種類の重大度を定義できますが、必ずしもすべてを使う必要はありません。むしろ、シンプルに保つには、利用する種類をできるだけ限定することをお勧めします。まずは「標準」と「致命的」だけを使うのも良いでしょう。
重大度の定義の一貫性を保つ
「高」と「致命的」の違いとは？といった点を明確にして、組織全体でその定義に基づいてすべてのKPIのしきい値を定めることが大切です。そうすれば、アラート生成や修復プロセスのルールの一貫性を高め、長期的にも、特に将来ITSIインスタンスを拡大すると想定したときに、保守が容易になります。また、グラステーブルやサービスアナライザーの監視担当者がサービスやKPIごとに重大度の基準を思い出す必要がなくなり、精神的に負担が軽くなります。
この問題は繊細で、すぐにいつの間にか一貫性が失われるので注意してください。特に注意が必要なのが、複数のチームがそれぞれKPIのしきい値を設定する場合と、Splunk ITSIモジュールのKPIや事前設定済みの時間ポリシーを使用する場合です。前者の場合は、各重大度の解釈がチームによって異なる可能性があり、後者の場合は、あらかじめ定義されたしきい値が組織全体の重大度の定義と一致しない可能性があります。
各重大度を定義する際の基準を次に示します。もちろんこれは例であり、必ずしもこの定義に従う必要はありません。
- 致命的：完全に予想外で、アラートがただちに必要な状態
- 高：正常と考えられる範囲は超えているが、アラートを出すほどではない状態
しきい値を設定するKPIを限定する
すべての結果に「情報」の重大度を割り当てることにより、KPIに無駄にしきい値を設定するのを避けることができます。この場合、ITSIにKPIは表示されますが(特にディープダイブで便利です)、サービス健全性スコアの計算には反映されません。この方法は、他の監視ツールからKPIを監視するときに、KPIの値が問題の発生を直接示すわけではない場合や、KPIの結果が安定していない場合、または適切なしきい値がわからない場合に特に役立ちます。
エンティティごとのしきい値と集計を使い分ける
エンティティごとのしきい値は便利そうですが、集計よりも複雑です。そのため、初めのうちは集計のしきい値のみを使用することをお勧めします。エンティティごとのしきい値を使わないことのマイナス点は、単一のエンティティのKPIがしきい値を超えても、他の複数のエンティティの値に相殺されて気づけない可能性があることです。この問題については、ITSI環境が安定し、運用が軌道に乗って、対応が明らかに必要になった時点で解決策を考えましょう。その頃になれば、エンティティごとのしきい値を設定する方法、異常検出を利用する方法、または動作をエンティティ別に追跡する別のKPIを追加する方法を検討できます。
静的しきい値と動的しきい値を使い分ける
動的しきい値はたしかに優れものです。しかし、そればかりに気を取られるとKPIの本質を見失ってしまいます。動的しきい値を活用するには体系的なアプローチが必要で、しきい値やアラートとはやや異なる考え方が求められます。むやみに動的しきい値を有効にして、事前定義されたしきい値ポリシーを漫然と受け入れることは、失敗のもとです。
動的しきい値の使い方について詳しくは、このブログシリーズの次の記事でご紹介します。KISSの精神に従えば、まずは静的しきい値を使うことに集中し、動的しきい値はITSIに慣れてその必要性が明確になった時点で導入することをお勧めします。
時間のポリシーとKPIしきい値のテンプレートを活用する
KPIのしきい値設定に関する強力な機能の1つが、1時間や1日単位で異なるしきい値を柔軟に設定できることです。このポリシーを使えば、KPIに最も効果的なしきい値アルゴリズムと値を、組織のニーズに合わせて詳細に調整できます。たとえば、あるKPIの適切なしきい値が平日の午前8時から午後5時までと週末とで大きく異なる場合は、それぞれの時間ポリシーを作成して異なるしきい値を適用できます。
ここでもシンプルに保つことを忘れないでください。時間ポリシーの数は、組織とサービスの大半をカバーできる範囲で最小限に抑えるようにしましょう。また、週単位で作成する期間の総数もできるだけ少なくしてください。1週間は168時間あり、もし各曜日について1時間単位で異なる設定を指定するとしたら、それだけたくさんのしきい値を管理しなければならなくなります。
大いに役立つ静的しきい値
こう言うと冷ややかな目を向けられるかも知れませんが、実際のところ、静的しきい値はなかなか優秀です。極めてわかりやすく設定も容易で、多くの場合、過去の経験から適切なしきい値は概ね検討がつきます。この点と、時間ポリシーを使って時間や曜日ごとに異なるしきい値を設定できる点を合わせれば、静的しきい値はKISSの原則にぴったりと当てはまります。
適切な静的しきい値を知るために動的しきい値を使う
まだ静的しきい値の活用法が見出せない方にも、受け入れてもらえそうな使い方があります。それは、多くの人が気づいていないかもしれませんが、ITSIで動的しきい値を使ってKPIの適切なしきい値を特定することです。適切な値が見つかったら、静的しきい値に反映して、必要に応じて調整します。これにより、動的しきい値を常時使う場合のいくつかの落とし穴を回避するとともに、機械学習に基づく最適な初期しきい値を手に入れることができます。
しきい値設定の検証と調整のベストプラクティス
さて、サービスを構築してKPIのしきい値をとりあえず設定したとしましょう。本番環境に展開するには、まずサニティーチェックを行わなければなりません。そのガイドラインをいくつかご紹介します。
お気づきかもしれませんが、アラートについてはまだお話ししていません。ここで少し考えてみましょう。たとえば、KPIが「致命的」の状態になったらただちにアラートを生成するように決めたとします。このとき、あるKPIで「致命的」の状態が全監視時間の75%を占めた場合、そのしきい値の設定は間違っていた可能性があります。
ディープダイブでのしきい値検証
ディープダイブでは、KPIについて算出された重大度を確認することも、KPIが定義およびバックフィルされた期間であれば時間をさかのぼって状態を調査することもできます。その大きなメリットは、しきい値を調整した後にディープダイブの表示を更新すると、すぐに新しいしきい値設定の結果が表示されることです。
この方法を各KPIで試すことで、しきい値の結果を必要なだけ入念に検証できます。ここでは、組織レベルで定義した重大度の状態と一致しているかどうかを確認します。もし真夜中にKPIが「致命的」の状態になってアラートで叩き起こされるようなことが何度もある場合は、「致命的」とみなす基準が緩すぎないかどうかを検証することをお勧めします。
ディープダイブを理解する
誰もがどこかの時点で、ディープダイブに表示される情報に惑わされることになります。KPIが5分または15分単位で計測されることを思い出してください。つまり、時間とともに大量のデータポイントが生成されるということです。実は、データポイントがあまりに多いと、ディープダイブで表示する期間を広げたときに、KPIの結果がより大きな時間単位で集計されて表示されます。
下の図を見れば一目瞭然です。2つのグラフはいずれも、5分間隔で計測されたKPIの24時間のデータを示しますが、一方が実際の数のデータポイントを表しているのに対して、ディープダイブのグラフではデータが要約されています。ご覧のとおり、ディープダイブでは表示期間を長くするとデータが要約され、グラフの起伏がなだらかになってしまいます。データが要約されたときは、画面上部にあるKPI計算メトリクスセレクターを使って、その時間範囲での要約の表示方法を柔軟に変更できます。
このように、KPIのしきい値を検証するときは、表示する時間範囲を狭くして結果の履歴を高い精度で表示することも、検証するしきい値に合わせて履歴データの外れ値が最適に表示されるようにKPI集計メトリクスを調整することもできます。
最近のインシデントと照らし合わせる
ディープダイブでKPIを検証するときは、サービスに関する最近のインシデントを参照したいでしょう。右上のタイムピッカーを使えば、インシデントが最初に発生した時点に戻ることができます。たとえば、最近システムに問題が発生してユーザーがログインできなくなった場合、その時点からログインのKPIが「高」または「致命的」になっていること、またはその周辺で他の関連KPIが「致命的」になっていることを確認できます。
もしすべてが正常であったり、重大度がアラートレベルに達していない場合は、しきい値が緩すぎるか、前述のディープダイブの表示に問題がある可能性があります。
Splunk ITSIをもっと詳しく説明していますので、ぜひこのブログの続き「パート2：アラートの基本」と「パート3：動的しきい値」もご覧ください。
