アラートとアプライド・インテリジェンス通知の統合

New Relic を Atlassian 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 宛先を作成するには、次の手順に従います。

1. one.newrelic.com > All capabilities > Alerts & AIに移動し、 Destinations [宛先を]クリックして、 Jiraを選択します。

2. 次の情報を入力します。

   • 名前: 宛先を識別するためのカスタム名。
   • URL: 宛先の URL。
   • ユーザー名: ユーザーの電子メール アドレス。
   • API トークン： アトラシアンアカウントから生成されたものです。

   宛先を保存する前に、 Test connection [接続のテスト] ボタンをクリックして接続を確認することをお勧めします。

   

   2ウェイ・シンク

   双方向同期はワークフローに適用できます。有効にするには、双方向統合トグルをオンにします。

   オンにすると、Jira アカウントに Jira Webhook が作成されます。Webhook には、New Relic へのアクセスの詳細 (URL と API キー) が含まれています。

   NewRelicのワークフローとの同期

• New Relic 問題のクローズは、JIRA 問題のステータスが doneに変化するとトリガーされます。

• New Relic 問題の承認は、JIRA 問題のステータスが in-progressに変化するとトリガーされます。

  ワークフローでメッセージ テンプレートを構成する

  Jira 課題のテンプレートを構成するには、次の手順に従います。

1. one.newrelic.com > All capabilities > Alerts & AI > ワークフロー に移動し、既存のワークフローをクリックするか、 + Add a new workflow [+ 新しいワークフローを追加] ボタンをクリックします。

2. 目的地を選択してください。この段階で新しい宛先を作成することもできます。

3. 接続先への接続が成功したら、プロジェクトを選択し、使用したいJiraの課題タイプを選択します。

4. 課題タイプが選択されると、設定されたプロジェクトのフィールドがアカウントから取得され、Jiraインスタンスに自動的にマッピングされます。

   開始しやすいように、必須および推奨のフィールドと値が自動的に入力されます。すべての必須フィールドに値を入力します。

   テスト通知の送信

   デフォルトのフィールド値を含むテスト通知をクリックして、JIRA の問題を確認します。

   成功すると、JIRA でインシデントを表示するためのリンクが表示されます。

   

NewRelicとAWSEventBridgeを使用して、AWS Lambda、Amazon Simple Notification Service（SNS）キュー、CloudWatchLogsなどのターゲットに通知をカスタマイズして配信します。

EventBridgeの宛先を設定します

AWS EventBridge 宛先を作成するには、次の手順に従います。

1. one.newrelic.com > All capabilities > Alerts & AIに移動し、 Destinations [宛先 を]クリックして、 AWS EventBridgeを選択します。

2. 次の情報を入力します。

   • 名前: 宛先を識別するためのカスタム名。

   • AWS リージョン: これは AWS リージョン エンドポイントです。イベント ソースがホストされているリージョンを選択します。

   • AWS アカウント ID: AWS アカウント ID。これは 12 桁の番号です。

     

   イベントソースを選択してください

   AWSアカウントIDを使用してEventBridgeの宛先を設定したら、新しいイベントソースを作成すると、EventBridgeで利用できるようになります。

3. 宛先名を選択または作成します。

4. イベントソースを選択または作成します。

   新しいイベントソースを作成すると、AWSEventBridgeアカウントに統合パートナーのイベントソースとして作成されます。

   AWSアカウントでイベントソースを関連付け、ルールを作成します

   イベント ソースをイベント バスに関連付けるには、次の手順を実行します。

5. AWS EventBridge コンソールのナビゲーションペインで Partner event sources [パートナー イベント ソース] を選択します。

6. パートナー イベント ソースの横にあるボタンを選択し、 Associate with event bus [イベント バスとの関連付け]を選択します。

   イベント ソースのステータスが Pending から Activeに変わり、イベント バスの名前がイベント ソース名と一致するように更新されます。これで、New Relic からのイベントに一致するルールの作成を開始できるようになりました。

