アラート 通知 インテグレーション

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に移動し、 Destinationsをクリックして、 Jiraを選択します。

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

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

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

   

   2ウェイ・シンク

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

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

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

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

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

  Workflowsでメッセージ テンプレートを構成する

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

1. one.newrelic.com > All capabilities > Alerts > Workflowsに移動して既存のワークフローをクリックするか、 + Add a new workflowボタンをクリックします。

2. 既存の宛先を選択するか、新しい宛先を作成します。

3. 宛先に接続したら、プロジェクトを選択し、使用する Jira 課題タイプを選択します。

4. 課題タイプを選択すると、構成されたプロジェクトのフィールドが Jira インスタンスに自動的にマッピングされます。

   開始しやすいように、必須および推奨のフィールドと値が自動的に入力されます。続行する前に、すべての必須フィールドに値が含まれていることを確認してください。

   テスト通知の送信

   デフォルトのフィールド値を含むテスト通知をクリックすると、Jira の課題が表示されます。成功すると、Jira でインシデントを表示するためのリンクが表示されます。

   

New Relic とAWS EventBridgeを使用して、AWS Lambda、Amazon シンプル通知サービス (SNS) キュー、CloudWatch ログなどのターゲットに通知をカスタマイズして配信します。

EventBridgeの宛先を設定します

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

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

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

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

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

   • AWS account 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ドキュメントを使用してください。

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

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

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

   EventBridge API には JSON が必要で、テンプレート プレビューにはレンダリングされた JSON が表示されます。イベントテンプレートが有効な JSON に準拠すると、テスト通知を AWS EventBridge に送信できます。詳細については、 JSON の使用例を参照してください。

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

電子メール通知のアラートのワークフローを構成するには:

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

2. 左側のナビゲーション パネルでWorkflowsを選択します。

3. + Add a workflowをクリックします。

   

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

5. 必要なデータをフィルタリングします。 BasicとAdvancedのオプションから選択して、送信する問題を追加できます。

6. データを充実させたり、ミュートされた問題の通知設定を構成したりするには、 Additional settingsをクリックします。

   • データを拡充するには、 Enrich your data有効にし、NRQL クエリを構築して、保存して終了します。
   • ミュートされた問題の通知設定を構成するには、要件に応じて利用可能なオプションのいずれかを選択します。

7. 通知方法としてEmailを選択します。

   

8. 受信者を追加: 受信者の名前またはメール アドレスを入力します。そのユーザーがいる目的地がフィードに表示されるので、いずれかを選択します。ユーザーの新しい宛先を作成する場合:

   1. フィードからCreate new destinationクリックします。

   2. Add a destinationページで、メール ID またはユーザー名を検索して受信者を追加し、送信先の一意の名前を入力して保存します。

      • 電子メール アドレスが既存の宛先にすでに関連付けられている場合は、それらを結合するように求められます。 宛先を結合するには、 Mergeを選択します。
      • 新しいメールアドレスを追加した場合、受信者は確認メールを受け取ります。通知の受信を開始するには、受信者は検証プロセスを完了する必要があります。

      重要

      メール送信先の制限:

      • 無料アカウント: 各送信先には最大 5 つの電子メール アドレスを設定できます。
      • 有料アカウント: 各送信先には最大 150 個のメール アドレスを設定できます。
      • 組織の制限: カスタマー組織ごとに 24 時間あたり 1000 件の固有の電子メール アドレスを追加できます (すべてのユーザーに適用されます)。

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

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

10. Send test notificationをクリックして、電子メール通知が受信箱に届くことを確認します。

11. Saveをクリックします。

12. 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 テンプレート

Webhook テンプレートを使用してワークフローから Opsgenie に通知を送信する:ワークフロー用の 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 サービスを定義する機能をサポートします。

  権限

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

• リストサービス

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

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

• ノートの作成

• リストチーム

