Workflow Slack 連携の仕様と設定手順

New Relic の Workflow を利用して、アラート発報時に Slack へ通知を送る連携は、Issue 通知において多くのユーザーにご利用いただいているポピュラーな通知連携機能です。

設定自体はシンプルですが、いざ構築や運用を深めていくと「UI と Terraform で設定する際の挙動の違い」「設定を行うユーザーの Slack 認証状態によって選択できるチャンネルが異なる」、あるいは「Issueのクローズ時に最初の通知内容（Custom Details や Enrich データ）が上書きされてしまう」といった、少し入り組んだ仕様に直面することがあります。

本ブログでは、Workflow の Slack 連携に関して、以下の実践的なポイントを詳しく解説します。

• Destination の作成と Slack 認証の仕組み
• 認証済みユーザーと未認証ユーザーでの Notify (Workflow) 設定時の挙動の違い（UI / Terraform）
• 「Override notifications（元の Slack 通知の上書き）」機能の具体的な動作と注意点

これから Slack 連携を新規で設定される方はもちろん、すでに運用中で「通知内容がいつの間にか変わっている？」と疑問に思われたことがある方にも役立つ内容となっています。

アラート通知統合機能 > Slack ドキュメント

Slack タイプ Destination の作成

本ブログ執筆時点では、Destination として Slack を作成する場合、Slack ワークスペースへのサインインが必要となるため、NerdGraph や Terraform では新規作成ができません。UI より作成いただく必要があります。

UI より Alerts > Destinations と進み、Add a destination より “Slack” を選択します。

“Authenticate in one click” をクリックすると Slack ワークスペースへのサインインページに遷移します。またすでに別のワークスペースにサインイン済みである場合は、遷移先の「Slack へのアクセスを「New Relic」アプリに許可する」ページの Workspace から “別のワークスペースを追加する” を選択し、対象のワークスペースにサインインください。

サインインを行う Slack アカウントは、Slack へのサインイン前の段階では、操作をしている New Relic ユーザーとは関係がございません。対象の Slack ワークスペースのアカウントにサインインください。

下記操作にて、New Relic の UI で Slack のワークスペースにサインインした場合、操作した New Relic ユーザーは “認証済みユーザー” となり、サインインした Slack 側のアカウントと紐づきます。
複数の New Relic ユーザーが同一の Slack アカウントとしてサインインすることも可能でした。
別の Slack アカウントとしてサインインされ直す場合は、Slack アカウントからサインアウトいただくかシークレットブラウザ、プライベートブラウザなどで Slack にサインインしていない状態で、再度 Destination から別のアカウントにサインインください。 また、認可の取り消し（Revoke）に関しては、後述の “New Relic アプリ (Slack 側) での設定” をご参照ください。

“Authenticate in one click” をクリックした遷移先のページは slack.com のコンテンツとなります。遷移後のページが表示できない場合は、ブラウザで slack.com へのアクセスが許可されるかなどをご確認ください。

Slack へのサインインが成功すると「Slack へのアクセスを「New Relic」アプリに許可する」ページが表示されます。

New Relic アプリのパーミッションを確認いただき、問題なければ “許可をする” をクリックください。
この操作にて、対象 Slack ワークスペースに New Relic アプリが導入されることになります。

ブログ執筆時点の New Relic アプリのパーミッションは以下のように記載されております。

• "New Relic" がアクセスできる情報
  • あなたに関するコンテンツと情報
    • あなたの ID に関する情報にアクセスする
  • チャンネルと会話に関するコンテンツと情報
    • あなたのワークスペースのパブリックチャンネルに関する基本情報にアクセスする (user action)
    • あなたのプライベートチャンネルに関する基本情報にアクセスする (user action)
    • あなたのダイレクトメッセージに関する基本情報にアクセスする (user action)
    • あなたのワークスペースのパブリックチャンネルに関する基本情報にアクセスする (app action)
    • "New Relic"が連携されたプライベートチャンネルに関する基本情報にアクセスする (app action)
    • メッセージ内の URL を表示する (app action)
  • ワークスペースに関するコンテンツと情報
    • "New Relic"が接続されたワークスペースの名前、メールドメインやアイコンにアクセスする (app action)
    • あなたのワークスペースのメンバーを閲覧する (app action)