7. イベント バスのルールを作成します。

   New Relic から送信された通知に対応するには、New-Relic イベントをフィルタリングするイベント パターンを使用してルールを作成する必要があります。

   

   詳細な手順については、イベントソースルールを作成する方法についてこのAWSドキュメントを使用してください。

   ワークフローでメッセージ イベント テンプレートを構成する

   ワークフローに移動し、既存のワークフローまたは Add a new Workflow [新しいワークフローの追加] ボタンをクリックして、eventbridge の宛先を選択します。New Relic から EventBridge に通知を送信する場合、メッセージ テンプレートを使用してその通知をカスタマイズできます。

   デフォルトのテンプレートを使用することも、独自のテンプレートをカスタマイズすることもできます。 変数メニュー から変数を選択し、 ハンドルバー構文 を適用してイベントを充実させます。

   EventBridgeAPIにはJSONが必要です。 JSONの使用例を参照してください。テンプレートプレビューには、レンダリングされたJSONが表示されます。

   イベントテンプレートが有効なJSONに準拠したら、テスト通知をAWSEventBridgeに送信できます。

ワークフローの通知チャネルとして [電子 メール] を選択すると、電子メールの 宛先が自動的に作成されるため、 [宛先] メニューから構成する必要はありません。各電子メールの宛先は、それに関連付けられたワークフローに固有であるため、宛先フィードに重複して表示される場合があります。

電子メール通知を送信するには:

1. one.newrelic.com > All capabilities > Alerts & AIに移動します。

2. 左側のナビゲーション パネルで [ワークフロー] を選択します。

3. [+ ワークフローを追加]をクリックします。

   

4. ワークフローの名称を入力してください。このフィールドは必須で、ユニークである必要があります。

5. 必要なデータをフィルタリングします。送信する問題を追加するには、 基本 オプションと 詳細 オプションのいずれかを選択できます。

6. [追加設定] をクリックして、データを充実させます。 [データを充実させる] を 有効にして、NRQL クエリを作成します。

7. [保存して終了]をクリックします。

8. 通知方法として 電子メールを 選択します。

   

9. 通知を送信するメールを追加します。1 人以上の受信者を追加できます。

   • メールアドレスを検索することで、New Relic アカウントを持つユーザーを見つけることができます。
   • New Relic アカウントやメール配信リストを持っていないユーザーを追加するには、そのユーザーの完全なメールアドレスを入力します。
   • メール設定に追加されたメール アドレスの各リストは、独自の一意の宛先を作成し、宛先フィードに表示されます。
   • 通知ログで宛先ごとの電子メール通知を追跡できます。

10. 電子メール メッセージをカスタマイズします。

    • 電子メールの件名については、デフォルトのペイロードを使用するか、必要なデータを含めるようにカスタマイズできます。
    • メール本文には、変更できないデフォルト データが含まれていますが、独自のカスタマイズされた詳細情報を追加することもできます。これらのカスタマイズは、 [カスタムの詳細] セクションに表示されます。
    • メールを充実させるには、変数メニューから変数を選択し、ハンドルバーの構文を適用します。

11. [テスト通知を送信] をクリックして、電子メール通知が受信トレイに届くことを確認します。

12. クリック 保存.

13. [ワークフローを有効にする]をクリックします。

    ワークフローのメイン ページから、ワークフロー ID を有効化、編集、削除、または作成したワークフローをクリップボードにコピーできます。

New Relic を FreshService と統合して、FreshService チケットを自動的に作成して解決します。

Webhook を使用して FreshService 宛先を設定する

1. one.newrelic.com > Alerts & AIに移動し、 Destinations [宛先]をクリックして、 Webhookを選択します。

2. 次の情報を入力します。

   • Webhook 名: FreshService Webhook の参照名。

   • エンドポイント URL: https://yourdomain.freshservice.com/api/v2/tickets(ドメインを FreshService ヘルプ デスク名に置き換えます)

   • 認証を有効にし、基本認証を選択します。ユーザー名とパスワードに次の情報を入力します。

     • Username [ユーザー名]: FreshService API キー
     • Password [パスワード]: X (パスワードは大文字の X です)

