Splunk Observability Cloudのディテクター作成のベストプラクティス 🔗
Splunk Observability Cloudは、ディテクターを使用して、適切なチームメンバーにアラートまたは通知を送信するタイミングを決定する条件を設定します。ディテクターは、指定された条件および（オプションの）期間に照らしてメトリック時系列を評価します。条件が満たされると、ディテクターは重大度レベル付きのイベントを生成します。重大度レベルは、「情報」（Info）、「警告」（Warning）、「マイナー」（Minor）、「メジャー」（Major）、および「クリティカル」（Critical）です。これらのイベントは、PagerDutyなどのインシデント管理プラットフォーム、またはSlackや電子メールなどのメッセージングシステムで通知をトリガーできるアラートです。
静的閾値の使用 🔗
最も基本的な種類のアラートは、シンプルなメトリクスが静的閾値を超えたときに即座にトリガーされるものです。例えば、CPU使用率が70%を超えた時などです。測定する絶対的な目標がある場合は、固定した閾値を実装し解釈すると簡単です。例えば、特定のアプリケーションのCPUあたりの典型的なメモリプロファイルがわかっている場合、正常なステータスを定義するための境界を定義することができます。あるいは、特定時間内にリクエストを処理するというビジネス要件がある場合に、その機能にとって許容できない待ち時間を把握します。詳細は、静的閾値 を参照してください。
一貫したシグナルタイプ 🔗
ディテクターが適切に動作するためには、ディテクターが評価するシグナルは一貫したタイプの測定値を表すものである必要があります。例えば、Splunk Observability Cloudが cpu.utilization をレポートする場合、それは0から100の間の値であり、単一のLinuxインスタンスまたはホストの全CPUコアの平均使用率を表すものです。
ワイルドカードは使用しないでください。メトリクス名にワイルドカードを使用する場合は、そのワイルドカードによって異なるタイプのメトリクスが誤って含まれないようにしてください。たとえば、メトリクス名として jvm.* を入力した場合、ディテクターは同じ閾値に対して jvm.heap、jvm.uptime、jvm.cpu.load （それぞれ組織で使用されているメトリクス名であると仮定）を評価することができ、予期しない結果につながる可能性があります。
ネイティブのデータ解像度での表示 🔗
ディテクターを作成するための一般的で簡単な方法は、最初にチャートを作成し、アラートを発したいシグナルの動作を視覚化してから、それをディテクターに変換することです。この方法は、「 チャートからディテクターを作成する 」を参照してください。この方法を使用してディテクターを作成する場合、必ずデータをネイティブの解像度で視覚化してください。これを行うことで、ディテクターが評価するデータの最も正確な描画を取得できるからです。たとえば、10秒に1回レポートするメトリクスを使用してディテクターを作成する場合は、チャートの時間範囲が、10秒ごとの個々の測定値を表示するために十分に小さい（例：15分間）ことを確認してください。
デフォルトでは、Splunk Observability Cloudは選択された時間範囲に収まるチャート表示解像度を選択し、その解像度に合わせてデータを要約します。たとえば、10秒ごとにレポートするメトリクスを使用しているにもかかわらず、1日の時間窓で見るという場合、デフォルトでは、チャート上のデータは30分間隔で表示されます。ロールアップや要約の方法によっては、これではピークやディップが平均化されてしまう可能性があり、シグナルや適切なディテクター閾値に対する不正確な理解につながる可能性があります。また、分析パイプラインはロールアップされたデータに適用されるため、解像度が変わると計算の意味が変わる可能性があります。例えば、タイムシフトやデータの平滑化に使用できる継続期間パラメータは、解像度より小さければ効果がありません。
母集団全体にわたり単一のシグナルを監視するディテクターの作成 🔗
Splunk Observability Cloudは、特定のクラスタ内の全ホストのCPU使用率のように多数の類似した項目を監視するディテクターを定義するためのシンプルで簡潔な方法を提供します。これは、メトリック時系列に関連付けられたメタデータによって実現されるもので、これは、そのメタデータ（ディメンション、プロパティ、タグ）がチャートを作成する方法に似ています。
例を1つ見てみましょう。Kafkaのようなクラスタ化されたサービスを提供する30個のホストのグループがある場合、通常は service:kafka のようなディメンションが含まれ、そのメトリクスはすべてこれらのホストから来ます。この場合に、これらの各ホストのCPU使用率が70%未満にとどまっているかどうかを追跡したければ、 service:kafka ディメンションを使用しているホストをフィルタリングして cpu.utilization メトリクスを監視する単一のディテクターを作成し、70という静的閾値に対して評価を行います。このディテクターは、まるで別々の30個のディテクターを設定しているかのように、CPU使用率が閾値を超えた各ホストに対して個別のアラートをトリガーしますが、作成する必要があるのは30個ではなくたった1個のディテクターです。
さらに、母集団が変わった場合（例えば、クラスタの規模が40ホストに拡大した場合）でも、ディテクターに変更を加える必要がありません。新たに増えたホストから来るメトリクスについて service:kafka ディメンションを含めている限りは、既存のディテクターがそれらを見つけて自動で閾値評価の対象に含めます。
単一のシグナルを監視するディテクターは、母集団の全てのメンバーが同じ閾値を持ち、同じ通知ポリシーを持っている場合に、最もうまく機能します。例えば、同じSlackチャンネルにアラートを発行するような場合です。閾値や通知ポリシーが異なる場合は、複数のディテクター（閾値と通知の配列ごとに1つずつ）を作成するか、SignalFlowのconst関数を活用する必要があります。いずれにせよ、このようなディテクターの数は、それが監視する個々のメンバーの数よりもまだ少ない可能性が高いです。多数のアラートをトリガーするディテクターを蓄積しすぎないようにするためには、マイクロサービスではなくシグナルに対してディテクターを作成することが重要です。
母集団内のサブグループを監視するために集計を使用する 🔗
ディテクターを使用して、母集団内のサブグループを監視することもできます。例えば、合計100個のホストがあり、それらが10個のサービスに分かれているとします。これらの各サービスを提供するホストクラスタ全体のCPU使用率の95パーセンタイルが70%未満にとどまっていることを確認したいとします。この場合、cpu.utilization のディテクターを1つ作成し、P95の分析関数を適用して、service でグループ化します。この集計アプローチは、service がディメンションまたはプロパティである場合にのみ機能します。service がタグである場合、この集計アプローチは機能しません。
この集計ディテクターは、まるで10個の個別のディテクターを設定しているかのように各サービスに対してアラートをトリガーしますが、作成する必要があるのは10個でなく1個のディテクターだけです。サービスを追加した場合でも、その新しいサービスのメトリクスに service ディメンションまたはプロパティが含まれている限り、このディテクターは自動的にそれらのサービスを監視します。
また、「外れ値の検出」の内蔵アラート条件を使って、母集団の個々のメンバーを、母集団の標準からの偏差について、オプションでディメンションまたはプロパティをグループ化して、監視することができます。https://github.com/signalfx/signalflow-library/tree/master/library/signalfx/detectors/population_comparison で、GitHubのsignalflow-libraryにあるpopulation_comparisonディテクターについて参照してください。