ディテクターをカスタマイズしてアラートの実用性をさらに高める方法

前回のブログ(英語)では、良くないアラートとはどのようなものであり、優れたアラートを生成するためにはディテクターをカスタマイズおよび調整することがいかに重要であるかについて説明しました。Splunk Observability Cloudで利用できるディテクターとして最初に紹介したのが、「AutoDetect」と呼ばれる、すぐに使えるディテクターです。このディテクターをカスタマイズして登録すれば、業界のベストプラクティスに基づいたアラートをすばやく起動して実行し、MTTx (平均xx時間)を効果的に短縮できます。 

組織によってテクノロジースタックは異なり、それによって優先順位や目標も変わります。また、どの環境も多様で複雑です。ビジネスにとって重要なイベントを詳細に監視するには、カスタマイズは避けられません。Splunk Observability Cloudのカスタムディテクターでは、データセットやディメンションを明示的に指定し、ストリーミングメトリクスの強力なリアルタイム処理エンジンやさまざまなカスタマイズオプションを活用できるため、ビジネスにとって有意義で実用性の高いアラートを作成し、ビジネスとテクノロジーを継続的に改善できます。

このブログでは、カスタムディテクターを作成し、適切なカスタマイズによって大量のアラートを有意義なインサイトに変える方法をご紹介します。無料のトライアル版から使い始める場合でも、この記事の例で使用するメトリクスを利用できます。ぜひお試しください。

カスタムディテクター

Splunk Observability Cloudでは、カスタムディテクターを作成して、任意のサービスやメトリクスに対してアラートの条件を詳細に指定することができます。複数のデータセットを対象にフィルターや関数を適用することもできるため、基本となるメトリクスに対するシンプルな条件だけでなく、複数のメトリクスと数学的な計算を組み合わせた複合的な条件も定義できます。データベースサーバーのディスク使用率に対してシンプルな静的しきい値を設定することも、スケーリングをプロアクティブに行うためにサービスの今後のサチュレーションを予測することも、複数のシステムをまたいでサービスの包括的な健全性スコアを判断するための複雑な数式を使用することも、カスタムディテクターなら可能です。 

カスタムディテクターの作成を開始するには、[Alerts & Detectors]ページの右上隅にある[+]アイコンをクリックしてから、[Custom Detector]を選択します。 

アラートシグナル

[New Alert Rule]画面が表示されたら、最初に監視するメトリクスを指定します。Splunk Observability Cloudでメトリクスとシグナルを操作するときは、「プロットライン」を使用し、データセットを定義して複数のデータセットを相関付けます。1つのプロットラインを使って特定のメトリクスとその関連ディメンションの独立したストリームを作成するだけでなく、複数のプロットラインを使って互いに評価を行い、新しい出力を計算することもできます。今回の例では、顧客側で発生しているサービスの遅延を監視し、それを前の週と比較して、ユーザーエクスペリエンスの低下を示す傾向が検出されたときにアラートを生成します。エンドユーザーから指摘される前に遅延に対処できれば、それに越したことはありません。まずは、サンプルのサービス遅延メトリクスを取得し、顧客ごとに集計して、週ごとの遅延の差を調べるための基本的な関数を実行します。 

ここで使うサンプルメトリクスは「demo.trans.latency」という名前で、異なる国の3社の顧客が複数のデータセンターで運用しているサービスの遅延をシミュレートします。このメトリクスに含まれるすべてのメタデータを使用し、メトリクスをディメンションで分割すると、データテーブルの図に示すように18のメトリクス時系列(MTS：Metrics Time Series)が抽出されます。MTSは、特定のメトリクスとその個々のディメンションすべてを構成する基本単位の行と考えてください。たとえば、テクノロジースタック全体の最大CPU使用率を集計すると、それが1つのMTSになります。しかし、インフラの特定の問題を検出および解決するには、これでは役に立ちません。代わりに、アベイラビリティゾーンごとに集計します。3つのゾーンでサービスをホストしている場合、MTSは3になります。しかし本当に知りたいのは、具体的にどのホストで問題が発生しているかです。その場合は、ホスト単位で集約します。すると、MTS数はホスト数と同じになり、たとえば100などになります。