• "New Relic" が実行できるアクション
  • あなたとしてアクションを実行する
    • あなたに代わりパブリックチャンネルの管理と新規作成を行う
    • あなたに代わりプライベートチャンネルの管理と新規作成を行う (user action)
  • チャンネルと会話でアクションを実行する
    • アプリが参加している会話で @new_relic を直接メンションしているメッセージを表示
    • あなたのワークスペースでパブリックチャンネルに参加する
    • @new_relic としてメッセージを送信する (app action)
    • @new_relic が参加していないチャンネルにメッセージを送信する
    • メッセージ内の URL のプレビューを表示する (app action)
  • あなたのワークスペースでアクションを実行する
    • ユーザーが使用できるショートカットやスラッシュコマンドを追加する (app action)

上記のように New Relic の UI で Slack のワークスペースにサインインした場合、操作した New Relic ユーザーを “認証済みユーザー” と記載します。
サインインした Slack 側のアカウントは “Slack アカウント” と記載します。
繰り返しとなりますが、New Relic 側では “認証済みユーザー” はサインインした “Slack アカウント” と紐づきます。
一方で、Slack へのサインインを行っていない New Relic ユーザー は “未認証ユーザー” と記載します。

UI での Notify (Workflow) 設定

UI での Workflow > Notify で Slack チャンネルを指定する場合、認証済みユーザー での操作と 未認証ユーザー での操作では表示される Slack チャンネルが異なります。

• 認証済みユーザーでの設定

  • 紐づいている “Slack アカウント” が参加しているパブリックおよびプライベートチャンネルが表示され、選択することができます
    ( “Slack アカウント” の権限でチャンネル情報のリストを取得しているものと認識しています)
  • 既に存在する Workflow Notify に関しては、メンバーとして参加していない Slack チャンネルが設定されている場合であっても Custom Details の内容は変更いただけます

• 未認証ユーザーでの設定

  • Slack ワークスペースのパブリックチャンネルが表示され、選択することができます
    (NewRelic アプリの権限で、チャンネル情報のリストを取得しているものと認識しています)
  • プライベートチャンネルが設定されている既存の Workflow Notify に関しては、Custom Details の内容は変更いただけます

Terraform での Notify (Workflow) 設定 (newrelic_notification_channel)

Terraform を利用して設定する場合、UI とは少し異なる挙動となります。

Terraform > newrelic resources > notification_channel > Slack

Terraform では、Slack のチャンネルを channelId として設定いただく必要があります、channelId は Slack の対象チャンネルの リンク情報などから取得ください。

• 認証済みユーザーの UserKey を利用している場合
  • 紐づいている “Slack アカウント” が参加しているチャンネル (パブリック、プライベート区別なく) であった場合、設定することができます
• 未認証ユーザーの UserKey を利用している場合
  • パブリックチャンネルの場合、設定いただけます
  • プライベートチャンネルの場合、New Relic アプリが該当チャンネルに連携されている場合は設定いただけます
    • 該当チャンネルに New Relic アプリが連携されているかは、チャンネルの Edit settings > Integrations タブなどよりご確認、追加ください
      また、チャンネルから New Relic アプリ を削除する場合は /remove @New Relic など一般的なアプリ除去操作を実施ください

Slack の New Relic アプリ側での設定

先の方法で Slack 連携を設定した場合、対象の Slack では New Relic アプリが導入され、サインインした Slack アカウントが 認可メンバーとして追加されています。

