そろそろサービスのKPIで動的しきい値を使用しても良い頃だとお考えであれば、ぜひこの記事をお読みください！
今回は、「Splunk ITSIを使いこなす」シリーズのパート1とパート2で学んだ基礎を活かして、動的しきい値のベストプラクティスを掘り下げます。動的しきい値を使用する場合でも、適切な設定を選択して有意義なしきい値とアラートを生成するには知識と経験の両方が必要です。
ぜひ以下のガイダンスをお役立てください。
重大度に対する認識を変える
設定に入る前に、KPIの重大度の定義と理解を改める必要があります。以前の回でご説明したとおり、Splunk IT Service Intelligence (ITSI)には、「標準(Normal)」、「致命的(Critical)」、「高(High)」、「中(Medium)」、「低(Low)」、「情報(Info)」の6種類の重大度が用意されています。
静的しきい値では、通常、これらの状態を「機能しているか機能していないか」の度合いと結び付け、機能が実際に停止している場合にのみKPIが致命的レベルになるよう適切なしきい値を設定します。しかし、動的しきい値は「機能しているか機能していないか」ではなく「正常か異常か」の度合いを表します。そのため、各状態を「致命的に高い」、「異常に高い」、「正常」、「異常に低い」、「致命的に低い」と解釈し直すことをお勧めします。
この違いは微妙ですが、非常に重要です。これが、動的しきい値を使用する場合のしきい値とアラート設定の基本な考え方になります。
使用すべきアルゴリズムの選定
このセクションでは説明を簡潔にするために、事前設定済みのしきい値テンプレートは使用しないものとします。また、テンプレートについては後ほどご説明します。ここでは、3つのアルゴリズムの特徴と、状況に合わせた選び方について説明します。各アルゴリズムの数学的処理については特別な点はなく、インターネットで数多くの解説が見つかるため、詳細は省きます。
ここでご紹介する各アルゴリズムの全体的な機能と実践的なメリット/デメリットを参考に、組織のニーズに最適なアルゴリズムを選択してください。KPIごとに、選択したアルゴリズムと学習期間分の履歴データを使って、今後のしきい値が毎晩計算し直されることを覚えておいてください。
分位数
分位数アルゴリズムでは、履歴データに基づいてさまざまなパーセンタイルにしきい値の境界を設定できます。たとえば、1パーセンタイル(0.01)を下回るデータポイントと99パーセンタイル(0.99)を上回るデータポイントに「致命的」の重大度を割り当てるなどです。パーセンタイルのしきい値は0～1の範囲で指定する必要があるため、履歴データの最小値を下回るしきい値と最大値を上回るしきい値が生成されることはありません。これは他の2つのアルゴリズムにはない特徴です。そのため、今後のデータが履歴データと同じように推移すると考えて分位数を使用すると、しきい値の境界をたびたび超えてしまう可能性があります。この点はアラーム戦略を立てるときに考慮する必要があります。このアルゴリズムのメリットとしては、わかりやすいことと、履歴データに極端な外れ値が含まれていても偏りを抑えられることが挙げられます。
標準偏差
標準偏差アルゴリズムでは、平均値からの標準偏差の倍数を使ってしきい値を指定できます。負の値からは平均以下のしきい値、正の値からは平均以上のしきい値が生成されます。このアルゴリズムは履歴データ内の外れ値に影響されやすく、しきい値が必要以上に大きくなる可能性があります。また、応答時間のKPIのように、大きい値や外れ値のみがあり、小さい値や外れ値がない場合など、データが偏っていると、下限の有意義なしきい値を生成するのが難しくなります。逆にデータが平均値を中心にほどよく分散している場合は、このアルゴリズムが最適です。また、データが偏っていても、偏っている方にのみ有意義なしきい値があればよい場合にも良い選択肢となります。
範囲
このアルゴリズムは分位数と似ているように思うかもしれませんが、まったく異なります。範囲アルゴリズムではまず、履歴データの最小データポイントと最大データポイント、およびその差(max – min)が調べられます。しきい値は、差に乗数を掛けて最小値を足すことで計算されます。つまり、乗数に0を指定するとしきい値が履歴データの最小値に設定され、1では最大値、-1では最小値–差、2では最大値+差に設定されます。
そのため、履歴データに外れ値が含まれると差が極端に大きくなり、それがしきい値に影響を及ぼします。履歴データの最小値と最大値を超えるしきい値を指定する必要があり、標準偏差では期待どおりの結果が得られない場合は、このアルゴリズムの使用を検討してみてください。
一様分布？外れ値？よくわからないけどデータを可視化したい！
正直なところ、私は統計が得意ではありません。思い返してみれば、大学時代、もっと楽しいことを求めて統計の授業をさぼったことは1度や2度ではありません。そのため、ITSIで「平均を中心とするデータの一様分布」とか「データ分布の非対称性」とか「外れ値」といった言葉に触れたとき、原理はそれなりに理解できても、しきい値への影響を可視化する方法はさっぱりわかりませんでした。やはりこの点で悩んでいる方のために、同じ思いをした私がサポートできればと思います。データの分布を可視化して外れ値を表示するには、比較的シンプルなSplunkサーチを作るだけで済みます。ただしそのためには、目的のKPIがすでに作成され、バックフィルされている必要があります。バックフィルを行うか数週間実行すれば、サーチを実行するために十分なitsi_summaryインデックスデータが集まります。もちろん、KPIに渡される生データに対して同様のサーチを実行することもできますが、ITSIでは夜間の計算でitsi_summaryインデックスデータが使われるため、ここでもそちらを使いたいと思います。ITSIで次のSplunkサーチを実行します。1行目には目的のKPIの名前を指定してください。適切にフィルタリングするにはKPIの正式名が必要です。わからない場合は、ITSIのサマリーインデックスを調べてください。
index=itsi_summary is_service_aggregate=1 kpi="<ここにKPIの名前を入力>"
| bin alert_value as bin_field
| stats max(alert_value) as sort_field count by bin_field
| sort sort_field
| fields - sort_field
| makecontinuous bin_field
このSPLを実行すると、次のようにデータが可視化されます。
サーチでは、binコマンドを使って、alert_valueの多数の結果を少数のグループにまとめています。また、makecontinuousコマンドを使って、外れ値を目立たせています。上の図は、外れ値がなく比較的均等に分布しているデータの表示結果です。必要に応じて、binコマンドにspanオプションを追加して、以下のようにより細かい単位でグラフ化することもできます。
上の図は、分布に偏りのあるデータの表示結果です。大きい外れ値が多数あるため、しきい値の計算に影響する可能性があります。
事前設定済みのしきい値テンプレートの使い方
意外に思うかもしれませんが、事前設定済みのしきい値テンプレートは当面は使わないことを強くお勧めします。テンプレートはただの提案であり、組織独自のニーズに合うとは限らないからです。むやみに使うと、プロセスがわからず、予期しない結果に悩まされることになりかねません。
それよりも、KPIの動的しきい値の設定プロセスを少なくとも1回はゼロから検証して、適切なしきい値が毎回どのように決まるのかを理解することをお勧めします。そうすれば、事前設定済みのしきい値テンプレートを使用するときにも、より効果の高いテンプレートを見極めることができます。
KPIの動的しきい値と時間ポリシーの作成
それではいよいよ、KPIのしきい値を設定していきましょう。ここでは、上記の説明に基づいて適切なアルゴリズムをすでに決めているものとします。もちろんその選択に縛られず、すべてのアルゴリズムを順に試していただいてもかまいません。いずれにせよ、各アルゴリズムの特徴と、組織のKPIデータセットに最適なアルゴリズムの選び方をあらかじめ確認してから、KPIのしきい値を設定してください。また、当初の学習期間は7日間に設定しますが、状況に応じて時間ポリシーを細かく指定するようになると、より短い時間範囲について十分なデータポイントを収集して有意義なしきい値を生成できるように、学習期間を14日、30日、60日と拡大していく必要が生じます。
ここでは、サンプルデータセットを使って設定を行い、そのスクリーンショットをお見せします。このKPIはWebサーバーへのログイン件数を示し、曜日と時間帯によって利用状況が変わります。
デフォルトのポリシー設定を作成するには、まず、動的しきい値アルゴリズムを選択し、その重大度パラメーターを組織の重大度の定義に合わせて設定します。ここでは、KPIに分位数アルゴリズムを使用し、「高」のしきい値を95%、「中」のしきい値を5%に設定します。動的しきい値の重大度で表現すれば、95%を超えると異常に高く、5%を下回ると異常に低い、ということになります。適用ボタンをクリックして、結果を確認しましょう。今はまだ期待どおりの結果にならなくても問題ありません。
実のところ、多くの人がこの時点で混乱し始めます。異常が多すぎるか、少なすぎるか、または表示されたグラフをどう解釈すべきかわからないためです。事前設定済みのテンプレートを使用した場合は特にそうなります。そして、パニック状態であちこちクリックして、なんとかグラフが正常に見えるようにします。これはあまり戦略的なアプローチとは言えませんよね？では正しい手順をご紹介しましょう。
1週間分のKPIのグラフを見てまず気づくのは、予想どおり、特定の曜日や時間帯の利用状況が他の曜日や時間帯と異なることです(上のスクリーンショットを参照)。たとえば午前中と午後、平日と週末で異なります。こうしたパターンは通常、説明可能であり、想定されることですが、念のためサービスオーナーに確認するのがベストです。
パターンが想定どおりであることを確認したら、次に、異なるパターンごとの時間ポリシーを作成します。この例では、週末にWebサーバーで処理するトラフィックはごくわずかです。そこでまず、時間ポリシーを新たに作成して週末と平日のトラフィックを分けましょう。新しい時間ポリシーを追加し、先ほどと同じ動的しきい値アルゴリズムと重大度の値を指定して、適用ボタンをクリックします。
ITSIのしきい値の計算にはこの時間ポリシー内の履歴データポイントのみが使われるため、週末のしきい値が妥当なものになっています。さて、改善できたでしょうか？
改善したのは確かですが、まだ問題があります。月曜日にトラフィックの急増があり、赤いゾーンに入っています。サービスチームに確認すると、平日の午前8時頃と午後5時頃にログインが集中するのは周知の事実とのことなので、これらの急増時間帯の時間ポリシーを作成しましょう。さらに、トラフィックが減る平日夜間の時間ポリシーも作成します。
その結果が上の図です。完璧なものにするには上記の手順を繰り返して適切な時間ポリシーをもう少し作成する必要があるかもしれませんが、上出来と言えるでしょう。体系的なアプローチを取り入れ、なによりも、各時間ポリシーの目的を明確にし、それに沿ってポリシーを作成することが重要です。
1時間単位で全168個の時間ポリシーを作成するのを避けるべき理由
上記の例で、なぜ各曜日の複数の時間帯のパターンや、複数の曜日のパターンをまとめて扱ったのでしょうか？各曜日、各時間のパターンは少しずつ異なるので、168個(24時間x週7日)分の時間ポリシーを作成すればよいのではないでしょうか？もちろん駄目だとは言いませんが、その方法にはさまざまなデメリットがあります。
まず、しきい値の計算に使われる履歴データが少なくなるため、大きな変動や外れ値が生じた場合に影響が大きくなります。また、問題をうっかり見落とす可能性もあります。アプリケーションに未確定の問題があり、予想されていてもKPIにまだ現れていない急変(CPU使用率やエラー数の急増など)がある場合、それに気づかず、サービスチームに確認し損ねる可能性があります。さらに、ポリシーが増えて管理の負担が増し、ITSIで夜間に計算されるしきい値が増えて負荷も必要以上に増します。
すべての時間ポリシーに動的しきい値を使う必要はない
時間ポリシーによっては、十分なデータがないと効果がありません。Webサイトへのログイン件数が良い例です。データが少ないと有意義な動的しきい値を生成できないためです。正確なしきい値を生成するためのデータを十分に確保できない場合は、静的しきい値の使用を前向きに検討しましょう。
アラートの設定
動的しきい値を使ってKPIのしきい値を設定できるようになったら、次に、KPIに異常があったときに実用的なアラートを生成するための適切なアラート設定について考える必要があります。
アラートを生成すべき状況としてまず思いつくのが、いずれかのKPIが「致命的」なレベルになったときと、複数のKPIが同時に「異常」なレベルになったときの2つです。ただし、使用するアルゴリズムやしきい値によっては、KPIが致命的なレベルであるか単に異常なレベルであるかを判断できない場合があることに注意が必要です。上記の例のように、分位数アルゴリズムを選択した場合は特に注意する必要があります。その際は、代替手段として、KPIの異常な状態が長く続いたときにアラートを生成することも検討しましょう。
複数のKPIの状態に基づいてアラートを生成するときは、サービスの健全性を特に明確に示すKPIを2つか3つ選び、その過半数またはすべてが異常なレベルになったときにアラートを生成することをお勧めします。1つ例を挙げると、ログファイルに記録されたエラー数のKPIと成功したログイン数のKPIの両方が異常なレベルになったときにアラートを生成すれば、サービスの問題の兆候をつかむために役立ちます。また、サービスを構成する重要な階層の中から複数の階層のKPIを選ぶのもよいでしょう。たとえば、Web層とサービス層の両方でエラー数が異常なレベルになった場合は、問題が発生している可能性が高くなります。
検出漏れと誤検知への対処
KPIが異常レベルになる頻度が想定をはるかに上回る、または下回る場合は、以下のことが考えられます。
- システムに実際に問題が発生しており、異常が検出されないようにしきい値の設定を見直す前に、十分に調査する必要がある
- 時間ポリシーの粒度が不十分で、週または時間単位で予測されるKPIの変化パターンに対応できていない
- しきい値の計算方法を正しく理解せずに、分位数アルゴリズムを使用している
- 異常を判定するためのしきい値の設定が厳しすぎるか緩すぎる
- 履歴データに予測不能なデータポイント、データの大きな偏り、または極端な外れ値が含まれ、しきい値の計算に悪影響を及ぼしている
- 学習期間が短いために、十分な履歴データを計算に使用できず、しきい値の精度が低い
- 最近の履歴データの値が将来の値を予測するのに適していない(この場合は、動的しきい値を使用しないことをお勧めします)
こういった問題の多くが、アラートの運用面でも通知漏れや誤報につながります。
よくある落とし穴
ITSIで効果的な動的しきい値を設定する際に陥りがちな落とし穴がいくつかあります。以下では、その落とし穴にはまらないようにする方法をご紹介します。
週のプレビューグラフですべてが正常な状態になっているが、実情はそんなはずはない
これはありがちな問題です。まずはっきりさせておきたいのは、動的しきい値を設定するときに作成される週のプレビューグラフでは各データポイントが30分単位で表示されることです。そのため、KPIを15分単位で計測している場合、グラフに表示されるデータポイントは、正確には2つのデータポイントの平均値ということになります。同様に、KPIを5分単位で計測している場合は、6つのデータの平均値です。正確な結果を得るために動的しきい値の計算がKPIの各データポイントに対して実行されたとしても、週のプレビューグラフでは外れ値が取り除かれて異常なレベルに届かず、実際の状態が反映されない場合があります。
KPIは絶対に負の値にならないのに、下限のしきい値が負の値になる
この問題は、標準偏差または範囲アルゴリズムを使用している場合に起こります。これらのアルゴリズムではしきい値の計算に減算が使われ、上限と下限の値に制限がありません。上限と下限の両方が重要で、負のしきい値が許容できない場合は、以下のいずれかを試してみてください。
- 分位数アルゴリズムに変更する。この場合、下限が履歴データの最小値を下回ることはありません
- 範囲アルゴリズムで、非常に小さい負の数を指定する。たとえば-0.05に設定すれば、しきい値が履歴データの最小値をわずかに下回る範囲に収まります
- 動的しきい値で学習した後、静的しきい値に切り替え、下限の静的しきい値を微調整する
しきい値を超えることがないような大きな値が設定される
これはおそらく、履歴データに極端な外れ値が含まれていることが原因です。唯一のシンプルな解決策は、学習期間を長くしてデータを増やすことです。それが難しい場合は、分位数アルゴリズムか静的しきい値に切り替える以外に良い方法はないでしょう。
事前設定済みの1時間単位の時間ポリシーを適用してみたが、期待どおりに動作しない
事前設定済みのテンプレートに含まれる毎日1時間単位の時間ポリシー(1-hour blocks every day)と平日の1時間単位の時間ポリシー(1-hour blocks workweek)では、曜日をまたがり各時間のデータがまとめられます。週7日24時間が個別に扱われると期待していた場合、それは間違いです。そのようなしきい値設定戦略に合った事前設定済みのテンプレートはありません。事前設定済みのテンプレートに含まれる1時間単位の時間ポリシーよりも細かい粒度でしきい値を設定したい場合は、独自のポリシーを作成する必要があります。
まとめ
このブログシリーズが皆様にとって洞察に満ち、価値が高く、なによりも実践的な情報源になっていてくれれば幸いです。ぜひこのブログを参考に実際に設定を行い、うまくいった点、うまくいかなかった点をお知らせください。皆様の貴重なご意見を参考に改善点を見つけ、Splunkのさらなる進化につなげていきたいと思います。私の連絡先またはブログのコメントから遠慮なくご意見、ご感想をお寄せください。
