アラートの概要

Control Center では、モニタリングデータ内の異常イベントを検出し、それらのイベントが検出された場合にアラートが発生するように構成できます。たとえば、クラスターがダウンしたタイミングを検出し、メールを送信するように構成できます。

注釈

Control Center で RBAC が有効になっているときは、トリガー、アクション、アラートアクセスに微妙な差異が加わります。詳細については、「アラートアクセスについて」を参照してください。

Alerts ページにアクセスする方法については、「アラートアクセスとアラート履歴」を参照してください。

トリガーおよびアクション

アラートは 1 つのトリガーと 1 つ以上のアクションで構成されます。

トリガーは、以下に対して定義できます。

  • トピック
  • ブローカー
  • コンシューマーグループ
  • クラスター

各トリガーは、トリガーを起動する条件を判別する条件値基準を持つメトリックに基づきます。トリガーの詳細については、「トリガーの表示と管理」を参照してください。

基準が満たされると、トリガーに関連付けられているすべてのアクションが実行されます。

トリガーでは以下のアクションがサポートされています。

  • 1 つ以上のアカウントにメール通知を送信する
  • Slack Webhook 通知を送信する
  • インシデントチケットを作成する PagerDuty Webhook 通知を送信する

トリガーには、定義済みのアクションをいくつでも関連付けることができます。アクションの詳細については、「アクションの管理」を参照してください。

トリガーおよびアクションの構成方法を示す例については、「トリガーおよびアクションの例」を参照してください。

トリガーが起動されると、トリガーは、トリガーに関連付けられていて有効になっているアクションのうち Max send rate を超えていないすべてのアクションを実行します。特定のアクションの Max send rate を超えている場合、トリガーイベントはアクションに関連付けられたキューに追加され、アクションイベントが次回実行されるときにアクションイベントに含められます(アクションは 1 つのトリガーだけでなく一連のトリガーをレポートできます)。

注釈

アラート(アクション)が 一時停止 されている間トリガーは無視されるため、一時停止中はキューへの追加は行われません。

アラートあたりにトリガーされるイベントの最大数(デフォルトは 1000)は、confluent.controlcenter.max.trigger.events.per.alert.config オプションで制御されます。

異常イベント("トリガー起動" 基準)の検出は、トリガー起動イベントが発生したときに実行されるアラート "アクション" から分離されます。つまり、トリガーとアクションは独立して定義されます。これにより、トリガーが起動されたときに実行する 1 つ以上のアクションの設定に柔軟性が生まれます。

インターセプターデータが Control Center によって受信されるたびに、対応する時間ウィンドウのメトリック値(消費量の違い、レイテンシなど)が更新されて新しいデータが反映されます。新しく更新されたすべてのメトリック値が構成されているすべてのトリガーと照合されて、トリガーを起動する必要があるかどうかが判別されます。

注釈

インターセプターでは、任意の時点に関連するデータが報告される場合があります。アラートの発行は、リアルタイムに近い時間ウィンドウだけでなく、すべての時間ウィンドウ全体に対して機能します。

コンシューマーグループトリガーのためのバッファ(非推奨)

ちなみに

このトリガーのためのバッファ機能は非推奨になりました。今後のリリースで Control Center から削除される予定です。バッファ値には依存しないでください。

コンシューマーグループのトリガーには "バッファ" 値が関連付けられています。バッファを使用すると、アラート可能な状態を構成可能な期間持続するよう要求して、コンシューマーグループトリガー が早めにアクティブ化されてしまう状況を制御できます。