「Splunk ITSIアラートの設計 - ステップ2」に続いて、今回のステップ3では、環境内の注視すべき問題を検出する追加の相関ルールをいくつか作成します。念のためもう一度申し上げますが、現時点ではまだ、相関ルールに基づいてアラートを生成することはしません。ここでは健全性に関する追加のコンテキストを「重要イベント」という形で提供するだけです。後でこれを有益なアラートを生成するために使用します。
マクロによるitsi_summaryからitsi_tracked_alertsへのフィールドマッピング
お気づきかもしれませんが、「Splunk ITSIアラートの設計 - ステップ1」で作成した相関ルールでは、rename、lookup、evalコマンドを使ってフィールドマッピングのロジックを取り入れていました。itsi_summaryインデックスとitsi_tracked_alertsインデックスには、kpiidのように、同じ内容でも名前が異なるフィールドがあります。そのため、結果に含まれる適切なフィールド値をitsi_tracked_alertsインデックスに保存するにはマッピングが必要です。
ステップ1のブログで行ったように、マッピングは相関サーチ内にインラインで追加できます。または、マッピングのSPLを含む新しいマクロを定義して、これから作成する新しい相関サーチすべてに追加することもできます。どちらでもかまいませんが、このブログではマクロを使う方法を紹介します。
サーチの時間範囲に関する重要な注意事項
以下のサーチの多くは、itsi_summaryインデックスに書き込まれた直近の結果を参照するように設計されていますが、適切な時間範囲は必ずしも明確ではありません。itsi_summaryインデックスの_timeフィールドは、KPIの頻度と監視のタイムラグを考慮して(意図的に)少し前の時間に設定します。適切な時間範囲は1分、5分、15分、30分、またはそれ以上でしょうか。結論から言えば、約16分間前までさかのぼって調べ、kpiidに基づいてサーチ結果を重複排除するのがお勧めです。16分前まで調べれば、15分ごとにしか実行しないようにスケジュールされたKPIでも相関サーチで確実に収集できます。追加の1分は、監視のデフォルトのタイムラグである30秒を想定しています。kpiidに基づいて重複排除すれば、そのKPIでitsi_summaryの結果が複数返された場合でも、最新の結果を調べることができます。
この動作を理解するために、サーチ画面で少し実験してみることをお勧めします。時間範囲が短すぎると、itsi_summaryインデックスに書き込まれた結果をいくつか見逃して、重要イベントを生成し損ねる可能性があります。また、十分に重複排除ができないと、同じ結果が何度も表示され、重要イベントが重複することになります。
集計KPIの低下
サービスの健全性スコアが低下したときに重要イベントを生成するのと同様に、KPIが低下したときにも重要イベントを生成できます。次の相関サーチでは、すべてのKPIを調べて、重大度が「高」または「重大」のKPIについて重要イベントを生成します。
index=itsi_summary is_service_aggregate=1 is_service_max_severity_event=0
| dedup serviceid, kpiid
| search alert_level > 4 | ` acme_itsi_summary_to_itsi_tracked_alerts_field_mapping`
エンティティごとのKPIの低下
一部のKPIでエンティティごとのしきい値を使用している場合は、KPI内のエンティティのパフォーマンスが低下し始めたときに重要イベントを生成することもできます。次の相関サーチでは、エンティティごとのKPI値をすべて調べて、重大度が「高」または「重大」のエンティティがあれば重要イベントを生成します。
index=itsi_summary is_service_aggregate=0 is_service_max_severity_event=0
| dedup serviceid, kpiid, entity_key
| search alert_level > 4
| ` acme_itsi_summary_to_itsi_tracked_alerts_field_mapping`
持続的なサービス低下
サービスが健全な状態と不健全な状態を交互に繰り返すことがあるかもしれません。この状態はアラートするほどの問題ではないかもしれませんが、不健全な状態が長期間続く場合はアラートすべきでしょう。次の相関サーチでは、すべてのサービスを調べて、最近の結果の80%以上が不健全な状態になっているサービスがあれば重要イベントを生成します。このサーチでは、スキャンする時間範囲を過去5分間、15分間、60分間など、必要な長さに設定してください。適切な長さがわからない場合は、まず過去15分間で試してみることをお勧めします。
index=itsi_summary kpiid="SHKPI-*"
| eventstats count(eval(alert_level>2)) as unhealthy_count count as total_count by serviceid
| eval perc_unhealthy = unhealthy_count / total_count
| dedup serviceid
| search perc_unhealthy > 0.8
| ` acme_itsi_summary_to_itsi_tracked_alerts_field_mapping`
サービスの複数のKPIの低下
マルチKPIアラートと同様に、サービスで1つではなく複数のKPIが低下したときにアラートするのが有意義な場合もあります。次の相関サーチでは、すべてのKPIを調べて、3つ以上のKPIが不健全な状態になっているサービスがあれば重要イベントを生成します。
index=itsi_summary kpiid!="SHKPI-*" alert_level>2
| dedup serviceid, kpiid
| eventstats dc(kpiid) as num_degraded_kpis by serviceid
| dedup serviceid
| search num_degraded_kpis > 2
| ` acme_itsi_summary_to_itsi_tracked_alerts_field_mapping`
KPIの結果の異常
この機能はすでに用意されているので、少し楽ができます。Splunk IT Service Intelligenceでは、異常検出アルゴリズムを使って各KPIで異常が検出されるたびに重要イベントを自動的に生成できます。設定は、使いたい自動検出アルゴリズムを有効にするだけです。
その他の検出
上記の具体例を参考に、ほかにどのような検出が可能か、その相関サーチはどのようになるか、ぜひ考えてみてください。きっと多くの可能性があると思います。
その他のサーチを検討する前に、ヒントをいくつか紹介します。まず、itsi_summaryの最近の結果だけでなく過去の結果も調べると役に立つことがあります。持続的なサービス低下のサーチはまさにその例です。また、itsi_summaryインデックスを調べるだけでなく、itsi_tracked_alertsインデックスで異常なアクティビティを検出して重要イベントを生成することもできます。検討できるその他の検出を以下に示します。
- 持続的なKPI低下：持続的なサービス低下と同様のサーチで、KPIの結果を調べます。
- 複数のエンティティのパフォーマンス低下：サービスの複数のKPIの低下と同様のサーチで、KPIの複数のエンティティでのパフォーマンス低下を検出します。
- 重要イベントが複数発生しているエンティティ：すべてのサービスのエンティティごとのKPIをすべて調べて、複数の原因で不健全な状態になっているエンティティを検出します。
- alert_group内の複数の問題：alert_group内の複数のサービスが関わる重要イベントを検出します。このようなイベントは、サービスが複数の階層で低下している可能性があることを示しています。
まとめ
検出には大きな可能性があり、どのような形のサービス低下であっても検出方法があることをおわかりいただけたと思います。重要なのは、相関ルールや重要イベントをただ大量に作成することではなく、正確かつ詳細に問題を検出するためにはどのようなタイプの重要イベントを生成すべきかを考えることです。あともう少しで、すべての重要イベントを実用的なアラートにつなげることができます。次のブログでその方法をご紹介します。
面白くなってきましたね。ステップ4に進みましょう。