• ユーザー一覧

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

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

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

  ヒント

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

  アカウント レベルの宛先の作成中に、サービス インテグレーションを作成します。 このインテグレーションはキーを使用するため、削除しないでください。

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

  PagerDutyのデスティネーションを作成するには

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

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

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

   • API Key: この統合では、REST API キーを提供するように求められます。 PagerDuty には、 一般アクセス トークンとユーザー トークンの 2 種類の REST API キーがあります。

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

     

   2ウェイ・シンク

   双方向同期を有効にするには、 two-way integrationトグルをオンにします。 オンにすると、選択した PagerDuty サービスに対して後の段階で PagerDuty サブスクリプションが作成されます (メッセージ テンプレートのカスタマイズを参照)。 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> Workflowsに移動して既存のワークフローをクリックするか、 + Add a new workflowボタンをクリックして PagerDuty 通知機能を選択します。
  2. 宛先を選択するか、新しい宛先を作成します。
  3. PagerDutyのサービスを選択します。
  4. ユーザーを選択します。選択したユーザーに代わって、New Relic がノートを投稿します。
  5. 詳細をPagerDutyのカスタム詳細セクションに送信します。 デフォルトのペイロードを使用することも、課題ペイロードのフリー テキストまたは動的変数を使用してカスタマイズすることもできます。 変数メニューから変数を選択し、ハンドルバー構文を適用してペイロードを強化します。 右側のpreviewセクションには、テンプレートがレンダリングされた後に予想されるペイロードが表示されます。 ペイロードが有効な JSON を形成していない場合は、エラーが表示され、テンプレートを保存できません。

  PagerDuty アラートのカスタム詳細は自動的に入力されます。

  テスト通知の送信

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

  

  サービス統合

  この統合では、New Relic でインシデントを作成するサービスに New Relic PagerDuty 統合をセットアップする必要があります。PagerDuty サービスで New Relic 統合を作成するには:

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

2. Integrationsタブを選択し、 Add an integrationをクリックします。

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

   

4. 右側をクリックして、 Integration Keyを表示してコピーします。

   

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

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

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

6. 宛先を選択するか、新しい宛先を作成します。

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

   なお、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に移動し、 Destinationsをクリックして、 ServiceNowを選択します。

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

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

   • Domain: 宛先の URL。

   • Username: ユーザーの名前。

   • Password: ユーザーのパスワード。

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

     2ウェイ・シンク

     two-way integrationを構成するには:

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

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

   3. ServiceNow サイドバー メニューで、 System Definition > Business Rulesに移動します。

   4. いずれかの列ヘッダーにあるメニュー アイコンをクリックし、 Import XMLを選択して、ダウンロードした XML ファイルをアップロードします。

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

      ワークフローとの同期

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

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

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

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

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

   簡単に開始できるように、必須フィールドと推奨フィールドにはデフォルト値が事前に入力されています。サポートされているフィールドにカスタム値を追加する場合、課題ペイロードから動的な値を追加することも、独自の値を書き込むこともできます。必須でないフィールドを削除して、独自のフィールドを追加できます。

   テスト通知の送信

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

   

認定された ServiceNow と New Relic ワークフローの統合は、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 デザイナーとともにエンティティのタグを使用します。	はい、エンティティのタグを使用し、デフォルトの New Relic Flow デザイナーとともに Webhook ペイロードで指定します。

  ServiceNow アプリケーションの宛先を設定する

  重要

  新しい宛先を作成するためのアクセス権がない場合は、アカウント名とアカウント番号を記載した電子メールをnotificationWorkflows@newrelic.comに送信してください。

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

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

2. ServiceNow 内でユーザーを作成します。 必ずWeb service access onlyオプションを有効にし、作成したユーザーにx_newre_core.inbound_apiロールを付与してください。 生成されたパスワードをコピーして保存します。

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

   

4. Nextをクリックします。

5. ドメイン、ユーザー名、パスワードを追加します。ドメインには*.service-now.comを含める必要があります。手順 2 でコピーしたパスワードを追加します。

6. Nextをクリックします。

7. 目的地に名前を付けます。

8. Save destinationをクリックします。

