Splunk Observability Cloudのアラートとディテクターの概要 🔗

Splunk Observability Cloudは、ディテクター、イベント、アラート、および通知を使用して、特定の基準が満たされたときに情報を提供します。アクティブなアラートと既存のディテクターは、アラートページのタブ内で見つけることができ、イベントは、イベントサイドバー内で見つけることができます。どのダッシュボードからも利用可能です。

Example scenarios of alerts and detectors¶

CPU使用率が95パーセンタイルに達したときに、OpsチームのSlackチャンネルまたはメールアドレスにメッセージを送信したいという場合
同時ユーザー数が限界に近づき、追加のAWSインスタンスをスピンアップする必要が生じる可能性があるときに通知を受けたいという場合

他のシナリオ例は、アラートとディテクターを使用してインフラストラクチャの問題を発見し解決するシナリオを参照してください。

Detectors¶

detector は、チャート上と同様に、プロットライン上のシグナルを監視し、ルールで定義した条件に基づいてアラートイベントや解除イベントをトリガーします。概念的には、ディテクターは、シグナル値がアラートルールで定義した指定閾値をまたいだときにアラートをトリガーすることができるチャートと考えることができます。

ルールは、そのルールの条件が満たされたときにアラートをトリガーします。ディテクター内の個々のルールは、重大度に従ってラベル付けされます。重大度は、「情報」、「警告」、「マイナー」、「メジャー」、「クリティカル」です。たとえば、APIコールのレイテンシを監視するディテクターは、ディテクターのルールの定義にしたがって、レイテンシが通常よりも大幅に長い場合に「クリティカル」の状態になる可能性があります。

またディテクターは、一定期間にわたって特定の条件に対してストリームを評価します。メトリック時系列（MTS）に分析を適用すると、SignalFlowクエリ言語のオブジェクトであるストリームが生成されます。MTSには、生データまたは分析関数の出力を含めることができます。

Metadata in detectors¶

MTSに関連するメタデータを使用することで、ディテクターの定義をよりシンプルに、よりコンパクトに、よりしなやかにすることができます。

たとえば、Kafkaのようなクラスタ化されたサービスを提供するために使用される30台の仮想マシンのグループがある場合、通常はこれらの仮想マシンから来るすべてのメトリクスを service:kafka というディメンションとあわせて含めます。

これらの各仮想マシンのCPU使用率が80未満にとどまっているかどうかを追跡する場合、service:kafka ディメンションを含むCPU使用率メトリクスをクエリし、80という閾値に対してこれらのメトリクスを評価する単一のディテクターを作成できます。この単一のディテクターを使用して、まるで30台の別々のディテクターがあるかのように、CPU使用率が閾値を超える各仮想マシンに対して個別のアラートをトリガーできます。30台の仮想マシンそれぞれの監視に、30個の個別のディテクターを作成する必要はありません。

クラスタが仮想マシン40台となって増加したために母集団が変更されるという場合は、クラスタレベルまたはサービスレベルのディテクターを作成できます。新しく追加された仮想マシンに service:kafka ディメンションを含めると、既存のディテクターのクエリでは、クラスタ内のすべての新しい仮想マシンが閾値の評価に含まれます。

Dynamic threshold conditions¶

ディテクターの条件に静的な値を設定すると、あるサービスや特定の時間帯にとって適切な値が、別のサービスや別の時間帯には適切でない可能性があるため、ノイズの多いアラートが発生する可能性があります。例えば、アプリケーションやサービスにDockerコンテナやEC2オートスケーリングのようなしなやかなインフラストラクチャが含まれている場合、アラートの値は、時間帯によって異なる可能性があります。

そこで、ストリーミングデータにおける変化を考慮した動的な閾値を定義することができます。例えば、メトリクスが周期的な挙動を示す場合、同じメトリクスを1週間タイムシフトしたバージョンの閾値を定義することができます。関連データの比較基準が、クラスタ化されたサービスのような集団の挙動であると考えてみてください。この場合は、その挙動を反映した値を閾値として定義することができます。例えば、15分の移動窓におけるクラスタ全体のメトリクスの90パーセンタイルなどです。

詳細は、内蔵アラート条件を参照してください。

Alerts¶

When data in an input MTS matches a condition, the detector generates a trigger event and an alert that has a specific severity level. You can configure an alert to send a notification using Splunk On-Call. For more information, see the Splunk On-Callの使用を開始する方法 documentation.

アラートルールは、内蔵のアラート条件に指定した設定を使用して、アラートをトリガーする閾値を定義します。ディテクターは、ルールの条件が満たされたと判断すると、アラートをトリガーし、イベントを作成し、通知を送信します（指定してある場合）。ディテクターは、電子メール、Slackなどの他システム、またはウェブフックを介して通知を送信できます。

Interaction between detectors, events, alerts, and notifications¶

ディテクター、イベント、アラート、通知間の相互関係は以下の通りです：

ディテクターは、ルールを含みます。ルールは、以下を指定します：
- ディテクターの signal に関連する条件に基づいて、ディテクターがトリガーされるタイミング。
- ディテクターによって生成される alert の重大度。
- 通知の送信先。
ディテクターがトリガーされると、次のような動作をします：
- event を生成する。これは、チャートや「イベント」サイドバーで確認できます。
- アラートをトリガーする。このアラートは、Splunk Observability Cloudのさまざまな場所で確認できます。
- 1つまたは複数の通知を送信する。これにより、現在ダッシュボードを閲覧していないメンバーにも、アラートに関する通知が届きます。
条件が解除されると、ディテクターは2つ目のイベントを生成し、2つ目の通知セットを送信します。

次の図は、ディテクターとアラートの関係を説明したものです。四角形はディテクターに関連するオブジェクトを表し、菱形はディテクターに関連するプロセスを表しています。

What you can do with alerts and detectors¶

次の表は、ディテクター、イベント、アラート、および通知でできることを示したものです：

操作（行動）	ドキュメントへのリンク
組織用に設定されたディテクターに基づいてアラートを表示する	アラートの表示
ディテクターを変更できる人を制限する	ディテクターの権限の表示と管理
アラート通知の送信先を指定する	通知の受信登録の管理
通知を一時的にミュートにする（送信を停止する）	アラート通知のミュート
アラート情報を補足するイベントを作成および表示する	イベントを使用してメトリクスにコンテキストを追加する
監視要件を満たすイベント、アラート、通知を生成するディテクターを作成する	アラートをトリガーするディテクターを作成する
内蔵アラート条件を操作する	内蔵アラート条件
レポートを停止したメトリクスによって生成されたアラートを自動的に解除するデフォルト設定を参照する	アラートの自動解除
ディテクターがアラートをトリガーしない原因、または予期せずアラートをトリガーする原因を判断する	Splunk Observability Cloudのディテクターのトラブルシューティング
ディテクターをチャートにリンクする	ディテクターをチャートにリンクする

このページは 2025年02月18日に最終更新されました。

Related Topics