^{demo.trans.latencyメトリクスをプロットラインAのシグナルとして入力します}

^{データテーブルにdemo.trans.latencyの18のMTSの個々の値が表示されています}

ここでは、サービスを運用するホスト、地域、データセンターごとではなく顧客ごとの遅延を知りたいため、demo_customerディメンションで最大の遅延を集計するための分析関数を[F(x)]列に追加します。ただちにデータ行の数が更新され、適用した分析集計がタイムチャートに反映されます。

^{demo.trans.latencyメトリクスにdemo_customerごとの最大の遅延を分析する関数を適用します}

このサービスは3社の顧客が利用しているため、更新されたデータテーブルには、ディテクターが評価した3つの行(3つのMTS)だけが結果として表示されます。

^{データテーブルにdemo_customerごとの最大の遅延の集計を示す3つのMTS(3行)が表示されています}

次に、遅延の差を比較するための基準となる、前の週の同時間帯における顧客ごとの最大の遅延を知る必要があります。これにより、顧客側でのサービス遅延状況を確認し、新機能のリリースや機能改善によって遅延が解消されたかどうかを確認することもできます。そのためにまず、先ほどのプロットラインを複製します。

^{プロットラインを複製してシグナルと分析関数の設定を新しいプロットラインにコピーします}

複製されたプロットライン(プロットラインB)には、同じメトリクスと分析設定が引き継がれます。この状態から、Timeshift分析関数を新たに追加し、移動幅を1週間に設定して、プロットラインBの日時を前の週の同時間帯にシフトします。

^{プロットラインBにTimeshift分析関数を追加して1週間に設定します}

これで、顧客ごとのサービス遅延について、リアルタイムの状況と過去の状況を同時に表示できました。ただし、エクスペリエンスの低下を把握するために必要なのは、この2つの差を示すメトリクスです。そこで次のプロットラインに、既存の2つのデータセット間で計算を行う式を追加します。 

^{次のプロットラインの[Enter Formula]を選択します}

プロットラインA (現在)の値からプロットラインB (前の週)の値を引く式「A-B」を追加して、2つのプロットラインの差を計算します。この差がマイナスであれば状況が良くなっていることを示し、プラスであれば前の週と比べて遅延が大きくなっていることを示します。式を入力したら、目のアイコンをオンにして、差を示す新しい計算メトリクスを、タイムチャートに表示するデータセットとして設定し、ベルのアイコンをオンにして、その値をアラートに使用するように設定します。また、新しいメトリクスを設定すると、Y軸の目盛りが小数単位に変わり、実際の遅延の数字ではなく、遅延の差だけが表示されます。

^{2つのプロットラインの差を計算する式を追加します}

アラート条件

メトリクスの計算を適切に設定したら、次にアラート条件を設定します。これにより、アラートシグナルコンポーネントで収集したメトリクスに適用する条件やしきい値を評価できます。アラート条件を使うことで、機械学習を手軽に利用して異常や逸脱を高い精度で検出できます。この例ではシンプルな静的しきい値(Static Threshold)を使用しますが、このプラットフォームで選択できるアラート条件にはさまざまな種類があります。

^{リストからディテクターのアラート条件を選択します}

アラート設定

[Static Threshold]を選択したら、そのしきい値を指定します。たとえば、しきい値を3に設定すると、各顧客のサービス遅延が前の週よりも3ミリ秒(ms)長くなった場合にアラートが生成されます。タイムチャートを見ると、しきい値を3ミリ秒に設定した場合、前日にこのアラートが有効であれば6万1,000件以上のアラートが発生していたことがわかります。これでは「アラートノイズ」どころの騒ぎではありません。チームが平穏に過ごし、メールサービスを逼迫させないためにも、さらなるカスタマイズが必要です。

