Splunk APMのアラートを詳しく理解する

NoSample™による正確な分散トレーシングと制限のないカーディナリティ調査では、サンプリングでは見逃しまうアプリケーションパフォーマンスの低下も確実に捕らえることができます。そのため、遅延やエラーに関連する問題を実証する処理を記録すると、詳細に調査および分析できます。さらにトレースデータを活用して、エンドポイントの遅延率やエラー率のスパイクや異常値を特定することで、どの時点を詳細に調査すべきかを判断することもできます。これらすべてを可能にするのが、Splunk APMと、新たにリリースされたμAPMアラートです。

Splunk μAPMアラートでは、一般的な戦略に基づいて集計やトレンドに関するアラートを生成し、それをトリガーとして詳細な分析や調査を手動または自動で実行できます。この場合、集計はμAPMメトリクス(スパンごとの集計)として捕捉されます。このメトリクスは以前から、内蔵のグラフ作成機能やダッシュボード表示で可視化やトラブルシューティングに使用されてきました。Splunkの最高レベルのメトリクス監視/アラート生成プラットフォームを利用することで、μAPMディテクターおよびアラートをトラブルシューティングのワークフローの効率化にも役立てることができます。 

スパイクからトレースへ

このブログ記事では、μAPMアラートの内部構造と、それを支えるいくつかの統計原則について説明します。

オプションの概要

遅延アラートには、製品に応じて5つの基本オプションがあります。

• ベースラインとなるデータセットを選択する2つのオプション：最近の履歴(Sudden Change)、特定の時間枠の前のサイクル(Historical Anomaly)
• 異常値を測定する2つのオプション：ベースラインに対する変化の割合、標準偏差の大きさ
   

さらに、

• 遅延を静的なしきい値(ミリ秒単位)と比較するオプション
   

4つの動的なしきい値のうち定性的なオプションを除いて、アラートの感度は、ベースラインとの必然的な差異と時間枠の長さ(基礎となるプログラムで現れる期間)の影響を受けます。[Sudden Change]と[Historical Anomaly]のアラートは、インフラストラクチャー監視で使われる同名のアラートと性質が似ていますが、実装は多少異なります。次のセクションでその詳細を説明します。

エラーアラートには、2つの基本オプションがあります。

• 現在のエラー率を、直前の時間枠から計算されたベースラインのエラー率と比較する
• エラー率を静的なしきい値(%単位)と比較する
   

遅延とエラー率のいずれについても、μAPMの静的しきい値ディテクターではトリガーとクリアそれぞれのしきい値(および期間)に基づいて比較が行われるため、アラートの大量発生を防ぐことができます。これに対してインフラストラクチャーの静的しきい値ディテクターでは、SignalFlow APIを使用すればアラートのクリア条件を設定できますが、現在のところSignalFx UIからは設定できません。クリア条件を設定するメリットと、プロットビルダーで条件を構成する方法(SignalFlowのdetectブロックで「off」条件が受け入れられるため現在は不要)については、こちらを参照してください。重要なのは、シグナルがしきい値前後で推移した場合、区別のためのクリア条件を設定していれば、それが複数のインシデントではなく1つのインシデントとして扱われることです。

一部の統計の詳細

異常検出では、通常、分布が比較されます(直前の5分間の値と過去1時間の値を比較するなど)。ヒストグラムを利用できる場合、これは分位比較、つまり中心と広がり、多くの場合は中央値と四分位範囲(75パーセンタイルと25パーセンタイルの差で、IQRとも表記されます)によるロバスト統計を使用して行われます。

[Sudden Change]と[Historical Anomaly]の遅延アラートでは、「標準偏差」の定義が一般とは異なるため(インフラストラクチャー監視の条件で使用されるものとも異なります)、詳しい説明が必要でしょう。この場合の「偏差」は、遅延の分布の特性に合わせて、90パーセンタイルと50パーセンタイルの差を示します。

具体例として、トラフィックの多いある一般的なエンドポイントでの数時間の処理の分布について考えます。IQRは62msですが、中央値の前後の分布は非対称的で、75パーセンタイルが68ms、25パーセンタイルが6msです。さらに、このエンドポイントの90パーセンタイルは中央値よりも約2 IQR高い一方、正規分布では90パーセンタイルと中央値の差は1 IQR未満です。また、このエンドポイントの99パーセンタイルは中央値よりも約29 IQR高い一方、正規分布では99パーセンタイルと中央値の差は2 IQR未満です。

