AWS DevOps Agent、New Relic連携時の、Slack 通知について検証してみた
はじめに
こんにちは、じゅんきちです。
AWS のメトリクスを New Relic で監視し、アラートを Slack に流している環境に、AWS DevOps Agent（以下 DevOps Agent）の自動調査を足してみたいと考えました。New Relic の Slack 通知は今のまま残し、その投稿を起点に DevOps Agent に調査させ、調査の中身も Slack で見られるようにするのがゴールです。
実際に組んでみると、New Relic から DevOps Agent への渡し方と、Slack への通知の出し方でそれぞれ考慮することがあったので、検証した結果をまとめます。
構成
- Lambda のメトリクスを CloudWatch Metric Streams → Data Firehose で New Relic に送ります。Metric Streams の Include filter を
AWS/Lambdaだけにして、Firehose に流す量を絞りました - New Relic のアラート条件は
aws.lambda.Errors.byFunctionが 0 を超えたら発火します - New Relic の Workflow で、Slack への通知と、DevOps Agent の汎用 Webhook の呼び出しを同時に行います
- DevOps Agent の調査の進み具合は EventBridge（
source: aws.aidevops）に流れるので、それを Lambda で受けて Slack に書きます - 対策1では、DevOps Agent の標準の Slack 連携も同じチャンネルで使います
New Relic 側の設定（AWS アカウントの連携、アラート条件、Workflow、Webhook の宛先）は Terraform、AWS 側は CDK で作りました。New Relic は無料プランです。
New Relic から DevOps Agent に渡す
MCP がないと DevOps Agent は New Relic のアラート情報を見られない
DevOps Agent の New Relic のネイティブ連携でできることは、New Relic のイベントから調査を起動すること（Webhook）と、調査中に New Relic のテレメトリを読むこと（New Relic の MCP サーバー）の2つです。MCP が要るのは後者だけで、起動に使う Webhook は Agent Space の汎用 Webhook と同じ形式（Bearer 認証）です。
ただし、ネイティブ連携の登録では最初に MCP への接続確認があります。無料プランのアカウントでは、ここで失敗しました。
Unable to access tools from the MCP server at 'https://mcp.newrelic.com/mcp/' (configured with api-key authorization).
{ "error": { "message": "Missing required entitlements. Make sure that you enabled access to this feature.", "code": 403 } }
登録できないと New Relic 用の Webhook URL も発行されないので、Agent Space の汎用 Webhook を New Relic の Workflow から直接呼ぶ形にしました。起動のしかたはネイティブ連携と変わりません。これで調査は始まりますが、最初は Webhook の description に New Relic の issue の URL しか入れていなかったので、調査結果の「調べられなかったこと」に次の内容が出ました。
New Relic 連携ツールが未構成: issue の発報者・priority・NRQL 条件式などは NR 経由で取得不可。CloudWatch メトリクスで代替
DevOps Agent からは、New Relic が何をどの条件で検知したのかが見えていません。
解決策: description に New Relic の情報を詰める
汎用 Webhook のペイロードのうち、調査のコンテキストに入るのは title / description / priority と、incident の参照（incidentId）だけです。data に何を入れても調査では使われません。
そこで、New Relic の Workflow で使える変数を description に箇条書きで詰めました。
{
"eventType": "incident",
"incidentId": {{ json issueId }},
"action": "created",
"priority": {{ json priority }},
"title": {{ json annotations.title.[0] }},
"description": "New Relic のアラートから起動した調査。以下は New Relic 側の情報。\n- issue: {{ issueId }}（{{ issuePageUrl }}）\n- アラートポリシー: {{ accumulations.policyName.[0] }}\n- アラート条件: {{ accumulations.conditionName.[0] }}（condition id {{ accumulations.conditionFamilyId.[0] }}）\n- 条件の NRQL: {{ accumulations.nrqlQuery.[0] }}\n- 対象エンティティ: {{ entitiesData.names.[0] }}（guid {{ entitiesData.ids.[0] }}）\n- 違反チャート: {{ violationChartUrl }}"
}
同じ障害を起こして、詰める前と後を1回ずつ比べました。
| 比較項目 | 詰める前 | 詰めた後 |
|---|---|---|
| 調査時間 | 12.6 分 | 7.6 分 |
| 調査のまとめの長さ | 787 字 | 1,483 字 |
| 調査の記録に NRQL のメトリクス名が出た回数 | 0 | 4 |
| 調べられなかったこと | New Relic の情報が取れない | New Relic の情報不足は消えた |
詰めた後は、New Relic のポリシー名や条件名を挙げて「テスト中は Muting Rule をかける」といった具体的な提案まで出るようになりました。
ただし、これで渡せるのはアラートの定義（何をどの条件で検知したか）までです。条件以外のメトリクスやログ、過去の issue の履歴といった New Relic に入っているデータそのものは、MCP がないと読めません。
Slack への通知
バラバラに通知すると見にくい
DevOps Agent には標準の Slack 連携があり、調査の途中経過（症状・観察・所見）と緩和計画をチャンネルに投稿してくれます。ただ、通知（One-way notifications）の投稿先として指定できるのはチャンネルだけで、スレッドは指定できません。プライベートチャンネルでは、アプリをメンションするとスレッドで返信する双方向モードもありますが、会話は新しいトップレベルのメッセージから始める作りなので、今回は試していません。
New Relic の Slack 通知と並べて動かすと、DevOps Agent はチャンネルに自分の親投稿（「Investigation started」）を新しく作り、そのスレッドに途中経過を書いていきます。
1つのアラートに対して、New Relic のスレッドと DevOps Agent のスレッドの2本ができます。アラートが続けて上がると、どの調査がどのアラートのものか追いにくくなります。
見にくいので対策したい
対策はどれも、New Relic のアラート投稿のスレッドに Lambda から返信する形です。そのためには、New Relic の投稿と DevOps Agent の調査を結びつけるキーが要ります。
Webhook の incidentId に New Relic の issueId を入れると、DevOps Agent のタスクの reference.referenceId にそのまま入りました。New Relic の Slack 投稿にも、リンクの URL に同じ issueId が入っています。DevOps Agent の調査の開始・終了は EventBridge（source: aws.aidevops）に流れるので、Lambda で受けてタスクから issueId を取り出し、チャンネルの投稿から issueId を含む New Relic の投稿を探して、そのスレッドに返信します。
Slack への投稿と読み取りには、自作の Slack App を使いました。
対策1: New Relic の投稿にリンクを貼り、DevOps Agent の投稿は標準連携に任せる
途中経過も緩和計画も標準連携のまま使い、New Relic のスレッドには標準連携のスレッドへのリンクだけを置きます。
標準連携の親投稿には調査画面の URL（https://<agentSpaceId>.aidevops.global.app.aws/investigation/<taskId>）が入っています。調査が始まったら Lambda でチャンネルの投稿を読み、この taskId を含む投稿を探して、そのスレッドへのリンクを New Relic の投稿のスレッドに返信します。
対策1: New Relic のスレッドに、標準連携のスレッドへのリンクが付く
スレッドは2本のままですが、New Relic のスレッドからどの調査かを辿れるようになりました。
対策2: まとめを1回だけ New Relic のスレッドに投稿する
調査が終わったときに1回だけ、調査のまとめを New Relic のスレッドに返信します。EventBridge の Investigation Completed で Lambda を起動し、ListJournalRecords で調査記録の investigation_summary_md（Markdown のまとめ）を取り出して返信します。
対策2: 調査が終わると、まとめが1件だけ返信される
1スレッドにまとまり、作りもいちばん単純です。ただし調査の途中経過は出ないので、途中経過を見たいときは DevOps Agent のコンソールを見に行く必要があります。
対策3: タイムラインなどすべてを New Relic のスレッドに投稿する
途中経過も New Relic のスレッドに書きます。Investigation In Progress で Lambda を起動し、調査記録をポーリングし、レコードが1件増えるたびに Slack へ送信します。最後のまとめは対策2の Lambda が返信します。
対策3: 調査が始まると、症状・所見が1件ずつ返信される
スレッドが長いので、続きです。
対策3（続き）: 観察・調べられなかったこと・まとめが続き、最後に New Relic の「issue is closed」が出る
今回の調査では問題ありませんでしたが、Lambda の上限の15分に収まらない場合は更なる作り込みが必要になります。
対策のまとめ
| 方式 | EventBridge ルール | Lambda | 中身 |
|---|---|---|---|
| 標準連携だけ | なし | なし | Slack の登録とチャンネルへの関連付けだけ。スレッドは2本に分かれる |
| 対策1: リンク | 開始 | リンク | 開始時に標準連携の親投稿を探し、リンクを1件返信する |
| 対策2: まとめだけ | 終了 | まとめ | 調査の終了時に1回だけ動き、まとめを1件返信する |
| 対策3: タイムライン | 開始＋終了 | タイムライン＋まとめ | 開始から15秒ごとに調査記録を読み、増えたレコードを1件ずつ返信する。最後にまとめを返信する |
まとめ
MCP がない場合、DevOps Agent は New Relic が何を検知したのか分からないまま調べ始めてしまうので、description に適切な情報を詰めて調査を起動する必要があります。
また、New Relic と DevOps Agent がバラバラに Slack へ通知すると運用しにくいので、1スレッドにまとめるなどの工夫をした方が良いです。
