Splunk Observability Cloudのディテクターのトラブルシューティング 🔗
detector は、チャート上と同様に、プロットライン上のシグナルを監視し、ルールで定義した条件に基づいてアラートイベントや解除イベントをトリガーします。
ディテクターにアクセスするには、「アラート」メニューから Alerts > Detectors に移動するか、アラートポップアウトウィンドウから Open Detector を選択します。
ディテクターのトラブルシューティング方法については、以下のセクションを参照してください：
一般的なディテクターの問題のトラブルシューティング 🔗
ディテクターが期待した条件下でアラートを発しない場合は、ディテクターを開き、以下のトラブルシューティン グ手順を実行します：
ディテクターが非周期的なデータに十分に対応できるほど堅牢かどうかを判断します。例えば、イベントが定期的かつ予測可能な周期で生成される可能性がない場合に送信されるメトリクスなどです。
ディテクターの Alert Rules、Signal、および Options のタブを確認します。ディテクターのルールが正しいと思われる場合、データが指定された時間窓外で到着するほどに遅延しているか、ディテクターが作成された後に入力データの解像度が変更された可能性があります。
ディテクターの Detail View でレポートされている解像度とシグナルを比較します。シグナルと「詳細ビュー」の解像度が一致していない場合、2つの方法で表示されます：
「詳細ビュー」の解像度がシグナルの解像度よりも粗い場合は、レポート間隔が変更され、データの信頼性が低すぎてアラートイベントをトリガーできないためにディテクターが発動しなくなっている可能性があります。
「詳細ビュー」の解像度がシグナルの解像度よりも密な場合は、ロールアップされたデータが、評価される基準の矛盾を引き起こしている可能性があります。
タイムスタンプの問題のトラブルシューティング 🔗
予想されたアラートがトリガーしないという問題ではなく、遅延したデータによって不当なアラートがトリガーするという逆の問題が発生することがあります。ディテクターに表示されるデータがアラートメッセージに表示されるチャートプレビューと一致しない場合、ディテクターの実行中にデータが遅延または欠落したためにデータが利用できなくなっている可能性があります。
次の例では、タイムスタンプに関連する問題を回避する方法を説明します：
ディテクターが、メトリクスが5分間にわたって50を超えたときにアラートをトリガーするように設定されていて、データが1分に1回届くという場合、タイムスタンプの不一致が生じる可能性があります。次の表は、一部のメトリクスデータポイントが数分遅れて到着する様子を示しています：
値 |
メトリクスのタイムスタンプ |
メトリクスが実際に到着した時間 |
|---|---|---|
30 |
11:07 |
11:07 |
55 |
11:08 |
11:08 |
40 |
11:09 |
11:15 |
30 |
11:10 |
11:15 |
20 |
11:11 |
11:16 |
45 |
11:12 |
11:16 |
20 |
11:13 |
11:16 |
この例では、すべてのデータが時間通りに到着した場合、ディテクターはアラートを発しません。しかし、11:08から11:15までの間に監視対象のメトリクスの値が50を超え、値が40である11:09のデータポイントがこのときにやっと到着しています。指定されたディテクターパラメーターにより、11:08から5分後の11:13にアラートがトリガーされます。
しかし、後でこのディテクターを見ると、チャートに表示されたデータポイントは正しいタイムスタンプを反映しています。つまり、11:09以降のデータポイントはすべて、正しいタイムスタンプ（メトリクスが送信され、到着が予想される時刻）で50未満の値を示しているため、トリガーの閾値条件が満たされたようには見えません。
この問題を避けるために、いくつかの戦略を使うことができます：
Max Delay の値を Auto に設定します。ディテクターで「最大遅延」の値を手動で設定した場合は、その値を「Auto」にリセットします。Amazon CloudWatchメトリクスの同期とAmazon EC2プロパティの同期に、受信データに基づいて最大遅延を自動的に調整させるようにすると、通常、遅延データによるアラートの不用意なトリガーを防ぐことができます。
ディテクターの extrapolation policy を0（ゼロ）に設定して、データの欠落によるアラートのトリガーを防止します。予想される時間枠内に送信されなかったデータポイントは、デフォルトでnullと見なされ、計算から除外されます。
シグナルに
mean analytics関数を追加し、変換値を5分に指定することで、アラートをトリガーするシグナルと条件を変更し、ディテクターが直ちに発動するようにします。上記の例の表では、平均値が50を超える5分間は存在しないので、アラートはトリガーされません。
相関の矛盾のトラブルシューティング 🔗
相関とは、変数の組が互いにどれほど強く関係して（関連し合って）一定割合で一緒に変化しているかを示す関数です。
時系列は、メトリクス名とディメンションのセットによって定義されます。したがって、それぞれがメトリクスを保持している2つのプロットを比較するカスタムのアラート閾値を使用しているにもかかわらず、関与するメトリクスが同じディメンションを持たないという場合、それらの間の相関の矛盾によってアラートが発動しない可能性があります。
一方のメトリクスが他方のメトリクスにはないディメンションを保持している場合、分析エンジンは、特別な支援なしに2つのメトリクスを互いに比較する（相関付ける）ことはできません。
この問題を解決するには、2つのプロットを集約することで、問題のあるメトリクスを取り除き、相関を保つことができます。
count関数を使用して、インスタンスが停止しているかどうかを判断する 🔗
常にアップダウンが繰り返される刹那的なインフラストラクチャ環境では、従来の監視メカニズムでは、手動による設定を繰り返す必要があります。従来の監視メカニズムは、メトリクスのレポートがないことは常にアラートに値すると仮定しています。これは、インスタンスを意図的に停止する場合のように、レポートがないことがオートスケールによって期待される効果である場合に問題となります。しかし、分析を使用することで、レポートがないことが予期しない事態である場合にのみアラートを発することができます。
count の分析関数は、指定された時点で値をレポートしている時系列の数を知らせます。インスタンスが、意図的に終了されたなどの理由でメトリクスのレポートを停止した場合、その時系列はカウントされません。
注釈
ロールアップではなく、必ず分析関数を選択してください。
この関数が、レポートを行っているインスタンスの数を正確に報告するためには、インスタンスに期待される状態を伝えるプロパティが必要です。例えば、Amazonは、EC2インスタンスの状態を公開しています（「終了」、「実行中」など）。Splunk Infrastructure Monitoringは、これを aws_state としてインポートします。
count 関数を使用すると、以下のことが実行できます：
memory.freeなど、好みのハートビートメトリクスを使用するプロットを設定する。例えば
!aws_state:terminatedのように、意図的に終了されたエミッターを除外する。例えば
aws_tag_Nameのように、単一のエミッターを表すディメンションでグループ化してcount関数を適用する。
このプロットは、0または1を出力します。出力が0のときにトリガーされるアラートは、インスタンスが予期せず停止したことを知らせるアラートです。
この一般的なコンセプトは、以下が存在することを前提として、何にでも適用できます：
定期的にレポートを行うハートビートメトリクス
関心対象のエミッターまたはソースを表す正準ディメンション
エミッターの予想される状態を示す、そのディメンションのプロパティ
これらの項目は、「ハートビートチェック」の内蔵アラート条件にパッケージ化されています。このアラート条件の詳細については、ハートビートチェック を参照してください。