Splunk Observability Cloudのアラートとディテクターの概要 🔗
Splunk Observability Cloud uses detectors, events, alerts, and notifications to keep you informed when certain criteria are met. Active alerts and existing detectors can be found in tabs on the Alerts page, and events can be found in the Events sidebar, available from within any dashboard.
CPU使用率が95パーセンタイルに達したときに、OpsチームのSlackチャンネルまたはメールアドレスにメッセージを送信したいという場合
同時ユーザー数が限界に近づき、追加のAWSインスタンスをスピンアップする必要が生じる可能性があるときに通知を受けたいという場合
For more example scenarios, see アラートとディテクターを使用してインフラストラクチャの問題を発見し解決するシナリオ.
detector は、チャート上と同様に、プロットライン上のシグナルを監視し、ルールで定義した条件に基づいてアラートイベントや解除イベントをトリガーします。概念的には、ディテクターは、シグナル値がアラートルールで定義した指定閾値をまたいだときにアラートをトリガーすることができるチャートと考えることができます。
ルールは、そのルールの条件が満たされたときにアラートをトリガーします。ディテクター内の個々のルールは、重大度に従ってラベル付けされます。重大度は、「情報」、「警告」、「マイナー」、「メジャー」、「クリティカル」です。たとえば、APIコールのレイテンシを監視するディテクターは、ディテクターのルールの定義にしたがって、レイテンシが通常よりも大幅に長い場合に「クリティカル」の状態になる可能性があります。
またディテクターは、一定期間にわたって特定の条件に対してストリームを評価します。メトリック時系列（MTS）に分析を適用すると、SignalFlowクエリ言語のオブジェクトであるストリームが生成されます。MTSには、生データまたは分析関数の出力を含めることができます。
MTSに関連するメタデータを使用することで、ディテクターの定義をよりシンプルに、よりコンパクトに、よりしなやかにすることができます。
たとえば、Kafkaのようなクラスタ化されたサービスを提供するために使用される30台の仮想マシンのグループがある場合、通常はこれらの仮想マシンから来るすべてのメトリクスを service:kafka というディメンションとあわせて含めます。
If you want to track whether the CPU utilization remains below 80 for each of those virtual machines, you can create a single detector that queries for the CPU utilization metrics that include the service:kafka dimension and evaluates those metrics against the threshold of 80. This single detector triggers individual alerts for each virtual machine whose CPU utilization exceeds the threshold, as if you had 30 separate detectors. You do not need to create 30 individual detectors to monitor each of your 30 virtual machines.
クラスタが仮想マシン40台となって増加したために母集団が変更されるという場合は、クラスタレベルまたはサービスレベルのディテクターを作成できます。新しく追加された仮想マシンに service:kafka ディメンションを含めると、既存のディテクターのクエリでは、クラスタ内のすべての新しい仮想マシンが閾値の評価に含まれます。
ディテクターの条件に静的な値を設定すると、あるサービスや特定の時間帯にとって適切な値が、別のサービスや別の時間帯には適切でない可能性があるため、ノイズの多いアラートが発生する可能性があります。例えば、アプリケーションやサービスにDockerコンテナやEC2オートスケーリングのようなしなやかなインフラストラクチャが含まれている場合、アラートの値は、時間帯によって異なる可能性があります。
You can define dynamic thresholds to account for changes in streaming data. For example, if your metric exhibits cyclical behavior, you can define a threshold that is a one-week timeshifted version of the same metric. Suppose the relevant basis of comparison for your data is the behavior of a population, such as a clustered service. In that case, you can define your threshold as a value that reflects that behavior. For example, the 90th percentile for the metric across the entire cluster over a moving 15-minute window.
詳細は、内蔵アラート条件 を参照してください。
入力MTSのデータが条件に一致すると、ディテクターはトリガーイベントと特定の重大度レベルを持つアラートを生成します。アラートは、Splunk On-Callを使用して通知を送信するように設定できます。詳細は、Splunk On-Call のドキュメントを参照してください。
アラートルールは、内蔵のアラート条件に指定した設定を使用して、アラートをトリガーする閾値を定義します。ディテクターは、ルールの条件が満たされたと判断すると、アラートをトリガーし、イベントを作成し、通知を送信します（指定してある場合）。ディテクターは、電子メール、Slackなどの他システム、またはウェブフックを介して通知を送信できます。
ディテクター、イベント、アラート、通知間の相互関係は以下の通りです：
ディテクターがトリガーされると、次のような動作をします：
event を生成する。これは、チャートや「イベント」サイドバーで確認できます。
Triggers an alert, which can be viewed in a number of places throughout Splunk Observability Cloud.
1つまたは複数の通知を送信する。これにより、現在ダッシュボードを閲覧していないメンバーにも、アラートに関する通知が届きます。
条件が解除されると、ディテクターは2つ目のイベントを生成し、2つ目の通知セットを送信します。
次の図は、ディテクターとアラートの関係を説明したものです。四角形はディテクターに関連するオブジェクトを表し、菱形はディテクターに関連するプロセスを表しています。
次の表は、ディテクター、イベント、アラート、および通知でできることを示したものです：
操作（行動） |
ドキュメントへのリンク |
|---|---|
組織用に設定されたディテクターに基づいてアラートを表示する |
|
ディテクターを変更できる人を制限する |
|
アラート通知の送信先を指定する |
|
通知を一時的にミュートにする（送信を停止する） |
|
アラート情報を補足するイベントを作成および表示する |
|
監視要件を満たすイベント、アラート、通知を生成するディテクターを作成する |
|
内蔵アラート条件を操作する |
|
レポートを停止したメトリクスによって生成されたアラートを自動的に解除するデフォルト設定を参照する |
|
ディテクターがアラートをトリガーしない原因、または予期せずアラートをトリガーする原因を判断する |
|
ディテクターをチャートにリンクする |