アラート通知統合機能を使用すると、特定のサービスやプラットフォームをNew Relicプラットフォームと連携させることができます。この連携を利用して、New Relicから通知を送信できます。この通知によって、見直しが必要なイシューに関する情報や、検出されたイシューに関する意思決定に役立つ情報を受け取ることができます。
統合機能の詳細
各通知統合について詳しくお読みください。
New RelicをAtlassian Jira（クラウド版）と連携させ、Jiraのイシューを自動的に作成、更新、クローズします。
アクセス権限
重要
この統合機能は、オンプレミス版およびデータセンター版のJIRAをサポートしていません。
Jira API-Tokenに必要な権限はBROWSE_PROJECTS、ASSIGN_ISSUES、CLOSE_ISSUES、CREATE_ISSUES、EDIT_ISSUES、RESOLVE_ISSUES、TRANSITION_ISSUES、USER_PICKER、ADD_COMMENTSです。
双方向同期トグルを有効にするには、指定されたJira API-KeyにAdminロールを持っている必要があります。
Jiraの送信先の設定
Jiraでイシューを作成し、JiraとNew Relicで更新情報を共有できるようにして、同期状態を維持します。
Jiraの送信先を作成するには、以下の手順に従ってください。
one.newrelic.com > All capabilities > Alertsに移動し、Destinationsをクリックしてから、Jiraを選択します。
以下の情報を入力してください。
- Name: 送信先を識別するためのカスタム名。
- URL: 送信先のURL。
- Username: ユーザーのメールアドレス。
- API token: Atlassianアカウントで生成されたもの。
送信先を保存する前に、Test connectionボタンをクリックして接続を確認することをお勧めします。
双方向同期
双方向同期はワークフローに適用可能です。これを有効にするには、双方向統合トグルをオンにします。
オンにすると、JiraアカウントにJira Webhookが作成されます。Webhookには、New Relicへのアクセス情報（URLとAPIキー）が含まれています。
New Relicとの同期
Jiraのイシューのステータスが
doneに変更されると、New Relicのイシューがクローズされます。Jiraのイシューのステータスが
in-progressに変更されると、New Relicのイシュー確認がトリガーされます。ワークフローにおけるメッセージテンプレートの設定
Jiraのイシューのテンプレートを設定するには、以下の手順に従ってください。
one.newrelic.com > All capabilities > Alerts > Workflowsに移動して既存のワークフローをクリックするか、+ Add a new workflowボタンをクリックします。
既存の送信先を選択するか、新しい送信先を作成します。
接続先と連携したら、プロジェクトを選択し、使用するJiraのイシュータイプを選択します。
イシュータイプを選択すると、設定済みのプロジェクトのフィールドがJiraインスタンスに自動的にマッピングされます。
使い始めやすいように、必須フィールドと推奨フィールドおよびその値が自動入力されます。先に進む前に、すべての必須項目に値が入力されていることを確認してください。
テスト通知の送信
デフォルトのフィールド値が設定されたテスト通知をクリックすると、Jiraのイシューが表示されます。成功すると、Jiraでアラートを表示するためのリンクが表示されます。
Jiraの通知メッセージテンプレート。
New RelicとAWS EventBridgeを使用することで、AWS Lambda、Amazon Simple Notification Service（SNS）キュー、CloudWatchログなどに通知をカスタマイズして送信できます。
EventBridgeの送信先の設定
重要
New Relicは、AWSのSaaSパートナーイベントソースとして登録されています。
AWS EventBridgeの送信先を作成するには、以下の手順に従ってください。
one.newrelic.com > All capabilities > Alertsに移動し、Destinationsをクリックしてから、AWS EventBridgeを選択します。
以下の情報を入力してください。
Name: 送信先を識別するためのカスタム名。
AWS region: AWSリージョンのエンドポイント。イベントソースがホストされている地域を選択してください。
AWS account ID: AWSアカウントID。12桁の数字です。
イベントソースの選択
AWSアカウントIDを使用してEventBridgeの送信先を設定すると、新しいイベントソースの作成時に、そのイベントソースをEventBridgeで利用できます。
送信先の名前を選択または作成します。
イベントソースを選択または作成します。
新しいイベントソースを作成すると、そのイベントソースはAWS EventBridgeアカウントに統合パートナーイベントソースとして作成されます。
AWSアカウントにおけるイベントソースの関連付けと、ルールの作成
イベントソースをイベントバスに関連付ける方法：
AWS EventBridgeコンソールで、ナビゲーションペインからPartner event sources選択します。
パートナーイベントソースの横にあるボタンを選択し、Associate with event busを選択します。
イベントソースのステータスがPendingからActiveに変更され、イベントバスの名前がイベントソース名に合わせて更新されます。これで、New Relicのイベントを対象とするルールを作成できます。
イベントバス用のルールを作成します。
New Relicから送信された通知に反応するには、New Relicイベントをフィルタリングするためのイベントパターンを含むルールを作成する必要があります。
より詳細な手順については、イベントソースルールの作成方法に関するAWSドキュメントを参照してください。
ワークフローでメッセージイベントテンプレートを設定する
Workflowsに移動し、既存のワークフローまたはAdd a new Workflowボタンをクリックして、送信先となるEventBridgeを選択します。New RelicからEventBridgeに通知を送信する際、メッセージテンプレートを使用して通知をカスタマイズできます。
デフォルトのテンプレートを使用することも、独自のテンプレートをカスタマイズすることも可能です。変数メニューからVariablesを選択し、Handlebars構文を適用してイベントを拡張します。
EventBridge APIはJSONを必要とし、テンプレートプレビューにはレンダリングされたJSONが表示されます。イベントテンプレートが有効なJSON形式に準拠したら、AWS EventBridgeにテスト通知を送信できます。詳細については、JSONの使用例をご覧ください。
ワークフローの通知チャネルとしてEmailを選択すると、メールの送信先が自動的に作成されるため、Destinationsメニューから設定する必要はありません。各メール送信先は、関連付けられているワークフローごとに固有のため、送信先フィードに重複して表示される可能性があります。
メール通知におけるアラートのワークフロフローの設定方法：
one.newrelic.com > All capabilities > Alertsに移動します。
左側のナビゲーションパネルでWorkflowsを選択します。
+ Add a workflowをクリックします。
ワークフロー名を設定します。この項目は必須であり、名前は一意である必要があります。
必要なデータを絞り込みます。送信したいイシューを追加するには、BasicからAdvancedのいずれかのオプションを選択してください。
データを拡充する場合や、ミュート対象のイシューの通知設定を行う場合は、Additional settingsをクリックします。
- データを拡充するには、Enrich your dataを有効にし、NRQLクエリを作成してから、保存して終了します。
- ミュート対象のイシューの通知設定を行うには、必要に応じて利用可能なオプションのいずれかを選択してください。
通知方法としてEmailを選択します。
受信者の追加：受信者の名前またはメールアドレスを入力します。そのユーザーの送信先がフィードに表示されるので、いずれかを選択します。ユーザーの新しい送信先を作成したい場合は、次の手順に従ってください。
フィードからCreate new destinationをクリックします。
Add a destinationページで、メールIDまたはユーザー名を検索して受信者を追加し、送信先に固有の名前を入力して保存します。
- メールアドレスが既に既存の送信先に関連付けられている場合は、それらを統合するかどうかを尋ねられます。送信先を結合する場合は、Mergeを選択してください。
- 新しいメールアドレスを追加すると、受信者には確認メールが送信されます。通知が届くようにするには、受信者が本人確認手続きを完了する必要があります。
重要
メール送信先の制限：
- 無料アカウント：送信先ごとに最大5件のメールアドレスを登録できます。
- 有料アカウント：送信先ごとに最大150件のメールアドレスを登録できます。
- 組織の制限：顧客組織ごとに24時間あたり1000件の一意のメールアドレスを追加できます（すべてのユーザーに適用）。
メールメッセージをカスタマイズする。
- メールの件名には、デフォルトのペイロードを使用することも、必要な情報を追加するためにカスタマイズすることもできます。
- メール本文には変更できないデフォルトデータが含まれていますが、任意の追加情報を追加することもできます。カスタマイズの内容はCustom Detailsセクションに表示されます。
- メールを充実させるには、変数メニューから変数を選択し、Handlebars構文を適用します。
Send test notificationをクリックして、メール通知が受信トレイに確実に届くことを確認します。
Saveをクリックします。
Activate workflowをクリックします。
ヒント
通知ログでは、送信先ごとにメール用に生成されたすべての通知を追跡できます。
ワークフローのメインページから、作成したワークフローの有効化、編集、削除、ワークフローIDのクリップボードへのコピーを行うことができます。
New RelicからMicrosoft Teamsに通知を送信できます。詳細については、「Microsoft Teams向けのNew Relicインテグレーション」を参照してください。
New RelicのiOSまたはAndroidモバイルアプリにプッシュ通知を送信します。
モバイルプッシュ通知の送信先を設定する
モバイルプッシュ通知の送信先を作成する際は、以下の情報が必要です。
Push destination name: 一意の送信先名。
User id: ログイン中のユーザーに応じて自動入力されます。
重要
現在、モバイルプッシュ通知の送信先を作成できるのは、変更権限を持つログイン中のユーザーのみです。また、ユーザーごとに作成できるプッシュ通知の送信先は1つだけです。複数作成しようとすると、エラーが表示されます。送信先を保存する前に、Test connectionボタンを使用して接続を確認してください。
ワークフローでプッシュ通知を送信するタイミングを設定する
one.newrelic.com > All capabilities > Alerts > Workflowsに移動して既存のワークフローをクリックするか、+Add a new workflowボタンをクリックしてモバイル通知機能を選択します。モバイルプッシュ通知を設定するには、モバイル通知機能アイコンをクリックし、目的の送信先を選択します。
Atlassian Opsgenie用Webhookテンプレート
ワークフローからOpsgenieに通知を送信するには、Webhookテンプレート（Opsgenieワークフロー用Webhookテンプレート）を使用します。
New RelicとPagerDutyを統合することで、PagerDutyのアラートを自動的に作成、更新、確認、解決できます。
PagerDutyとの連携方法は2種類あります。
Account level integration using REST API Keys (recommended)：完全に自動化されたインテグレーションです。双方向同期に加え、単一のNew Relic送信先に複数のPagerDutyサービスを設定できます。
Service integration using Events API keys：サービス単位のインテグレーションです。サービスレベルインテグレーションキーを使用し、PagerDutyサービスごとに個別のNew Relic送信先が必要となります。
アカウントレベルのインテグレーション
この完全に自動化されたインテグレーションでは、双方向同期に加え、単一のNew Relic送信先に複数のPagerDutyサービスを設定できます。
アクセス権限
このインテグレーションを利用するには、次のアクションを実行する権限が必要です。
このインテグレーションでは、REST APIキーが必要です。PagerDutyには2種類のREST APIキーがあります。
一般アクセスキー：上記のすべての権限が含まれており、PagerDutyの管理者とアカウント所有者がアクセスできます。PagerDutyの説明書を参照してください。
個人用ユーザートークン：アカウントに高度な権限が付与されている場合、固有の個人用REST APIキーを作成できます。個人用REST APIキーを使用して行われたリクエストは、そのユーザーの権限に制限されます。ユーザートークンAPIキーを発行する方法を用いる場合は、上記の必要な権限が含まれていることを確認してください。PagerDutyの説明書を参照してください。
ヒント
個人ユーザートークンを用いる場合は、実際のユーザーに属さない専用のインテグレーションユーザーを使用することが推奨されます。
アカウントレベルの送信先の作成中に、サービスインテグレーションを作成します。このキーを使用するため、このインテグレーションを削除しないでください。
送信先を設定する
PagerDuty送信先を作成する方法：
one.newrelic.com > All capabilities > Alertsに移動し、Destinationsをクリックしてから、PagerDutyを選択します。
以下の情報を入力してください。
Name：送信先を識別するためのカスタム名。
API Key：このインテグレーションでは、REST APIキーを提供するように求められます。PagerDutyには、一般アクセスとユーザートークンの2種類のREST APIキーがあります。
送信先を保存する前に、Test connectionボタンをクリックして接続を確認してください。
双方向同期
双方向同期を有効にするには、two-way integrationトグルをオンにしてください。オンにすると、選択したPagerDutyサービス用に、後日PagerDutyサブスクリプションが作成されます（メッセージテンプレートのカスタマイズを参照）。Webhookには、New Relicへのアクセス情報（URLとNew Relic APIキー）が含まれています。デフォルトでは、New Relicによって作成されたPagerDutyインシデントに対するステータス変更はすべてNew Relicに同期されます。
重要
PagerDuty Event IntelligenceまたはDigital Operationsの利用者で、特定のサービスでIntelligent Alert Groupingを使用している場合、New Relicに返送されるPagerDutyインシデントに不一致が発生する可能性があります。
New Relicとの同期
New Relicのイシューは、PagerDuty側でインシデントが解決したタイミングでクローズされます。
New Relicのイシューは、PagerDuty側でインシデントが確認済みとなったタイミングで確認済みとなります。
ワークフローでメッセージテンプレートを設定する
メッセージテンプレートを設定する方法：
- one.newrelic.com > All capabilities > Alerts> Workflowsに移動して既存のワークフローをクリックするか、+ Add a new workflowボタンをクリックしてPagerDuty通知機能を選択します。
- 既存の送信先を選択するか、新しい目的地を作成します。
- PagerDutyのサービスを選択します。
- ユーザーを選択します。New Relicは選択したユーザー名義でメモを投稿します。
- PagerDutyのCustom Detailsセクションに詳細情報を送信してください。デフォルトのペイロードを使用することも、イシューペイロード内の任意のテキストや動的変数を使用してカスタマイズすることもできます。変数メニューから変数を選択し、Handlebars構文を適用してペイロードを充実させることが可能です。右側のpreviewセクションには、テンプレートがレンダリングされた後に想定されるペイロードが表示されます。ペイロードが有効なJSON形式でない場合、エラーが表示され、テンプレートは保存できません。
PagerDutyアラートのカスタム詳細は自動入力されます。
テスト通知の送信
デフォルトのフィールド値が設定されたテスト通知をクリックすると、PagerDutyのインシデントがどのように表示されるかを確認できます。成功した場合、インシデントが作成され、リンクが表示されます。
サービスインテグレーション
このインテグレーションを利用するには、New Relicでインシデントを作成するサービスにNew Relic PagerDutyインテグレーションをセットアップする必要があります。PagerDutyサービスでNew Relicインテグレーションを作成する方法：
Services > Service Directoryに移動し、インテグレーションを追加するサービスを選択します。
Integrationsタブを選択してAdd an integrationをクリックします。
リストからNew Relicインテグレーションを見つけてマークし、Addをクリックします。
右側をクリックして、Integration Keyを表示させ、コピーしてください。
メッセージテンプレートを設定する
メッセージテンプレートを設定する方法：
one.newrelic.com > All capabilities > Alerts > Workflowsに移動して既存のワークフローをクリックするか、+ Add a new workflowボタンをクリックしてPagerDuty通知機能を選択します。
既存の送信先を選択するか、新しい目的地を作成します。
（任意）デフォルトのインシデント概要を編集します。
PagerDutyアラートのカスタム詳細は自動入力されます。
テスト通知の送信
デフォルトのフィールド値が設定されたテスト通知をクリックすると、PagerDutyのインシデントがどのように表示されるかを確認できます。
重要
メンテナンスモードのレガシーインテグレーションタイプです。このレガシーインテグレーションをまだセットアップしていない場合は、ServiceNow（認定アプリケーション）を参照してください。
New RelicをServiceNow ITSMと統合することで、ServiceNowのインシデントを自動的に作成、更新、解決できます。
ロール
インテグレーションの一環として、New RelicはServiceNowインシデントテーブルからフィールドやその他の任意の値を取得します。以下の権限が必要となります。
sys_dictionary、sys_choice、sys_user、taskの各テーブルに対する完全な読み取り権限。incidentへの読み取り／書き込み権限。caller列のユーザーを取得するには、sys_userテーブルへの読み取り権限が必要です。標準で用意されている
personalize_choices、personalize_dictionary、rest_service、snc_platform_rest_api_access、itilの各非詳細ロールには、上記の権限があります。双方向のインテグレーションを有効にするには、api_key_credentialsテーブルに対する読み取り／書き込み権限が必要です。credentials_adminとdiscovery_adminの各ロールにはこの権限があります。送信先を設定する
ServiceNowの送信先を作成する方法：
one.newrelic.com > All capabilities > Alertsに移動し、Destinationsをクリックしてから、ServiceNowを選択します。
以下の情報を入力してください。
Destination Name: 送信先を識別するためのカスタム名。
Domain: 送信先のURL。
Username: ユーザー名。
Password: ユーザーのパスワード。
送信先を保存する前に、Test connectionボタンをクリックして接続を確認してください。
双方向同期
two-way integrationを設定する方法：
two-way integrationトグルをオンにします。このXMLファイルを開いてダウンロードしてください。このファイルには、New Relicにイベントを返送するビジネスルールが含まれています。
ServiceNowのサイドバーメニューから、System Definition > Business Rulesに移動します。
いずれかの列ヘッダーにあるメニューアイコンをクリックし、Import XMLを選択して、ダウンロードしたXMLファイルをアップロードします。
送信先を保存すると、New Relic APIキーが
api_key_credentialsに保存されます。キーはNew RelicへのRESTコールバック呼び出しの一部としてヘッダーで送信されます。ワークフローと同期する
- New Relicのイシューは、ServiceNowでインシデントのステータスが解決済みに変更されたタイミングでクローズされます。
- New Relicのイシューは、ServiceNowでインシデントのステータスがオープンから変更されたタイミングで確認済みとなります。
ワークフローでメッセージテンプレートを設定する
one.newrelic.com > All capabilities > Alerts > Workflowsに移動して既存のワークフローをクリックするか、+ Add a new workflowボタンをクリックします。
ServiceNowの送信先を選択します。
接続が成功すると、ServiceNowインシデントテーブルの列がアカウントから取得され、ServiceNowインスタンスと自動的にマッピングされます。
必須項目と推奨項目にはデフォルト値があらかじめ入力されているため、すぐに使い始めることができます。対応しているフィールドにカスタム値を別途入力する場合、イシューペイロードから動的な値を追加するか、任意の値を入力することができます。非必須のフィールドは削除可能で、独自のフィールドを追加することもできます。
テスト通知の送信
Send test notificationをクリックすると、ServiceNowインシデントがデフォルトのフィールド値で表示されます。成功すると、作成されたインシデントへのリンクが表示されます。
ServiceNowインシデントテンプレートのフィールドを選択、編集、削除します。
New Relicワークフロー向けの認定済みServiceNowインテグレーションは、ServiceNowストアで入手できます。ServiceNowを使用する際は、以下の点に注意してください。
ServiceNowインスタンスはNew Relicのイシュー通知を
New Relic Issuesとして保存します。ServiceNowでは、ルーティングポリシーを設定しておくと、イシューが特定のポリシーに一致する場合、そのイシューに対応するタスクやその他のレコードを生成できます。
ServiceNowでの確認イベントまたはクローズイベントに応じて、New Relicでイシューの確認またはクローズを実行することができます。
New RelicのイシューをServiceNowで実行可能なタスクに自動変換できます。
ServiceNowは、New Relicからイシューに関する最新情報を受け取ることができます。
ポリシーエンジンを使用すると、New Relic の受信時に評価できます。
エンティティを設定項目に合わせて、利用可能なタスクテーブルに関連付けます。
ServiceNowから、New Relicの追加情報を画像として送信・表示できます。
ServiceNowアプリケーションの送信先またはWebhookの送信先を使用して、ServiceNowをNew Relicと統合できます。詳細、ヒント、ベストプラクティスについては、インストレーションガイドを参照してください。
送信先タイプ
ServiceNowアプリケーションの送信先
Webhookの送信先
ペイロード
New Relicによって管理されます。通知テンプレートはありません。タグを介したSNOW属性の変更が制限されます。
通知テンプレート内でペイロードを直接編集できます。
ServiceNowからNew Relicをアップデートする機能
含まれています。送信先が作成されると、New Relicの接続が自動的に作成されます。
含まれています。New Relicとの接続を手動で作成する必要があります。
ルーティングポリシー
含まれます。
含まれます。
ターゲットフィールドを直接更新する機能
エンティティのタグを、デフォルトのNew Relic Flowデザイナーと併用することで可能です。
エンティティのタグを使用し、Webhookペイロードで指定したうえで、デフォルトのNew Relic Flowデザイナーと併用することで可能です。
ServiceNowアプリケーションの送信先を設定する
重要
新しい送信先を作成する権限がない場合は、アカウント名とアカウント番号を添えてnotificationWorkflows@newrelic.comまでメールを送信してください。
ServiceNowの送信先を作成するには、以下の手順に従ってください。
ServiceNowストアでNew Relicアプリケーションをダウンロードし、インストールします。
ServiceNow内でユーザーを作成します。作成したユーザーにWeb service access onlyオプションを有効にし、
x_newre_core.inbound_apiロールを付与します。生成されたパスワードをコピーして保存します。one.newrelic.com > All capabilities > Alertsに移動し、Destinationsをクリックしてから、ServiceNowを選択します。
Nextをクリックします。
ドメイン、ユーザー名、パスワードを追加します。ドメインには
*.service-now.comを含める必要があります。手順2でコピーしたパスワードを入力します。Nextをクリックします。
送信先の名前を設定します。
Save destinationをクリックします。
通知ワークフローでこの通知先を使用します。
ヒント
New Relicから、Incident [インシデント]などのターゲットテーブルにあるServiceNowの属性を直接更新できます。これを行うには、アラート条件、APMエンティティ、外形監視、ホストなどの関連エンティティを
serviceNowFields.[serviceNow_value]またはserviceNowFields.dv_[serviceNow_name]でタグ付けします。例えば、APMエンティティをインシデントテーブルの設定項目として追加するには、serviceNowFields.dv_configuration_item : my_ciタグを付けます。Webhookの送信先を設定する
Webhookの送信先を作成するには、以下の手順に従ってください。
ServiceNowストアでNew Relicアプリケーションをダウンロードし、インストールします。
ServiceNow内でユーザーを作成します。作成したユーザーにWeb service access onlyオプションを有効にし、
x_newre_core.inbound_apiロールを付与します。生成されたパスワードをコピーして保存します。one.newrelic.com > All capabilities > Alertsに移動し、Destinationsをクリックしてから、Webhookを選択します。
以下のフィールドを入力します。
Webhook name：Webhookを識別するための名前。
Endpoint URL：送信先のエンドポイントURL。
*.service-now.com/api/x_newre_core/new_relic/issue/notificationを含める必要があります。例：https://my_instance.service-now.com/api/x_newre_core/new_relic/issue/notification。Use authorization：Basic authorizationオプションを有効にし、ユーザー名とコピーしたパスワードを入力して、ServiceNowを認証します。
Save destinationをクリックします。
以下のショート動画では、Webhook送信先の作成方法を確認できます。
Webhookペイロードに
serviceNowFieldsを追加する方法：one.newrelic.com > All capabilities > Alertsへ移動し、Workflowsをクリックします。
既存のWebhookのアイコンをクリックしてEditを選択するか、+ Add a new workflowボタンをクリックします。
Webhookチャネルをクリックします。
デフォルトのペイロードを変更し、必要な
serviceNowFields属性を追加します。
Send test notificationをクリックして変更内容を確認します。
Save messageをクリックします。
Activate workflowをクリックします。
Slackチャネルに通知メッセージを送信します。詳しくは、古いSlack Webhookの送信先から新しいSlackアプに移行する方法をご覧ください。
前提条件
SlackワークスペースにNew Relicアプリケーション（または、one.eu.newrelic顧客向けのEUアプリ）がインストールされている必要があります。アプリケーションを個別にインストールするには、ワークスペースアドミニストレーターがアプリケーションを承認する必要があります。
Authenticate in one clickボタンをクリックしてSlackのランディングページに移動し、OAuth2認証プロセスを進めます。必要なワークスペースにサインインしていない場合は、サインインのためにSlackにリダイレクトされます。
ワークスペース名を入力するか、該当するワークスペースを選択して、Continueをクリックします。
Allowをクリックして、目的のページに戻ります。
重要
各Slackワークスペースには、New Relicアカウントごとに固有の送信先が割り当てられています。
ワークフローでSlackメッセージテンプレートを設定する
ヒント
プライバシー保護のため、ユーザーはプライベートチャネルを選択する前に認証を完了する必要があります。プライベートチャネルを選択すると、ボットがそのチャネルに自動的に追加されます。
one.newrelic.com > All capabilities > Alerts > Workflowsに移動して既存のワークフローをクリックするか、+ Add a workflowボタンをクリックします。
メッセージの送信先（ワークスペースとも呼ばれます）とSlackチャネルを選択します。必要なワークスペースに対して既定の送信先がない場合は、新しい送信先を作成できます。
チャネル上で、イシューの承認や解決などのタイミングで通知を受け取るように設定することもできます。これはスレッドブロードキャストとも呼ばれます。
デフォルトの通知を使用することも、カスタム情報を追加して通知を充実させることもできます。変数メニューから変数を選択し、Handlebars構文を適用してペイロードを充実させることが可能です。
Send test notificationボタンをクリックすると、既定のサンプルペイロードを含むテスト通知がチャネルに送信されます。これにより、選択したSlackチャネルにメッセージが作成されます。
Splunk On-Call用Webhookテンプレート
Webhookテンプレートを使用してワークフローからSplunk On-Callに通知を送信する
ワークフローでWebhook通知機能を使用して、指定したHTTPSエンドポイントに通知メッセージを送信する必要があります。デフォルトでは、通知機能はリクエストのコンテンツタイプがJSONであると想定し、指定されたエンドポイントに対してHTTP POSTリクエストを送信します。設定を開始すると、Webhook通知機能はすぐに使用できるデフォルトのJSON構造を提供します。ただし、より詳細なカスタマイズが必要な場合は、Handlebarsテンプレート構文を使用してペイロードを変更できます。これにより、ペイロード内の変数を動的に設定し、特定のニーズに合わせてカスタマイズすることが可能になります。
ペイロードに加えて、Webhookリクエストに追加のHTTPヘッダーを含めることも可能です。これは、受信側のエンドポイントに追加情報や認証トークンを渡したいときに役立ちます。Webhookの設定方法に関するチュートリアル動画はこちらです。
Webhookの送信先を設定する
Webhookの送信先を作成するには、以下の手順に従ってください。
one.newrelic.com > All capabilities > Alertsに移動し、Destinationsをクリックしてから、Webhookを選択します。
以下の情報を入力してください。
- Webhook name: Webhookの参照名。
- Endpoint URL: HTTP POSTリクエストが送信されるターゲットアプリケーションのエンドポイント。
- Use authorization: （任意）
Basic AuthenticationまたはBearer Tokenいずれかを選択できます。
Webhookの扱いに慣れておらず、サービスを作成せずに設定のテストやWebhookペイロードの確認を行いたい場合は、HTTPキャッチオールサービスを利用できます。例えば、BeeceptorやWebhook.siteといったサービスでは、HTTPペイロードを受信してイベントのJSONペイロードを確認できる専用URLを利用できます。この機能を活用することで、開発プロセスを開始する前に関連情報を収集できます。
このペイロードを利用する新しいサービスを構築する場合は、ローカル環境でテストする必要があります。本番サーバーへの導入前にローカル環境でWebhookをテスト・デバッグする方法としては、ローカルトンネルの使用が適しています。ローカルトンネルを使用すると、New RelicからのWebhookリクエストをローカルマシンで受信できるため、開発中に公開サーバーを用意する必要がありません。Beeceptorやngrokのようなツールを使用すると、目的のポートまたはアドレスを指定してリクエストをローカルサーバーに転送する一時的な公開URLを作成できます。これにより、ローカル開発環境でWebhookを直接監視・分析できるため、再試行やデバッグを迅速に行うことができます。
双方向同期
ワークフローから送信された通知については、Nerdgraphを使用してイシューの確認やクローズが可能です。Webhookとの双方向同期をテストする場合、Beeceptorのカスタマイズされた応答ステータスとペイロードテンプレートを使用できます。これにより、受信したイベントを確認する際に、希望する応答文を事前に作成できます。
安全なURL
URLのパスやパラメーター（サービスIDやAPIキーなど）に機密情報を追加できます。こうした機密情報が露出するのを防ぐため、ドメイン以降の機密情報を暗号化し、ユーザーや内部メトリクス収集に対して表示されないようにするオプションを追加しました。
このサービスは、通知を送信する場合にのみ完全なURLを使用します。ただし、安全なURLを保存した後は、保存済みのURLを完全に上書きするために、URLを手動で更新する必要があります。
カスタムヘッダー認証
一部のユーザーは、APIキーや個人IDなどの機密情報をヘッダーに含めて送信する場合があります。機密情報の露出を防ぐため、値の暗号化とデータのマスクを行い、ユーザーや内部ログに表示されないようにするカスタムヘッダーを作成できます。以下の点に留意してください。
暗号化された情報の値が変更された場合は、その値を完全に削除して書き換える必要があります。
送信先とチャネルの両方に同じヘッダーキーを追加した場合、送信先が優先されます。このチャネルは使用されません。
Webhookイベントテンプレートを設定する
リストからWebhookの送信先を選択し、
HTTP-POSTリクエストを設定します。リクエストの設定には、以下が必要です。
テンプレートに名前を設定します。
送信先リストから既定の送信先を選択するか、新しい宛先を作成します。
カスタムヘッダーを追加します（任意）。
リクエストのペイロードを設定します。
ワークフローでWebhookペイロードをカスタマイズする
one.newrelic.com > All capabilities > Alerts > Workflowsに移動して既存のワークフローをクリックするか、+ Add a new workflowボタンをクリックしてWebhookの送信先を選択します。
重要
リクエストのcontent-typeはデフォルトでJSONなので、ペイロードもJSON形式にする必要があります。フォーマットについては、使用例をご覧ください。
デフォルトのペイロードを使用することも、必要なデータが含まれるようにカスタマイズすることもできます。変数メニューから変数を選択し、Handlebars構文を適用してWebhookを拡張します。右側のPreviewセクションには、テンプレートがレンダリングされた後に想定されるペイロードが表示されます。ペイロードが有効なJSON形式でない場合、エラーが発生し、テンプレートを保存できません。
ヒント
未定義の型エラーは、その属性が最近インデックス化されていないか、存在しないことを示している可能性があります。エラーを修正するには、
if elseステートメントを追加してください。例："closed_at": {{#if issueClosedAtUtc}} {{ json issueClosedAtUtc }} {{else}}"None"{{/if}}Webhookペイロードが有効なJSON形式に準拠している場合、既定のWebhook送信先にテスト通知を送信できます。すべてが正しく接続されていることを確認するため、テスト通知を送信してください。
xMatters用Webhookテンプレート
Webhookテンプレートを使用して、ワークフローからxMattersに通知を送信します。
{ {{#if nrAccountId}}"account_id": {{nrAccountId}},{{/if}} "account_name": {{json accumulations.tag.account.[0]}}, {{#if accumulations.tag.action}}"action":{{json accumulations.tag.action.[0]}},{{/if}} "closed_violations_count": { "critical": {{#if closedIncidentsCount}}{{closedIncidentsCount}}{{else}}0{{/if}}, "warning": 0, "total": {{#if closedIncidentsCount}}{{closedIncidentsCount}}{{else}}0{{/if}} }, "condition_family_id": {{accumulations.conditionFamilyId.[0]}}, "condition_id": {{accumulations.conditionFamilyId.[0]}}, "condition_name": {{json accumulations.conditionName.[0]}}, {{#if accumulations.evaluationName}}"condition_metric_name": {{json accumulations.evaluationName.[0]}},{{/if}} {{#if accumulations.evaluationMetricValueFunction}}"condition_metric_value_function": {{json accumulations.evaluationMetricValueFunction.[0]}},{{/if}} "current_state": {{#if issueClosedAt}}"closed"{{else if issueAcknowledgedAt}}"acknowledged"{{else}}"open"{{/if}}, "details": {{json issueTitle}}, "duration": {{#if issueDurationMs}}{{issueDurationMs}}{{else}}0{{/if}}, "event_type": "INCIDENT", "incident_acknowledge_url": {{json issueAckUrl}}, "incident_url": {{json issuePageUrl}}, "incident_id": {{json issueId}}, "metadata": { {{#if locationStatusesObject}}"location_statuses": {{locationStatusesObject}},{{/if}} {{#if accumulations.metadata_entity_type}}"entity.type": {{json accumulations.metadata_entity_type.[0]}},{{/if}} {{#if accumulations.metadata_entity_name}}"entity.name": {{json accumulations.metadata_entity_name.[0]}}{{/if}} }, "open_violations_count": { "critical": {{#if openIncidentsCount}}{{openIncidentsCount}}{{else}}0{{/if}}, "warning": 0, "total": {{#if openIncidentsCount}}{{openIncidentsCount}}{{else}}0{{/if}} }, "policy_name": {{json accumulations.policyName.[0]}}, {{#if policyUrl}}"policy_url": {{json policyUrl}},{{/if}} "radar_entity": { "accountId": {{json accumulations.tag.accountId.[0]}}, "domain": {{json accumulations.conditionProduct.[0]}}, "domainId": {{json issueId}}, "entityGuid": {{json entitiesData.entities.[0].id}}, "name": {{#if accumulations.targetName}}{{json accumulations.targetName.[0]}}{{else if entitiesData.entities}}{{json entitiesData.entities.[0].name}}{{else}}"NA"{{/if}}, "type": {{#if entitiesData.types.[0]}}{{json entitiesData.types.[0]}}{{else}}"NA"{{/if}} }, {{#if accumulations.runbookUrl}}"runbook_url": {{json accumulations.runbookUrl.[0]}},{{/if}} "severity": {{#eq HIGH priority}}"WARNING"{{else}}{{json priority}}{{/eq}}, "state": {{json state}}, "status": {{json status}}, "targets": [ { "id": {{#if entitiesData.entities.[0].id}}{{json entitiesData.entities.[0].id}}{{else if accumulations.nrqlEventType}}{{json accumulations.nrqlEventType.[0]}}{{else}}"N/A"{{/if}}, "name": {{#if accumulations.targetName}}{{json accumulations.targetName.[0]}}{{else if entitiesData.entities}}{{json entitiesData.entities.[0].name}}{{else}}"NA"{{/if}}, "link": {{json issuePageUrl}}, "product": {{json accumulations.conditionProduct.[0]}}, "type": {{#if entitiesData.types.[0]}}{{json entitiesData.types.[0]}}{{else}}"NA"{{/if}}, "labels": { {{#each accumulations.rawTag}}{{#if this.[0]}}"{{@key}}":{{json this.[0]}},{{/if}}{{/each}} "NewRelic": "targetLabels" } } ], "timestamp": {{#if closedAt}}{{closedAt}}{{else if acknowledgedAt}}{{acknowledgedAt}}{{else}}{{createdAt}}{{/if}}, "timestamp_utc_string": {{json issueUpdatedAt}}, "version": "1.0", {{#if accumulations.conditionDescription}}"VIOLATION DESCRIPTION": {{json accumulations.conditionDescription.[0]}},{{/if}} {{#if violationChartUrl}}"violation_chart_url": {{json violationChartUrl}},{{/if}} "violation_callback_url": {{json issuePageUrl}}}レガシーSlackの送信先を新しいSlackの送信先に移行する
レガシーSlackの送信先を新しいSlackの送信先に移行するには、次の手順に従います。
新しいSlackの送信先をセットアップします。
レガシーSlackの送信先に送信するワークフローごとに、次の操作を実行します。
- レガシー通知で送信されたSlackチャネルを見つけて保存します。
- 通知が正しく機能するかどうかテストしてください。
- 既存のレガシーSlackの通知機能を削除します。
- フィルターに一致する実際のイシュー（存在する場合）を確認するには、Test workflowをクリックします。
- ワークフローを保存します。