Control Center を使用すると、監視データの異常イベントを検出し、アラートを設定できます。 クラスター障害に関する通知をできるだけ早く受信するようにメールアドレスを指定できます。 アラートは、トリガーと 1 つ以上のアクションで構成されます。 各トリガーは、トリガーが起動するタイミングを決定する条件値基準を持つメトリックに基づいています。 基準が満たされると、トリガーに関連付けられているすべてのアクションが実行されます。 このトピックでは、Control Center で ApsaraMQ for Confluent クラスターのアラートを設定する方法について説明します。
アラートメトリック
メトリック
タイプ | 名前 | 説明 |
ブローカートリガー | 受信バイト数 | ブローカーによって 1 秒あたりに生成されるバイト数。 |
送信バイト数 | ブローカーから 1 秒あたりにフェッチされるバイト数。 内部レプリケーショントラフィックは考慮されません。 | |
フェッチリクエストレイテンシ | 中央値、95 パーセンタイル、99 パーセンタイル、または 99.9 パーセンタイルでのブローカーへのフェッチリクエストのレイテンシ。 単位:ミリ秒。 | |
プロダクションリクエスト数 | ブローカーへのプロダクションリクエストの 1 分あたりの総数。 | |
プロダクションリクエストレイテンシ | 中央値、95 パーセンタイル、99 パーセンタイル、または 99.9 パーセンタイルでのブローカーへのプロダクションリクエストのレイテンシ。 単位:ミリ秒。 | |
クラスタートリガー | クラスターダウン | 監視対象のクラスターがシャットダウンされているかどうかを示します。 |
リーダー選出率 | パーティションリーダー選出の数。 | |
オフラインのトピックパーティション | クラスター内でオフラインになっているトピックパーティションの総数。 レプリカを持つブローカーがダウンしている場合、またはクリーンでないリーダー選出が無効になっていて、レプリカが同期していないため、リーダーとして選出できない場合、トピックパーティションはオフラインになる可能性があります。 リーダーとして選出できない場合は、メッセージが失われていないことを確認する必要があります。 トリガーを作成するときは、対応するパラメーターを 0 より大きい値に設定します。 | |
クリーンでない選出数 | 最後の間隔で報告された、クラスター内のクリーンでないパーティションリーダー選出の数。 同期していないレプリカ間でクリーンでないパーティションリーダー選出が行われた場合、以前のリーダーの損失前にメッセージが同期されていなかった場合、データ損失が発生する可能性があります。 したがって、クリーンでない選出の数が 0 より大きい場合は、ブローカーログをクエリして、リーダーが再選出された理由を特定し、警告メッセージまたはエラーメッセージを検索します。 ブローカー設定パラメーター unclean.leader.election.enable を false に設定することをお勧めします。 これにより、同期レプリカのセット外のレプリカがリーダーとして選出されることはありません。 トリガーを作成するときは、対応するパラメーターを 0 以外の値に設定します。 | |
複製不足のトピックパーティション | 同期レプリカの数がレプリケーション係数よりも少ないトピックパーティションの総数。 トリガーを作成するときは、対応するパラメーターを 0 より大きい値に設定します。 | |
ZK 切断 | ブローカーが ZooKeeper に接続できるかどうかを示します。 有効な値:
| |
ZooKeeper の有効期限率 | ブローカーで ZooKeeper セッションの有効期限が発生する割合。 | |
コンシューマーグルー プトリガー | 平均レイテンシ | コンシューマーグループの平均レイテンシ。 このメトリックを監視するには、コンシューマーグループのクライアントに Confluent Monitoring Interceptor を設定する必要があります。 単位:ミリ秒。 |
コンシューマーラグ | コンシューマーアプリケーションがプロデューサーアプリケーションからメッセージを消費している間の遅延量。 コンシューマーラグは、終了オフセットと現在のオフセットの差です。 | |
コンシューマーリード | コンシューマーアプリケーションがプロデューサーアプリケーションから消費している間の先行量。 コンシューマーリードは、現在のオフセットと開始オフセットの差です。 たとえば、オフセット 0 から始まるパーティションでオフセット 15 にあるコンシューマーのリードは 15 です。 このアラートメトリックは、消費が利用可能な最も古いメッセージに近づいていることを示します。 このメトリックを使用して、データ損失が発生したかどうかを判断できます。 | |
消費の差 | 特定の期間内の予想消費値と実際の消費値の差。 ほとんどの場合、予想消費値と実際の消費値の間には、ほぼリアルタイムに近いギャップが存在します。 このギャップは時間の経過とともに小さくなります。 | |
最大レイテンシ | コンシューマーグループの最大レイテンシ。 このメトリックを監視するには、コンシューマーグループのクライアントに Confluent Monitoring Interceptor を設定する必要があります。 単位:ミリ秒。 | |
トピックトリガー | 受信バイト数 | トピックに 1 秒あたりに入るバイト数。 |
送信バイト数 | トピックから 1 秒あたりに出るバイト数。 内部レプリケーショントラフィックは考慮されません。 | |
同期していないレプリカ数 | クラスター内のリーダーと同期しているトピックパーティションレプリカの総数。 このメトリックは、パーティションの合計を示し、トピックパーティションとトピックレプリケーション係数の積です。 | |
プロダクションリクエスト数 | クラスター内のトピックへのプロダクションリクエストの数。 | |
複製不足のトピックパーティション | 複製不足のトピックパーティションの数。 このメトリックのユースケースは、ブローカーが特定のトピックパーティションを保持しているときに Kafka ブローカーがクラッシュするかどうかを判断することです。 |
条件
監視対象メトリックの検出値と設定したしきい値との比較で条件が真になると、トリガーが起動します。 有効な値:
等しい
より大きい
より小さい
等しくない
トリガーの作成
上部のナビゲーションバーで、
アイコンをクリックします。
[概要] ページで、[トリガー] タブをクリックし、[トリガーの追加] をクリックします。
[新しいトリガー] ページで、トリガー名とトリガー条件を指定します。 次に、[保存] をクリックします。
トリガーが作成された後、[トリガー] タブでトリガーの名前をクリックし、表示されるページの下部でトリガーを変更または削除できます。
アクションフォームの作成
[概要] ページで、[アクション] タブをクリックし、[アクションの追加] をクリックします。
[新しいアクション] ページで、パラメーターを設定し、[保存] をクリックします。 次の表にパラメーターを示します。
パラメーター
説明
アクション名
アクション名を指定します。
トリガー
トリガーを選択します。
アクション
アクションタイプを選択します。 有効な値:
メールを送信:メールを使用して通知を送信します。
PagerDuty 通知を送信:PagerDuty を使用して通知を送信します。 詳細については、「サービスと統合」をご参照ください。
Slack 通知を送信:Slack を使用して通知を送信します。 詳細については、「受信 Webhook を使用したメッセージの送信」をご参照ください。
件名
1 つ以上のアラート連絡先のメールアドレスを指定します。 この設定は、[アクション] パラメーターが [メールを送信] に設定されている場合にのみ必須です。 アクションが実行されるたびに、指定されたメールアドレスにメールが送信されます。 複数のメールアドレスはコンマ (,) で区切ります。
最大送信レート
アクションが実行される最大レート。 このパラメーターは、[頻度] パラメーターと組み合わせて使用する必要があります。
たとえば、このパラメーターを 1 に、[頻度] パラメーターを [1 日ごと] に設定して、アラートを 1 日 1 回送信できます。
頻度
このパラメーターは、[最大送信レート] パラメーターと組み合わせて使用する必要があります。 有効な値:1 時間ごと、1 分ごと、4 時間ごと、8 時間ごと、1 日ごと。 デフォルト値:1 時間ごと。
たとえば、このパラメーターを [1 日ごと] に、[最大送信レート] パラメーターを 1 に設定して、アラートを 1 日 1 回送信できます。
[保存] をクリックします。
アクションが作成された後、[アクション] タブでアクションの名前をクリックし、表示されるページでアクションを変更または削除できます。
すべてのアラートアクションの一時停止と再開
メンテナンスまたはトラブルシューティングの理由により、必要に応じて、有効になっているすべてのアラートを一時停止できます。 有効または無効になっている個々のアクションの既存の設定は、一時停止中および再開中に考慮されます。 一時停止中は、満たされて起動されたトリガー条件は無視され、トリガーに関連付けられているすべての有効なアクションは抑制されます。 アクションが再開されると、条件が満たされたときにトリガーが起動し、通知が送信されます。 ApsaraMQ for Confluent または Control Center を停止して再起動すると、一時停止されたアクションは再開され、再びアクティブになります。
手順
[概要] ページで、[アクション] タブをクリックします。
[すべてのアクションを一時停止] スイッチをオンにします。
表示されるメッセージを読み、[確認] をクリックします。
アクションを再び有効にする場合は、上記の手順を繰り返して、[すべてのアクションを一時停止] スイッチをオンにします。
一時停止されたアラートアクションの再開
[概要] ページで、[アクション] タブをクリックします。
[すべてのアクションを一時停止] スイッチをオフにします。
表示されるメッセージを読み、[確認] をクリックします。
アラートアクションの無効化または有効化
アクションを作成すると、デフォルトで有効になります。 アクションをアクティブにしたくない場合は、無効にします。 アクションの一時停止と再開は、アクションの無効化設定を考慮します。 一時停止されたアラートを再開しても、無効になっているアラートアクションはアクティブになりません。
手順
[概要] ページで、[アクション] タブをクリックします。
[アクション] タブで、管理するアクションをクリックします。
アクションの詳細ページで、[編集] をクリックし、[有効] スイッチをオフにします。
アクションを再び有効にする場合は、上記の手順を繰り返して、[有効化] スイッチをオンにします。
参照
アラート設定の詳細については、「Confluent Platform の Control Center アラート」をご参照ください。