静的閾値の使用

最も基本的な種類のアラートは、シンプルなメトリックが静的しきい値を超えるとすぐにトリガーされます。たとえば、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 使用率など、多数の類似項目を監視するディテクタをシンプルかつ簡潔に定義できます。これは、メトリック時系列に関連付けられたメタデータによって実現されます。これは、メタデータ（ディメンション、プロパティ、またはタグ）がチャートを作成する方法に似ています。

例を見てみましょう。たとえば、Kafka のようなクラスター化されたサービスを提供する 30 のホストのグループが 1 つある場合、通常はこれらのホストから来るすべてのメトリックと一緒に service:kafka といったディメンションが含まれます。この場合、これらの各ホストの CPU 使用率が 70% を下回っているかどうかを追跡するには、cpu.utilization メトリックに単一のディテクタを作成し、service:kafka ディメンションを使用してホストをフィルタリングし、静的しきい値 70 に基づいて評価します。このディテクタは、CPU 使用率がしきい値を超えるホストごとに、個別のアラートをトリガーします。30 の個別のディテクタがあるかのようですが、作成する必要があるのは 30 個ではなく 1 つのディテクタのみとなります。

さらに、クラスターのホストが 40 に増加するなどして数が変化した場合でも、ディテクタを変更する必要はありません。新たに増えたホストから来るメトリックについて service:kafka ディメンションを含めている限りは、既存のディテクタがそれらを見つけて自動でしきい値評価の対象に含めます。

単一のシグナルを監視するディテクタは、母集団のすべてのメンバーが同じしきい値と同じ通知ポリシーを持っている場合に最もよく機能します。たとえば、同じ Slack チャネルにアラートを出す場合があります。しきい値や通知ポリシーが異なる場合は、複数のディテクタ（しきい値と通知の順列ごとに 1 つ）を作成するか、SignalFlow で const 関数を使用する必要があります。いずれの場合も、そのようなディテクタの見込み数は、監視対象の個々のメンバーの数よりも少なくなります。多数のアラートをトリガーするディテクタが多くなるのを避けるために、マイクロサービスではなく、シグナルのディテクタを作成することが重要です。

母集団内のサブグループを監視するために集計を使用する

また、ディテクタを使用して、母集団内のサブグループを監視することもできます。たとえば、合計 100 個のホストが 10 個のサービスに分割されているとします。こうした各サービスを提供するホストのクラスター全体の CPU 使用率が 95% の時間、70% 未満になるようにします。この場合は、cpu.utilization の単一のディテクタを作成し、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 ディテクタを参照してください。