9. 通知ワークフローでこの宛先を使用します。

   ヒント

   から直接 、インシデント などのターゲット テーブル内の ServiceNow 属性を直接更新できます。New Relicこれを行うには、アラート条件、 APMアプライアンス、外形監視、ホストなどのタグ関連のアプライアンスを serviceNowFields.[serviceNow_value] または serviceNowFields.dv_[serviceNow_name] で指定します。 たとえば、 APMアイテムをインシデント テーブルの設定項目として入力するには、serviceNowFields.dv_configuration_item : my_ci でタグを付けます。

   Webhook の宛先を設定する

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

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

11. ServiceNow 内でユーザーを作成します。 必ずWeb service access onlyオプションを有効にし、作成したユーザーにx_newre_core.inbound_apiロールを付与してください。 生成されたパスワードをコピーして保存します。

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

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

    • 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 を認証します。

      

14. Save destinationをクリックします。

    Webhook 宛先の作成方法を示す短いビデオを以下に示します。

    Webhook ペイロードにserviceNowFieldsを追加するには:

15. one.newrelic.com > All capabilities > Alertsに移動し、 Workflowsをクリックします。

16. クリック既存の Webhook のアイコンをクリックしてEditを選択するか、 + Add a new workflowボタンをクリックします。

17. Webhookチャンネルをクリックします。

18. 必要なserviceNowFields属性を追加して、デフォルトのペイロードを変更します。

    

19. Send test notificationをクリックして変更を確認します。

20. Save messageをクリックします。

21. Activate workflowをクリックします。

通知メッセージを Slack チャネルに送信します。詳細については、古い Slack Webhook 宛先から新しい Slack アプリに移行する方法をご覧ください。

前提条件

Slack ワークスペースにNew Relic アプリケーション(またはone.eu.newrelic顧客向けのEU アプリ) がインストールされている必要があります。アプリケーションを個別にインストールするには、ワークスペース アドミニストレーターがアプリケーションを承認する必要があります。

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

2. ワークスペース名を入力するか、関連するワークスペースを選択して、 Continueクリックします。

3. Allowをクリックして、目的のページに戻ります。

   重要

   各 Slack ワークスペースには、New Relic アカウントごとに固有の宛先があります。

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

   ヒント

   プライバシー上の理由から、ユーザーはプライベート チャネルを選択する前に認証を受ける必要があります。 プライベート チャネルを選択すると、ボットが自動的にチャネルに追加されます。

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

5. メッセージを送信する宛先 (ワークスペースとも呼ばれます) と Slack チャネルを選択します。 必要なワークスペースに事前定義された宛先がない場合は、新しい宛先を作成できます。

6. 問題が承認されたときや解決されたときなどの通知更新をチャネルで受け取るように選択することもできます。 これはスレッドブロードキャストとも呼ばれます。

   

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

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

   

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

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

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

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

Webhookの宛先を設定する

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

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

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

   • 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 ペイロードを直接観察して分析できるため、反復とデバッグが迅速化されます。

   2ウェイ・シンク

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

   安全なURL

   URL のパスと構造体に、サービス ID や API キーなどの機密情報を追加できます。 これらの秘密が公開されるのを避けるために、ユーザーと内部メトリックス コレクションの両方からドメインを越えた機密情報を暗号化するオプションを追加しました。

   サービスは通知を送信するときにのみ完全な URL を使用します。 ただし、安全な URL を保存したら、保存した URL を完全に上書きするように URL を手動で更新する必要があります。

   

   カスタムヘッダー認証

   一部のユーザーは、API キーや個人 ID などの機密情報をヘッダーで渡す場合があります。 機密情報の漏洩を防ぐために、値を暗号化し、ユーザーや内部ログからのデータをマスクするカスタム ヘッダーを作成できます。 それを念頭に置いて：

• 暗号化された情報の値が変更された場合は、値を完全に削除して書き換える必要があります。

• 宛先とチャネルの両方に同じヘッダー キーを追加した場合、宛先が優先されます。 チャネルは使用されません。

  

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

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

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

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

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

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

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

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

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

   重要

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

   デフォルトのペイロードを使用することも、必要なデータを含めるようにカスタマイズすることもできます。 変数メニューから変数を選択し、ハンドルバー構文を適用して 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}}
}