通知ポリシー - Amazon Managed Grafana

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

通知ポリシー

このドキュメントトピックは、Grafana バージョン 10.x をサポートする Grafana ワークスペース向けに設計されています。

Grafana バージョン 9.x をサポートする Grafana ワークスペースについては、「」を参照してくださいGrafana バージョン 9 での作業

Grafana バージョン 8.x をサポートする Grafana ワークスペースについては、「」を参照してくださいGrafana バージョン 8 での作業

通知ポリシーは、さまざまなレシーバーにアラートをルーティングする柔軟な方法を提供します。ラベルマッチャーを使用すると、個々のアラートルールをすべて更新することなく、アラート通知配信を変更できます。

このセクションでは、通知ポリシーの設定を最大限に活用できるように、通知ポリシーの仕組みと構成について詳しく説明します。

ポリシーツリー

通知ポリシーはリストではなく、ツリー構造に従って構造化されます。つまり、各ポリシーには子ポリシーなどを含めることができます。通知ポリシーツリーのルートは、デフォルトの通知ポリシー と呼ばれます。

各ポリシーは、処理に関心のあるラベルまたは関心のないラベルを指定する一連のラベルマッチャー (0 以上) で構成されます。

ラベルマッチングの詳細については、「」を参照してくださいラベルマッチングの仕組み

注記

通知ポリシーにラベルマッチャーを設定していない場合、通知ポリシーはすべてのアラートインスタンスと一致します。これにより、通知ポリシーで兄弟のマッチングを継続を有効にしていない限り、子ポリシーが評価されない場合があります。

ルーティング

どの通知ポリシーがどのアラートインスタンスを処理するかを判断するには、デフォルトの通知ポリシーから始めて、既存の通知ポリシーのセットを見ることから始める必要があります。

デフォルトポリシー以外のポリシーが設定されていない場合、デフォルトポリシーはアラートインスタンスを処理します。

デフォルトポリシー以外のポリシーが定義されている場合、それらの通知ポリシーは表示される順序で評価されます。

通知ポリシーにアラートインスタンスのラベルと一致するラベルマッチャーがある場合、その子ポリシーに降順になり、存在する場合、ラベルのセットをさらに絞り込むラベルマッチャーを持つ可能性のある子ポリシーが引き続き検索され、その後、子ポリシーが見つからないようになります。

通知ポリシーで子ポリシーが定義されていない場合、またはアラートインスタンスのラベルに一致するラベルマッチャーが子ポリシーのいずれにもない場合、親通知ポリシーが使用されます。

一致するポリシーが見つかるとすぐに、システムは他の一致するポリシーを引き続き検索しません。一致する可能性のある他のポリシーを引き続き検索する場合は、その特定のポリシーで「兄弟のマッチングを続ける」を有効にします。

最後に、どの通知ポリシーも選択されていない場合は、デフォルトの通知ポリシーが使用されます。

ルーティングの例

以下は、比較的単純な通知ポリシーツリーといくつかのアラートインスタンスの例です。

ツリー構造内の通知ポリシーのセットと、ポリシーに一致するラベルが異なるアラートインスタンスのセットを示す画像。

これらのポリシーの選択方法の内訳は次のとおりです。

でスタックしたポッド CrashLoopにはseverityラベルがないため、子ポリシーは一致しません。team=operations ラベルが付いているため、最初のポリシーは一致します。

一致が既に見つかり、一致する兄弟の継続がそのteam=securityポリシーに対して設定されていないため、ポリシーは評価されません。

ディスク使用状況 – 80% には teamと の両方のseverityラベルがあり、オペレーションチームの子ポリシーと一致します。

許可されていないログエントリにはteamラベルがありますが、値が同じではないため、最初のポリシー (team=operations) と一致しないため、検索とteam=securityポリシーの一致が続行されます。子ポリシーがないため、追加のseverity=highラベルは無視されます。

継承

アラートインスタンスをルーティングするための有用な概念である子ポリシーに加えて、親ポリシーからプロパティを継承します。これは、デフォルトの通知ポリシーの子ポリシーであるポリシーにも適用されます。

次のプロパティは子ポリシーによって継承されます。

  • 連絡先

  • オプションのグループ化

  • タイミングオプション

  • ミュートタイミング