認可メンバーについては、New Relic アプリの設定内容をブラウザでアクセスし、確認およびメンバーの削除 (Revoke) をすることが可能です。

Slack 側の New Relic アプリの認可メンバーを Revoke した場合、該当 Slack アカウントは Slack 側での権限を失うことになります。
また、この Revoke 操作は、New Relic 側には伝わらないようで、Revoke された Slack アカウントと紐づいている New Relic ユーザーは ”認証済みメンバー” のままとなります。
”認証済みメンバー” の状態ですが、Slack 側での権限を失っているため、UI ではチャンネルリストは表示されません。
この場合は、再度 Destination でサインインを行い、Slack アカウントと紐づいた認証済みユーザーとなってください。

Override notifications (Override original Slack notification)

テクニカルサポートケースでは、通知後に Custom Details や Enrich クエリの結果が変わってしまった、というお問い合わせをいただくことがございます。
これは Override notifications のオプションによる上書きによるものです。

Override notifications のオプションが有効な場合、Issue 作成 (Activated) 時の通知内容が Close 時の通知によって、上書きされます。

Improve notification workflows with new Slack integration features > Uncheck Slack notification overrides

(Nerdgraph では updateOriginalMessage、Terraform では update_original_message が対応します)

実際に、以下のように設定した Workflow における『Issue 作成時 (Activated)』と『クローズ (Closed) 後』の通知の挙動をご紹介します。
Custom Details や Enrichment に下記のような設定を行い、Issue は 15分後に自動でクローズされた例となります。

Custom Details には下記のように記載しました。stateText は Activate 時と Close 時では内容が変化します。また、createdAt は変化しませんが、closedAt は Activate 時 には未定の値で、Close 時にはクローズ時刻が入る変数となります。

"stateText": {{stateText}}
"createdAt": {{createdAt}}
"closedAt": {{closedAt}}

変化がわかりやすいように Enrich クエリには次の 2つのクエリを設定しました。

• クエリ1 (enrich-aggregationendtime)

SELECT toDatetime(aggregationendtime(), 'yyyy-MM-dd HH:mm:ss', timezone: 'UTC') FROM Log

• クエリ 2 (enrich-log)

SELECT message FROM Log WHERE message = ‘this is test message' SINCE 5 minutes ago

クエリ 2 はアラートコンディションのクエリと同じに SINCE 5 minutes ago を追加しています。

日本時間 17:45 (UTC 08:45) に Issue が新規作成され、Activate イベントで通知されて
15分後の 日本時間 18:00 (UTC 09:00) に Issue がクローズされて、Close 通知が行われました。

上記は Issue 作成時の通知内容です。
Custom Details は想定通り stateText は active で、closedAt は 未定義となっています。
aggregationendtime() は Enrich クエリが実行された 08:45 (UTC) になっており、Log データもヒットしています。

次の画像は、15分後のクローズ通知の結果です。

下部の紫枠で囲ったように Issue がクローズされた旨が スレッド返信で報告されています。

Override notifications によって変更された内容と変更されなk他t内容を詳しく見ていきます。
まずは、上部のオレンジ枠の内容は、変更されていません、日本時間 17:45 (UTC 08:45) で Issue が Active になった旨が記載されています。

次に Custom Details の内容ですが、ここは変化しています。
stateText は closed になり、Activate 時は入っていなかった closedAt にも時間が入っています。

また、2つの Enriched データも変化しています。
aggregationendtime() は Close 通知が行われた際の Enrich クエリの結果である 09:00 (UTC) 時刻の結果にさし代わり、 Log データも “No chart data available” (該当データなし) に変化しました。

このように Custom Details や Enrich クエリの結果は、Override notifications が有効な場合、後続の通知内容で上書きされます。
この上書きが便利な場合もありますが、Enrich クエリなどを利用している場合は意図しない上書きとなってしまう場合もあるかと思います。

期待される通知動作に合わせて、有効化、無効化を選択ください。