^{カスタムしきい値を設定した結果、データセットのスパイクによりシミュレーションアラートが大量に発生しました}

この例のデータセットにはスパイクが多く含まれ、ピークでしきい値を超えてはまた3ミリ秒以下に戻るという動きが繰り返されています。ここでは、こうした高解像度での挙動は気にせず、遅延の全体的な傾向を把握することに重点を置いて、チームにとってより有意義で実用的なアラートになるようにカスタマイズします。そのためのお勧めの方法の1つが、トリガーの感度を変更することです。しきい値を超過したら即座にアラートするのではなく、遅延が前の週を上回る状態がある程度続いたらアラートするように設定します。

^{スパイクの多いデータでは傾向を重視するように[Trigger Sensitivity]をカスタマイズします}

今回は、遅延がしきい値を超えた時間が5分間の半分(50%)以上になった場合にのみ、アラートを生成するように指定します。スパイクの多いデータセットで傾向を重視するようにしきい値をカスタマイズしたことで、前日のシミュレーションアラートの数が6万1,000件以上から1件に激減しました。カスタマイズによって、「使えない」ディテクターが、チームにとって価値あるディテクターに変身したのです。

^{感度を特定期間に設定してシミュレーションアラートの数を抑制します}

アラートメッセージ

このステージでは、誤検知、検出漏れ、アラートノイズに対応します。Splunk Observability Cloudでは、アラートメッセージをカスタマイズすることで、生成されるアラートにコンテキストを追加し、アクションにつなげることもできます。デフォルトのアラートメッセージにいくつかの変更を加えて、実用性を高めることができます。まず、このアラートはサービスの全面的な障害ではなく懸念される傾向を知らせるものであるため、重大度を[Critical]から[Warning]に変更します。次に、アラートメッセージの本文をカスタマイズします。プレビューには、日時、アラートの条件、アラート生成の原因となった値など、いくつかの重要な情報が含まれますが、トラブルシューティングをすばやく効果的に開始するために極めて重要な情報が欠けています。顧客ごとの遅延を監視しているこの状況では、遅延が発生した顧客の名前をアラートに含めることが、後の詳細な調査のために欠かせません。Splunk Observability Cloudならこの情報を簡単に追加できます。詳細を追加するには、[Customize]をクリックします。

^{重大度を設定し、アラートメッセージのカスタマイズパネルを開きます}

アラートメッセージのカスタマイズパネルで、設定したシグナルに含まれる任意のディメンションをアラートメッセージに追加できます。さまざまなカスタマイズオプションが用意されており、条件文やURL、画像をアラートメッセージに埋め込むこともできます。ここでは単に、メッセージの本文と件名に含める変数として「{{dimensions.demo_customer}}」を指定します。これだけの変更でアラートの実用性が大いに向上します。

^{主要なメタデータの値を取得する変数を使ってアラートのメッセージと件名をカスタマイズします}

アラートの受信者

ついに最後のステップです。生成されたアラートを必要な人だけに送信するようにします。たとえば人事部は、サービスの遅延状況が悪化しているという知らせを必要としているでしょうか？それはまずないでしょう。受信者パネルでは、生成されたアラートの送信先を指定できます。このビューの受信者オプションには、設定済みの通知サービスが含まれます。ここでは通知先として「my Team」だけを追加して、設定完了です！ 

^{生成されたアラートの受信者をカスタマイズして、1つのチームにのみアラートを送信します}

Splunk Observability Cloudで強力なディテクターを作成する方法はほかにもまだたくさんあります。詳細については、今後のブログ、アラートとディテクターに関するドキュメント、Splunkトレーニングポータルをご覧ください。ここで紹介した手順をトライアル版で試し、さらにレベルアップする準備ができたら、SignalFlowやTerraform、その他の利用可能なプラットフォームAPIを使い、プログラミング、自動化、テンプレートを活用してディテクターを作成および管理する方法に挑戦してみてください。

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