Datadog の Webhooks インテグレーションで外部サービスにアラート通知を API 連携してみた
こんにちは、なおにしです。
Datadog のWebhooks インテグレーションを使用する機会がありましたのでご紹介します。
はじめに
Datadog では豊富なインテグレーションが提供されており、モニタリングでイベントを検知した際の通知方法としてメール以外にも以下のようなサービス向けの通知用インテグレーションがあります。
- Jira
- PagerDuty
- Slack
- Microsoft Teams
- ServiceNow
目的の通知先が既存の通知用インテグレーションとして存在していれば問題ありませんが、Zabbix や Backlog といった通知用インテグレーションが存在しないサービスや、スクラッチ開発のシステムに対して通知内容を API 連携したいといった需要もあるかと思います。
そのような場合には、通知用インテグレーションの一つである Webhooks を用いて API 連携を実現できます。
本記事では、 Datadog のモニタリングで検知したイベント内容を Webhooks インテグレーションを利用して Backlog のコメントに追加してみます。
やってみた
事前準備
Backlog のAPIキーを発行しておきます。
Backlog のAPI仕様は公式ドキュメントをご確認ください。
Webhooks インテグレーションの設定
Datadog にログインして[Integrations] - [Integrations]を開き、検索ボックスでWebhooksを検索します。
Webhooks インテグレーションを選択し、[Configure]-[Webhooks]タブで[New Webhook]ボタンを押下します。
今回は以下のように設定しました。
-
Name:
backlog-alert-notification -
URL:
https://your-space.backlog.jp/api/v2/issues/issueIdOrKey/comments?apiKey=$BACKLOG_API_KEYyour-space: BacklogのスペースIDissueIdOrKey: コメントを追加する課題のキー$BACKLOG_API_KEYについては後述します
-
Payload: Template で [Blank]を選択し、以下を指定
-
{ "content": "## Datadogイベント通知\n### イベント名\n$EVENT_TITLE\n### ステータス\n$ALERT_STATUS\n### イベント内容\n$EVENT_MSG" }
-
-
Custom Headers: 指定無し
-
Encode as form: チェック無し
カスタム変数の設定
Backlog の APIキーは Webhooks インテグレーションのカスタム変数として保存します。カスタム変数の[hide from view]を有効化することで、Webhooks の設定画面を開いても APIキーを閲覧することができなくなるため、APIキーをセキュアに保管できます。
Webhooks インテグレーション設定画面の[Configure]-[Variables]タブで[New Variable]ボタンを押下し、以下を設定して[Save]します。
- Name:
BACKLOG_API_KEY - Value: Backlogで発行したAPIキー
- hide from view: チェック
一度[hide from view]にチェックを入れて保存したカスタム変数は、[Edit]ボタンを押下しても内容を表示することはできません。
モニターの設定
今回は DynamoDB のリードキャパシティユニット(RCU)が閾値超過した時にアラートとして検知するように設定してみます。
[Monitoring]-[New Monitor] を開き、[Metric]を選択します。detection methodはデフォルトで選択されている[Threshold Alert]のまま進みます。
以下のとおり設定します。name:attendance-tableは今回の検証に使用したDynamoDB テーブルに付与しているタグです。
今回は通知内容を以下のとおりシンプルに定義します。先ほど設定した Webhooks と、Datadog のユーザーに紐づくメールアドレスを指定します。
{{#is_alert}}といった構文については以下のドキュメントをご参照ください。今回の記載内容では、アラート状態になった場合と復旧した場合で通知内容を分けています。
Notification OptionsについてはDefaultからHide Handlesに変更しました。Defaultを選択した場合、@webhook-backlog-alert-notification やメールアドレスなどの通知先の指定も通知内容に含まれるためです。詳細はこちらのドキュメントをご参照ください。
このまま[Create and Publish]ボタンを押下してモニターを作成しても良いのですが、その場合はすぐに監視が開始されることになります。このため、事前に通知のテストをする場合は、[Test Notifications]から通知の挙動を確認することが可能です。
今回はアラートとその復旧だけが通知のルールで定義されているので、以下のとおり2項目しか選択することができません。この状態で[Run Test]を押下すると、Test notifications sentのメッセージが表示されます。
アラート通知のメールは以下のとおりです。[TEST]という表記と、誰が通知をトリガーしたのか分かるようになっています。
復旧通知の場合も同様です。
続いて、Backlogにコメントされたアラート通知の内容は以下のとおりです。
復旧通知は以下のとおりです。
通知テストの結果が問題なければ[Create and Publish]ボタンを押下してモニターを作成します。なお、監視をまだ開始したくない場合は[Save as Draft]ボタンからドラフトモニターとして保存することも可能です。ただし、ドラフトモニターは半年間更新がないと期限切れになる(= 削除される)ようなので、放置していると意図せず消えてしまう可能性があることにご注意ください。
Drafts expire after 6 months without updates, but you can delete draft monitors at any time.
実際に検知してみる
実際にDynamoDB で読み取り操作を実行してイベントを検知してみます。読み取り操作を行うことで、以下のとおり[Metrics]-[Explorer]からも値が増加していることが分かります。
モニターでもアラート状態になりました。
メールとBacklogにアラート通知がきました。
DynamoDB の読み取り操作は数秒だけ行なっただけなので、すぐに復旧状態になりました。
メールとBacklogに復旧通知がきました。
補足：APIの実行が失敗した場合のトラブルシュート
今回の検証を行なっている際、Webhooks の設定が誤っていたため、モニタリングでのイベント検知によってAPIが実行されているはずでもBacklogのコメントには登録されていないという状況になりました。
このような場合、トラブルシュートのためには[Monitoring]-[Event Management]-[All Events] を開き、該当する時間やソースで対象イベントを絞り込むことで、エラーの原因を確認することが可能です。
まとめ
Webhooks インテグレーションを使用することでモニターの通知をBacklog のコメントとしてAPIで登録することが確認できました。特に、モニターの設定時にテストイベントをすぐに試すことができる部分が便利だと感じました。
API連携用の仕組みを別途開発することなく、Backlog 以外にも様々なサービス/システムとの連携に役立つと思いますので、ぜひご活用ください。
本記事がどなたかのお役に立てれば幸いです。
