Datadog Monitor Notification Rules でタグベースのアラート通知を設定してみた
こんにちは、なおにしです。
Datadog の Monitor Notification Rules を利用したアラート通知を検証する機会がありましたのでご紹介します。
はじめに
以前の記事で、Webhooks インテグレーションを使用して外部サービスにアラート通知してみました。
この際の通知設定は、個別のモニター設定内にある「Configure notifications & automations」で以下のように定義していました。
設定方法の詳細は以下のドキュメントにまとまっており、記載のとおり条件付き変数を利用して柔軟に通知条件を指定することが可能です。
条件付き変数は、
if-elseロジックを使用して、モニターの状態とトリガーのされ方の詳細に応じて異なるメッセージを表示します。
一方で、上記のような方法で管理しているとモニター数が増えた時や条件分岐が複雑になった時にメンテナンスが難しくなることが想像できます。そこで活用できるのが Monitor Notification Rules 機能です。
Monitor Notification Rules では、上記のモニターごとの設定とは別にルールを作成し、モニターに設定されたタグとルールロジックに基づいて指定した送信先にアラートを通知することが可能です。
より詳細な解説については先ほどのドキュメントと併せて、以下のDatadog公式ブログの内容もご参照ください。
以下は Monitor Notification Rules のベストプラクティスについて、上記記事から引用したものです。
モニターにタグを付ける
アラート戦略に適したタグ（team、service、envなど）を、すべてのモニターで必須要素にしましょう。クリーンで一貫性のあるタグ付けにより、ルールのスコープを正確に保つことができ、新しいモニターが追加された際にも通知ルールが自動的に適用されるようになります。効果的なタグ付け戦略の実装には、Datadog のモニタータグポリシーがどのように役立つかをご確認ください。明確なオーナーシップを定義する
すべてのルールには明確なオーナーが存在すべきです。各ルールのスコープを特定のチームに限定することで、一致するモニターが発火した際に、誰がそのポリシーを管理しているのか、そして誰がページング（呼び出し）を受けるのかが明確になります。明確なオーナーシップにより、管理者不在のルートを防ぎ、レビューを迅速化できます。狭いスコープから始めて、徐々に広げる
まずは当面のニーズを満たす最も狭いスコープから始めましょう（例：team:payment-processing AND env:prod AND priority:P0）。ルーティングが正しく機能することを確認した後、スコープを段階的に広げていきます（例：P0 だけでなく、すべての優先度を含める）。アラートが複数のチームにスパムのように送られ始めてから、広すぎるルールを縮小するのは、正確なルールを広げるよりもはるかに困難です。
Datadog ではメトリクスやログといった監視データの管理にタグを活用することが必須となっていますが、モニターについても同様です。
それでは、実際に Monitor Notification Rules を使ってアラートを通知してみます。
やってみた
Teams の作成
[Organization Settings] - [Teams] から、通知先となるチームを作成します。今回はシンプルに以下のチームを作成してみます。
HogeサービスチームFuga基盤チームPiyoセキュリティチーム
Handleで指定された文字列が、teamタグで指定する際の値として扱われるようです。
ロールとしてMemberまたはManagerを指定することができ、チーム管理に関する権限設定をすることも可能ですが今回は割愛します。
なお、デフォルトでは以下のとおり、組織内の誰でもチームのメンバーを追加または削除できることにご注意ください。
先ほどのドキュメントに記載のとおり、サブチームを構成することもできるようなので、PiyoセキュリティチームについてはFuga基盤チームのサブチームにしてみます。Subteams 機能は、サブチームとして新たにチームを作るのではなく、既存のチームを別のいずれかのチームのサブチームとして配置するイメージです。
今回は以下のチーム構成で検証を進めます。
なお、後続の作業のために、各チームの通知設定でメールを有効化します。デフォルトでは以下のとおり有効化されておらず、この状態では Monitor Notification Rules の設定時に通知先としてチームがサジェストされないためです。なお、有効化した後、Monitor Notification Rules の設定でチームが通知先としてサジェストされるようになるまで、今回の検証では1〜2分ほどのラグがありました。
[Send alerts to team member emails] を選択して[Save] ボタンを押下します。
Tag Policies の設定
前述のベストプラクティスに基づき、タグポリシーを設定します。今回は例にあったとおり以下3つのタグをモニターに設定することを強制するポリシーとします。
teamserviceenv
[Monitors] - [Settings] - [Tag Policies] からポリシーを追加します。今回は上記いずれも必須タグとしています。service以外のタグについては値も固定としています。
詳細はドキュメントをご参照ください。特記事項として、タグポリシー適用前の既存モニターについてはポリシーに準拠していなくても引き続き機能しますが、設定変更時にポリシーに基づいたタグの設定が必要（設定しないと保存できない）となります。
Monitor Notification Rules の作成
本題の Monitor Notification Rules を設定していきます。[Monitors] - [Settings] - [Notification Rules] から、新しいルールを追加します。
本番環境で Priority が P1(Critical) の Alert を全チームに通知するルール
例として、上記のようなルールを作成してみます。この場合は以下のような設定になります。各ユーザーやチームだけではなく前回の記事で作成した Webhooks インテグレーションも通知先に指定可能です。Priority については、モニター設定画面での表示上はP1になっていましたが、タグで指定するときはp1という小文字でないと認識されなかったのでご注意ください。
画面右ペインに[1 matching monitor] と表示され、対象のモニター設定が表示されています。これは対象モニターの[Configure notifications & automations] で以下のように設定しており、ルールに該当するためです。
[Create Rule]を押下してルールを作成しました。以下のように登録されました。
対象のモニターを選択します。右側の数字にカーソルを合わせると、通知先のポップアップが表示されました。
[Message Template] 内では通知先を定義していませんが、モニターが Alert 状態になった時の通知先として、先ほど作成したルールに基づく内容が表示されています。
画面上部の[Edit] ボタンを押下し、[Test Notifications] から通知テストを実行してみます。
各通知先で受信を確認できました。
なお、全チームを通知先として登録している兼ね合いで、Fuga基盤チームのサブチームであるPiyoセキュリティチームのユーザーは、チーム階層的には二重登録になっている状態ですが、当該ユーザーにおいて重複通知にはなっていませんでした。この辺りの詳細な挙動はドキュメントに記載されていますのでご参照ください。
- If multiple rules match a single notification, recipients from all matching rules are merged and de-duplicated.
サブチームの親となるチームに通知するルール
手順の詳細は割愛しますが、Fuga基盤チームを通知先に設定すればサブチームであるPiyoセキュリティチームのメンバーにもメール通知されるのかが気になったためやってみました。
結論としては、通知されませんでした。
実際に通知された宛先については、対象モニターを選択した画面の[Event timeline]から該当のテストイベント選択することで確認できます。
したがって、サブチームについてはあくまでチーム階層を表現するものであって、通知先として設定する場合は個別にチームを選択する必要があります。
まとめ
複数のチームで多くのモニターを管理する状況になった時、Monitor Notification Rules によるタグとルールロジックに基づいた通知先のルーティングが非常に役立ちそうと感じました。
一方で、Monitor Notification Rules を実際の現場で有効活用するためには、どのようにチームを分けるべきか、どのようにタグを設計すべきか、といったルール設計を適切に実施/運用する必要があると思います。
本記事がどなたかのお役に立てれば幸いです。
