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

通知ポリシー

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

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

ポリシーツリー

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

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

ラベルの一致の詳細については、「ラベル一致の仕組み」を参照してください。

ルーティング

どの通知ポリシーがどのアラートインスタンスを処理するかを決定するには、既定の通知ポリシーから開始して、既存の通知ポリシーのセットを確認する必要があります。

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

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

通知ポリシーにアラートインスタンスのラベルと一致するラベルマッチャーがある場合、通知ポリシーは子ポリシーに降りてきます。子ポリシーがある場合は、ラベルのセットをさらに絞り込むラベルマッチャーを持つ可能性のある子ポリシーを探し続け、子ポリシーが見つからなくなるまで続行されます。

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

一致するポリシーが見つかるとすぐに、システムは他の一致するポリシーの検索を中止します。一致する可能性のある他のポリシーを引き続き検索する場合は、その特定のポリシーで [兄弟の照合の続行]を有効にします。

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

ルーティングの例

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

これらのポリシーの選択方法の内訳を次に示します。

[CrashLoop でスタックされた Pod]には 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 つの通知でまとめて受信する場合は、グループを空のままにすると受信できます。

タイミングオプション

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

グループ待機

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

デフォルト: 30 秒

グループ間隔

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

デフォルト: 5 分

繰り返し間隔

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

デフォルト: 4 時間