継承されたプロパティを上書きする場合は、これらのプロパティをそれぞれ個別のポリシーで上書きできます。

親ポリシーから連絡先を継承するには、空白のままにします。継承されたグループ化オプションを上書きするには、グループ化の上書きを有効にします。継承されたタイミングオプションを上書きするには、一般的なタイミングを上書きする を有効にします。

継承の例

以下の例は、前の例の通知ポリシーツリーで、 の子ポリシーがコンタクトセンターteam=operationsを継承することを許可する方法を示しています。

これにより、子ポリシーごとに同じコンタクトポイントを複数回指定する必要がなくなります。

ツリー構造内の一連の通知ポリシーを示す画像。一部のポリシーにはコンタクトポイントが割り当てられますが、一部の子ポリシーは、独自のポリシーを定義するのではなく、親のコンタクトポイントを継承します。

追加設定のオプション

グループ分け

グループ化は Grafana アラートの重要な機能です。これにより、関連するアラートをバッチ処理して少数の通知にまとめることができます。これは、エンジニアなどのファーストレスポンダーに通知が配信され、短期間に多数の通知を受信すると圧倒され、場合によってはファーストレスポンダーがインシデントに対応する能力に悪影響を及ぼす可能性がある場合に特に重要です。例えば、システムの多くが停止している大規模な停止を考えてみましょう。この場合、グループ化は、1 回の電話の受信と 100 回の電話の受信の違いになります。

通知ポリシーの Group by オプションを使用して、アラートをグループ化する方法を選択します。デフォルトでは、Grafana グループの通知ポリシーは、 alertnameおよび grafana_folderラベルを使用してアラートルールによってアラートをまとめます (アラート名は複数のフォルダ間で一意ではないため)。アラートルール以外の方法でアラートをグループ化する場合は、グループ化をラベルの他の組み合わせに変更します。

グループ化を無効にする

すべてのアラートを個別の通知として受信する場合は、 という特別なラベルでグループ化することで受信できます...。これは、アラートがファーストレスポンダーではなく自動システムに配信されている場合に便利です。

すべてのアラートに 1 つのグループ

すべてのアラートを 1 つの通知でまとめて受信する場合は、Group by empty のままにしておくことができます。

タイミングオプション

タイミングオプションは、アラートグループごとに通知を送信する頻度を決定します。グループ待機、グループ間隔、繰り返し間隔の 3 つのタイマーについて知っておく必要があります。

グループ待機

グループ待機は、新しいアラートグループの最初の通知を送信する前に Grafana が待機する時間です。グループの待機時間が長いほど、他のアラートが届くまでの時間が長くなります。グループの待機時間が短いほど、最初の通知は送信されますが、不完全な通知を送信するリスクがあります。ユースケースに最も適したグループ待機を常に選択する必要があります。

デフォルト 30 秒

グループ間隔

アラートの新しいグループに最初の通知が送信されると、Grafana はグループ間隔タイマーを開始します。これは、Grafana が変更に関する通知をグループに送信するまでに待機する時間です。例えば、既存のアラートが解決されている間に、別の発射アラートがグループに追加されている可能性があります。グループの待機が原因でアラートを最初の通知に含めるのが遅すぎた場合、グループ間隔後の後続の通知に含まれます。グループ間隔が経過すると、Grafana はグループ間隔タイマーをリセットします。これは、グループが削除された後にグループ内にアラートがなくなるまで繰り返されます。

デフォルト 5 分

繰り返し間隔

繰り返し間隔は、グループが前回の通知以降に変更されていない場合に通知を繰り返す頻度を決定します。これらは、一部のアラートがまだ発動していることを思い出させるものと考えることができます。繰り返し間隔はグループ間隔と密接に関連しています。つまり、繰り返し間隔はグループ間隔以上であるだけでなく、グループ間隔の倍数でなければならないということです。繰り返し間隔がグループ間隔の倍数でない場合、1 つに強制されます。例えば、グループ間隔が 5 分で、繰り返し間隔が 9 分の場合、繰り返し間隔は 5 の最も近い倍数である 10 分に切り上げられます。

デフォルト 4 時間