正の非対称分布は、遅延の分布ではかなり典型的です。分布の大部分は、比較的迅速で正常な処理で構成されます。そのため、低いパーセンタイルは凝集される一方、高いパーセンタイルはかなり広がります。このような非対称性があるため、中央値について対称な統計ではなく、右裾のデータに重点を置いた分布の散布度を表しています。

また、現在のP50が過去のP50よりも高いとき、その差が過去の(P90 - P50)を少しでも上回ると、現在のP50が過去のP90よりも大きくなることに注意してください。そのため、P50が(P90 - P50)からどのくらい離れたかに基づいてアラートを生成することは、現在のP50と過去のP90の比較(変化検出の分位比較手法)の自然な一般化と言えます。

ボリューム（リクエスト数）に関する条件

パーセンタイルの分析は、エンドポイントの健全性について重要な情報を示すものの、それは不完全であり、上記の計算のみに依存するとアラートにノイズが混ざりやすくなります。このため、μAPMディテクターでは、SignalFlowを利用して複合アラート条件(「AかつB」形式の条件でアラートをトリガーするなど)を設定できるようにし、アラートをトリガーするタイミングの基準として、エンドポイントが受信するトラフィックの量も簡単に条件に組み込めるようにしています。これにより、まばらなデータに基づくアラートを抑制できます。

遅延ディテクターでは、ボリュームパラメーターの1つに[Min. req/sec (absolute)]があります。このパラメーターでは、現在の時間枠でアラートをトリガーする最小リクエスト率(1秒あたりのリクエスト数)を指定します。デフォルト値の0は、ボリューム条件が無効であることを示します。このほかに[Min. req/sec (% of history)]もあります。このパラメーターでは、現在の時間枠でアラートをトリガーまたはクリアする最小リクエスト率を、過去のリクエスト率に対する割合で指定します。過去のリクエスト率は、ベースラインやしきい値の設定に使用するものと同じ時間枠を基準に計算されます(直前の時間枠、数週間前の同じ時間枠など)。静的しきい値ディテクターでは、過去の時間枠はトリガー期間の直前、5倍の長さに設定されます。

エラー率ディテクターでもリクエストボリュームの条件を設定できます。この条件を使用すれば、たとえばエンドポイントがほんの数件のリクエストを受信し、エラーが1つだけだった場合はアラートをトリガーしないように設定できます。

アラートパターンは他のシナリオにも適用できます(遅延に関するアプローチは、分布データやカウントデータを利用できるシナリオに広くに適用可能で、エラー率に関するアプローチは他の率を使用するシナリオにも適用できます)。ただし、インフラストラクチャー監視のアラートを強化する目的と比べて、その方法はかなり専門的になります。

中間計算

SignalFlowライブラリのapmモジュールは、μAPMアラート条件の下にあります。他のSignalFlowモジュールと同様に、apmには、状況を可視化したり他のアラート手法で利用したり(既に組み込まれた条件とカスタムしきい値を組み合わせるなど)する場合に便利ないくつかの中間計算が含まれます。たとえばerror_rate関数では、指定した一連の処理における指定した期間でのエラー率が計算されます。

ベースラインに基づくアラート状態

μAPMディテクターでは、インシデント状態でのデータの可視化を強化しています。次の図にその例を示します。

13:56から上昇している現在の遅延は紺色で示され、履歴に基づくベースライン(この例では過去の中央値)は水色で示され、しきい値(この例では履歴の中央値＋履歴の偏差5個分)は赤で示されています。また、従来どおり、塗りつぶされた三角形がインシデントの開始時点、空の三角形が終了時点を示します。履歴に基づくベースラインの表現が新しくなり(Infrastructureの内蔵の条件では性質が似た統計方法論をもとにした表現です)、コンテキストが増えたため、アラートを迅速に評価できます。

まとめ

SignalFxのリアルタイムストリーミング分析エンジンとNoSample™の正確な分散トレーシングを基盤とするSplunk APMアラートなら、すばやく問題を検出し、関連する処理トレースを特定できます。

このブログはこちらの英語ブログの翻訳です。