3. 保存先。

   ワークフローを作成し、ワークフロー変数を使用して FreshService 属性をカスタマイズする

4. one.newrelic.com > Alerts & AI に移動し、 Workflows [ワークフロー]をクリックします。+ Add a new workflow [+ 新しいワークフローを追加]をクリックします。

5. ワークフローの名前を入力します。

6. [データのフィルター] で、通知を宛先に送信するための希望のフィルター基準を作成します。

7. [通知] で[Webhook]を選択し、次の情報を使用して通知メッセージをカスタマイズします。

   • 「宛先」フィールドで、上記の手順で作成した FreshService 宛先を選択します。

   • ペイロードをカスタマイズして、 ワークフロー変数を関連するFreshService パラメーターに送信します。(ペイロードのサンプルを参照)

     • ワークフロー変数のヘルパー関数の詳細については、 「ハンドルバーの構文」を参照してください。
     • カスタム フィールドの追加については、 「FreshService カスタム フィールド」を参照してください。
     • ワークフロー変数のタイプは FreshService パラメータのタイプと一致する必要があります。

8. 「テスト通知を送信」をクリックして通知をテストします。FreshService チケットに移動して、新しく作成されたチケットを表示します。

   サンプルペイロード

   {
     "subject": {{ json annotations.title.[0] }},
     "description": "{{ issuePageUrl }}",
     "priority": 1,
     "status": {{#eq state "ACTIVATED"}}2{{else}}5{{/eq}},
     "email": "supportemail@domain.com",
     "custom_fields": {
       "nr_account_id": {{ nrAccountId }}
     }
   }

   コピー

New Relic iOS または Android モバイルアプリにプッシュ通知を送信します。

モバイル プッシュ先を設定する

モバイル プッシュの宛先を作成するには、次のものが必要です。

• プッシュ宛先名:固有の宛先名。

• ユーザー ID:現在ログインしているユーザーに基づいて自動的に入力されます。

  重要

  現在、 変更機能を持つ現在ログインしているユーザーのモバイル プッシュ先の作成に制限されています。 ユーザーのプッシュ先は 1 つだけ作成できます。複数作成しようとすると、エラーが表示されます。宛先を保存する前に、 [接続のテスト] ボタンを使用して接続をテストすることをお勧めします。

  ワークフローでプッシュ通知を受け取るタイミングを構成する

  one.newrelic.com > All capabilities > Alerts & AI > Workflows に移動し、既存のワークフローをクリックするか、 +Add a new workflow [+新しいワークフローを追加] ボタンをクリックしてモバイル通知を選択します。モバイル プッシュを設定するには、モバイル通知をクリックし、目的の宛先を選択します。

Atlassian Opsgenie の Webhook テンプレート

Webhook テンプレートを使用してワークフローから Opsgenie に通知を送信する ワークフロー用の Opsgenie Webhook テンプレート

New Relic を PagerDuty と統合して、PagerDuty インシデントを自動的に作成、更新、確認、解決します。

PagerDutyと統合する方法は2つあります。

• REST API キーを使用したアカウントレベルの統合（推奨） : 統合は完全に自動化されており、双方向の同期をサポートし、単一の New Relic デスティネーションに複数の PagerDuty サービスを定義することができます。

• イベントAPIキーを使用したサービス統合：単一のサービス統合はサービスレベル統合キーを使用し、一意のPagerDutyサービスごとに個別のNewRelic宛先が必要です。

  アカウントレベルの統合

  統合は完全に自動化されており、双方向の同期をサポートし、1つのNew Relicデスティネーションに複数のPagerDutyサービスを定義することができます。

  権限

  この統合には、以下のアクションを実行する権限が必要です。

• リストサービス

• インテグレーションの作成

• Webhookサブスクリプションの作成

• ノートの作成

• リストチーム

• ユーザー一覧

  この統合には、REST API キーが必要です。PagerDuty には 2 種類の REST API キーがあります。

• 一般アクセス キー: 上記のすべての権限が含まれており、PagerDuty 管理者とアカウント所有者がアクセスできます。PagerDuty の説明を参照してください。

• パーソナルユーザートークン: お客様のアカウントに高度な権限がある場合、固有のパーソナルREST APIキーを作成することができます。個人用REST APIキーを使用して行われたリクエストは、ユーザーのパーミッションに制限されます。ユーザートークンAPIキーを提供することを選択した場合、それが上記の必要なパーミッションを持っていることを確認してください。 PagerDutyの説明書をご覧ください.

  ヒント

  個人ユーザー トークンの場合、実際のユーザーに属さない専用の統合ユーザーを使用することをお勧めします。

  デスティネーションの設定

  PagerDuty 宛先を作成するには、次の手順に従います。

1. one.newrelic.com > All capabilities > Alerts & AIに移動し、 Destinations [宛先を]クリックして、 PagerDutyを選択します。

2. 次の情報を入力します。

   • Name: 目的地を特定するためのカスタム名。
   • API キー: この統合では、REST API キーを提供するように求められます。PagerDuty には、 一般アクセス トークン と ユーザー トークンという2 種類の REST API キーがあります。

   デスティネーションを保存する前に、 Test connection ボタンをクリックして、接続をテストすることをお勧めします。

   

   2ウェイ・シンク

   双方向の同期を有効にするには、 双方向の統合 のトグルをオンにします。

   オンにすると、選択した PagerDuty サービスに対して、後から PagerDuty のサブスクリプションが作成されます (See customize a message template)。Webhook には、New Relic へのアクセス詳細 (URL および New Relic API キー) が含まれます。

   デフォルトでは、New Relicによって作成されたPagerDutyのインシデントの状態が変更されると、New Relicに同期されます。

   重要

   特定のサービスで Intelligent Alert Grouping を使用している PagerDuty Event Intelligence または Digital Operations の顧客の場合、New Relic に送り返される PagerDuty インシデントに潜在的な不一致が存在する可能性があることに注意してください。

   New Relicのワークフローとの同期

• PagerDuty のインシデントが解決されると、New Relic issue の閉鎖がトリガーされます。

• PagerDuty のインシデントが承認されると、New Relic のインシデントの承認がトリガーされます。

  ワークフローでメッセージ テンプレートを構成する

  メッセージテンプレートを設定するには

1. one.newrelic.com > All capabilities > Alerts & AI > Workflows に移動し、既存のワークフローをクリックするか、 + Add a new Workflow [+ 新しいワークフローを追加] ボタンをクリックして、PagerDuty 通知機能を選択します。

2. 目的地を選択してください。この段階で新しい宛先を作成することもできます。

3. PagerDutyのサービスを選択します。

4. ユーザーを選択します。選択したユーザーに代わって、New Relic がノートを投稿します。

5. Pagerduty の Custom Details セクションに詳細を送信します。デフォルトのペイロードを使用するか、課題ペイロードのフリー テキストまたは動的変数を使用してカスタマイズできます。 変数メニュー から変数を選択し、 ハンドルバー構文 を適用してペイロードを充実させます。 右側の プレビュー セクションには、テンプレートがレンダリングされた後に予想されるペイロードが表示されます。 ペイロードが有効な JSON を形成しない場合、エラーが表示され、テンプレートを保存できません。

   なお、PagerDuty Alertsのカスタム詳細は自動的に入力されます。

   テスト通知の送信

   デフォルトのフィールド値を含むテスト通知をクリックすると、PagerDuty インシデントがどのように表示されるかを確認できます。成功すると、インシデントが作成され、リンクが表示されます。

   

   サービス統合

   この統合では、NewRelicでインシデントを作成するサービスにNewRelicPagerDuty統合を設定する必要があります。

   PagerDuty サービスで New Relic 統合を作成するには、次の手順に従います。

6. Services > Service Directory に移動し、統合を追加するサービスを選択します。

7. Integrations [統合] タブを選択し、 Add an integration [統合の追加]をクリックします。

8. リスト内で New Relic 統合を見つけてマークし、 Add 「追加」をクリックします。

   

9. 右側をクリックして Integration Key [統合キー]を表示し、コピーします。

   

   メッセージテンプレートの設定

   メッセージテンプレートを設定するには

10. one.newrelic.com > All capabilities > Alerts & AI > Workflows に移動し、既存のワークフローをクリックするか、 + Add a new workflow [+ 新しいワークフローを追加] ボタンをクリックして、PagerDuty 通知機能を選択します。

11. 目的地を選択してください。この段階で新しい宛先を作成することもできます。

12. (オプション）デフォルトのインシデントサマリーを編集します。

    なお、PagerDuty Alertsのカスタム詳細は自動的に入力されます。

    テスト通知の送信

    デフォルトのフィールド値でテスト通知をクリックすると、PagerDutyのインシデントがどのように表示されるかを確認できます。

New Relic を ServiceNow ITSM と統合し、ServiceNow インシデントを自動的に作成、更新、解決します。

役割

統合の一環として、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 宛先を作成するには、次の手順に従います。

1. one.newrelic.com > All capabilities > Alerts & AIに移動し、 Destinations をクリックして、 ServiceNowを選択します。

2. 次の情報を入力します。

   • デスティネーション名： デスティネーションを識別するためのカスタム名。
   • ドメイン： 送信先のURLです。
   • Username [ユーザー名]: ユーザーの名前。
   • パスワード： ユーザーのパスワードです。

   デスティネーションを保存する前に、 Test connection ボタンをクリックして、接続をテストすることをお勧めします。

   2ウェイ・シンク

   双方向統合を設定するには:

3. two-way integrationトグルをオンにします。

4. この XML ファイルを開いてダウンロードします。この XML ファイルには、New Relic にイベントをトリガーするビジネス ルールが含まれています。

5. ServiceNowのサイドバーメニューで、 System Definition> Business Rules を選択します。

6. いずれかの列ヘッダーのメニュー アイコンをクリックし、[ XML のインポート] を選択して、ダウンロードした XML ファイルをアップロードします。

   宛先が保存されると、New Relic API キーは api_key_credentialsに保持されます。キーは、New Relic への REST コールバック呼び出しの一部としてヘッダーで送信されます。

   ワークフローとの同期

• ServiceNow インシデントの状態が解決済みに変わると、New Relic の問題のクローズがトリガーされます。

• ServiceNow インシデントの状態がオープンから変化すると、New Relic の問題の承認がトリガーされます。

  ワークフローでメッセージ テンプレートを構成する

1. one.newrelic.com > All capabilities > Alerts & AI > Workflows に移動し、既存のワークフローをクリックするか、 + Add a new workflow [+ 新しいワークフローを追加] ボタンをクリックします

2. ServiceNow の宛先を選択します。

3. 接続が成功すると、ServiceNowのインシデントテーブルのカラムがアカウントから取得され、自動的にServiceNowインスタンスにマッピングされます。

   開始しやすいように、必須フィールドと推奨フィールドにはデフォルト値が事前に入力されています。

   サポートされているフィールドにカスタム値を追加する場合、課題ペイロードから動的な値を追加するか、独自の値を書き込むことができます。

   不要なフィールドを削除して、独自のフィールドを追加できます。

   テスト通知の送信

   Send test notification [テスト通知の送信] をクリックすると、デフォルトのフィールド値を持つ ServiceNow インシデントが表示されます。成功すると、作成されたインシデントへのリンクが表示されます。

   

認定された Servicenow と New Relic Workflows の統合は、ServiceNow ストアで入手できます。この統合について詳しくは、 フォーラムをご覧ください。

デスティネーションの設定

ServiceNow 宛先を作成するには、次の手順に従います。

1. ServiceNow ストアで New Relic アプリケーションをダウンロードし てインストールします。

2. one.newrelic.com > All capabilities > Alerts & AIに移動し、 Destinations [宛先を] クリックして Webhookを選択します。

3. 次のフィールドに入力します。

   • Destination Name [宛先名]：宛先を識別するための名前。
   • Domain [ドメイン]: 宛先のエンドポイント 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。
   • Username [ユーザー名]: ServiceNow を認証するユーザーの名前。 x_newre_core.inbound_api 権限が必要です。
   • Password [パスワード]: ServiceNow を認証するためのユーザーのパスワード。

4. Servicenow ストアからInstallation Guide [インストール ガイド]をダウンロードし、その指示に従います。

Slackのチャンネルに通知メッセージを送信します。

詳細については 、古い Slack Webhook 宛先から新しい Slack アプリに移行する 方法をご覧ください。

前提条件

Slack ワークスペースに は、New Relic アプリケーション(または、 one.eu.newrelic の顧客の場合は EU アプリ ) がインストールされている必要があります。アプリケーションを個別にインストールするには、ワークスペース管理者がアプリケーションを承認する必要があります。アプリのサポートについては、 support@newrelic.com までお問い合わせください。

Slackの宛先を設定する

1. one.newrelic.com > All capabilities > Alerts & AIに移動し、 Destinations [宛先を]クリックして、 Slackを選択します。

2. Authenticate in one click [ワンクリックで認証] ボタンをクリックして Slack ランディング ページに移動し、OAuth2 認証プロセスを続行します。必要なワークスペースにサインインしていない場合は、サインインするために Slack にリダイレクトされます。

   

3. ワークスペース名を追加するか、関連するワークスペースを選択して、 「続ける」 をクリックします。

   

4. 選択したワークスペースにサインインしている場合、New Relic が指定されたアクションを実行することを許可します。

   

5. Allow をクリックすると、目的のページに戻ります。

   

   Slack の統合は特定のユーザーに関連付けられていません。最初に Slack で認証したユーザーが組織を退職した場合、またはそのアカウントが削除された場合でも、Slack の宛先は引き続き機能します。Slack で認証すると、プラットフォームは Slack にアクセスして OAuth トークンを要求します。このトークンはある時点で期限切れになり、元のトランザクションのトークンで更新されます。

   Slack ワークスペースが存在する限り、元の Slack アカウントが削除されても通知を受け取り続けます。個々のユーザー アカウントは認証とは何の関係もありません。このアカウントにより、Slack とのハンドシェイクを実行する許可が与えられます。そのデータを取得すると、認証されます。

   ワークフローで Slack メッセージ テンプレートを構成する

6. one.newrelic.com > All capabilities > Alerts & AI > Workflows に移動し、既存のワークフローをクリックするか、 + Add a workflow [+ ワークフローを追加] ボタンをクリックします。

7. メッセージを送信する宛先 (ワークスペース) と Slack チャネルを選択します。必要なワークスペースに事前定義された宛先がない場合は、新しい宛先を作成できます。プライバシー上の理由から、ユーザーはプライベート チャネルを選択するために一度認証を受ける必要があります。プライベート チャネルを選択すると、ボットが自動的にチャネルに追加されます。

8. デフォルトの通知を使用することも、カスタムの詳細で強化することもできます。変数メニューから変数を選択し、ハンドルバー構文を適用してペイロードを充実させます。

9. Send test notification [テスト通知を送信] ボタンをクリックして、事前定義されたサンプル ペイロードを含むテスト通知をチャネルに送信します。これにより、選択した Slack チャネルにメッセージが作成されます。

   

Splunk オンコールの Webhook テンプレート

Webhook テンプレートを使用してワークフローから Splunk On-call に通知を送信する

ワークフローで Webhook 通知機能を使用して、指定された HTTPS エンドポイントに通知メッセージを送信する必要があります。デフォルトでは、Notifier はリクエストのコンテンツ タイプが JSON であると想定し、指定されたエンドポイントに対して HTTP POST リクエストを作成します。Webhook Notifier の構成を開始すると、すぐに使用できるデフォルトの JSON ペイロード構造が提供されます。ただし、さらにカスタマイズが必要な場合は、Handlebars テンプレート構文を使用してペイロードを変更できます。これにより、ペイロード内の変数を動的に設定し、特定のニーズに合わせて調整することができます。

ペイロードに加えて、Webhook リクエストに追加の HTTP ヘッダーを含めることもできます。これは、追加情報または認証トークンを受信側エンドポイントに渡す場合に役立ちます。Webhook を設定するためのビデオチュートリアルは次のとおりです。

Webhookの宛先を設定する

Webhook 宛先を作成するには、次の手順に従います。

1. one.newrelic.com > All capabilities > Alerts & AIに移動し、 Destinations [宛先を]クリックして、 Webhookを選択します。

2. 次の情報を入力します。

   • Webhook 名: Webhook の参照名。

   • Endpoint URL: [エンドポイント URL:] HTTP POST リクエストが送信されるターゲット アプリケーションのエンドポイント。

   • 承認を使用する: (オプション) Basic Authentication または Bearer Tokenから選択できます。

     

   Webhook の操作に慣れておらず、サービスを作成せずに構成をテストして Webhook ペイロードを検査したい場合は、HTTP キャッチオール サービスを使用できます。Beeceptor と Webhook.site は 、HTTP ペイロードを受信してイベントの JSON ペイロードを検査できる指定された URL を提供するサービスの例です。この機能は、開発プロセスを開始する前に関連情報を収集するのに役立ちます。

   このペイロードを使用する新しいサービスを構築している場合は、ローカルでテストする必要があります。実稼働サーバーにデプロイする前に、ローカル環境で Webhook をテストおよびデバッグするには、ローカル トンネルを使用することをお勧めします。これらのトンネルを使用すると、New Relic からの Webhook リクエストをローカル マシンで受信できるため、開発中にパブリックにアクセスできるサーバーが必要なくなります。Beeceptor や ngrok などのツールを使用すると、目的のアプリケーション ポートまたはアドレスを指定してリクエストをローカル サーバーに転送する一時的なパブリック URL を作成できます。これにより、ローカル開発環境で Webhook ペイロードを直接観察して分析できるため、反復とデバッグが迅速化されます。

   2ウェイ・シンク

   ワークフローから送信された通知については、 Nerdgraphを使用して問題を承認またはクローズできます。

   Webhook を使用した双方向同期をテストしている場合は、Beeceptor のカスタマイズされた応答ステータスとペイロード テンプレートを使用できます。これにより、受信したイベントを確認するときに、必要な応答を草案することができます。

   Webhookイベントテンプレートの設定

   リストからWebhookの宛先を選択し、 HTTP-POSTリクエストを設定します。

   リクエスト設定では、以下のことが求められます。

3. テンプレートの名前を設定します。

4. あらかじめ設定されている目的地を目的地リストから選択するか、新しい目的地を作成します。

5. カスタムヘッダーの追加（オプション）。

6. リクエストのペイロードを設定します。

   ワークフローで Webhook ペイロードをカスタマイズする

   one.newrelic.com > All capabilities > Alerts & AI > Workflows に移動し、既存のワークフローをクリックするか、 + Add a new workflow [+ 新しいワークフローを追加] ボタンをクリックして Webhook 宛先を選択します。

   重要

   リクエストの content-type はデフォルトで JSON であるため、ペイロードも JSON 形式である必要があります。形式に慣れるには、使用例を参照してください。

   デフォルトのペイロードを使用することも、必要なデータを含むようにカスタマイズすることもできます。 variablesメニュー から変数を選び、 handlebars構文 を適用して、Webhookを充実させます。

   右側の [プレビュー]セクションには、テンプレートがレンダリングされた後に予想されるペイロードが表示されます。ペイロードが有効な 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}}
}