既に本ブログドキュメントでご案内している通り、従来のアラート通知方式(Notification Channel)がWorkflowを活用した通知方式に変更される予定です(2023年前半)。

Workflowは、インシデント発生時のアラート通知のルールを定義するものであるという点は従来のNotification Channelと同じですが、インシデント発生時のコンテキスト情報を通知内容に付与したり、通知の条件や通知先などの設定の柔軟性が格段に向上しています。(参考:柔軟になったアラート通知設定を活用してインシデント対応を効率化する

Workflowによって定義されるアラート通知のルールは組織の運用のしかたによって様々ですが、本ブログではWorkflowの管理単位についてご説明します。具体的には、Workflowをアカウント単位で管理するか、アカウント横断の共通的なものとして管理するかについてです。

Workflowによる新たなアラート通知ルールを整備する前に本ブログにて構成を確認するようにしてください。

Environmentとは

Environmentとは、Workflowの管理単位で、一つ以上のアカウントと関連づきます。例えば、以下の図の場合、各アカウントはそれぞれ独立したEnvironmentと関連付いています。この場合、”Account A"で発生したインシデントに対するアラート通知ルール(Workflow)は、”Environment Account A”に定義し、それ以外のアカウントで発生したインシデントには関与しません。

Single environment

 

場合によってはアカウント横断でルールを定義したいケースもあるでしょう。その場合は、該当する複数のアカウントを一つのEnvironmentにまとめて関連づけることができます。以下の図の”Manual Cross-Account A”というEnvironmentに定義されたWorkflowは、”Account A"および”Account B"で発生したインシデントの両方をハンドリングすることができるようになります。

cross environment

現在のEnvironmentの確認

まずは、現在のEnvironmentがどうなっているのか確認してみましょう。New Relicのアカウントの作成の時期によって、複数のアカウントが関連づいたEnvironmentがあるか、1つのアカウントごとにEnvironmentアカウントがあるか、両方のパターンがありますので、まずは今の構成が期待にあっているかどうかを確認することが大事です。Environmentの確認や変更は、GraphQL APIであるNerdGraphを使って行います。

まず、GraphQL Explorerを開きます(参考:GraphiQLエクスプローラーを使用する)。
以下のクエリを実行し、現在の構成を確認します。

{
  actor {
    incidentIntelligenceEnvironment {
      authorizedEnvironments(kind: SINGLE_AND_CROSS_ACCOUNT) {
        associatedAuthorizedAccounts {
          name
        }
        kind
      }
    }
  }
}

以下が出力例です。3つの異なるEnvironmentがあり、それぞれ別のアカウント1つに紐づいていることがわかります。このようなケースでは、Environmentのkind属性は”SINGLE_ACCOUNT_ENVIRONMENT”となります。

query single

 

このような場合は、UI上(Workflowメニュー)ではアカウント名と同じ数だけのEnvironmentが表示されていることが確認できます。プルダウンでEnvironmentを選択し、それぞれのアカウントに対する通知ルールをWorkflowとして定義していきます。

list single

 

逆に、1つのEnvironmentが複数のアカウントに関連づいている場合は、以下の画像のような結果となります。この時Environmentのkind属性はCROSS_ACCOUNT_ENVIRONMENTとなります。

query cross

 

この例では、アカウント横断のEnvironmentとアカウント単位のEnvironmentがそれぞれ一つなので、以下の画像の通り、UI上はEnvironmentが2つ表示されます。

list cross

Environmentの構造を変更する

現在の構成が期待と異なる場合は、同様にGraphQLを利用してEnvironmentの構成を変更していきます。ケースとしては、アカウント横断のEnvironment(kind: CROSS_ACCOUNT_ENVIRONMENT)をアカウント別のEnvironment(kind: SINGLE_ACCOUNT_ENVIRONMENT)に分割するか、もしくはその逆に大別できます。

アカウント横断のEnvironmentをアカウント別のEnvironmentに分割する

以下のGraphQLにて現状の構成を確認します。

{
  actor {
    incidentIntelligenceEnvironment {
      authorizedEnvironments(kind: SINGLE_AND_CROSS_ACCOUNT) {
        incidentIntelligenceAccount {
          id
          name
        }
        associatedAuthorizedAccounts {
          id
          name
        }
        kind
        name
      }
    }
  }
}

この時、大事なのは赤枠の部分のIDです。これはアカウント横断のEnvironmentの情報が保存されているIDです。後ほど、アカウント横断のEnvironmentを削除する際に必要になります。

verify cross

 

次に、以下のGraphQLでアカウント横断のEnvironmentを削除します。xxxxxxの部分は前段で記憶したIDを指定します。

mutation {
  incidentIntelligenceEnvironmentDeleteEnvironment(accountId: xxxxxxx) {
    result
  }
}
delete cross

 

最後に、アカウント横断のEnvironmentが削除されていることを確認します。無事に全てのEnvironmentがアカウント単位に変更されました。

verify single

 

アカウント別のEnvironmentをアカウント横断のEnvironmentにする

現状の構成を確認し、Environmentがアカウント単位であること(kind: SINGLE_ACCOUNT_ENVIRONMENT)を確認します。GraphQLは先の説明と同じです。

verify single

 

次に以下のGraphQLにて、アカウント横断のEnvironmentを作成します。

mutation {
  incidentIntelligenceEnvironmentCreateEnvironment(associatedAccountIds: [xxxxx, yyyyy], incidentIntelligenceAccountId: xxxxx, name: "Shared Account") {
    result
  }
}

重要な属性は以下です。
associatedAccountIds: Environmentに関連づけるアカウントのIDを配列で指定します。省略した場合、全てのアカウントIDが同一のEnvironmentに関連づきます。
incidentIntelligenceAccountId: Environmentの情報を格納するアカウントのIDを指定します。associatedAccountIdsのアカウントIDのいずれかになります。

 

create share

 

無事に、アカウント横断のEnvironment(kind: CROSS_ACCOUNT_ENVIRONMENT)が作成できました。

verify cross

 

実行後は画面上でも確認してみましょう。

Workflowの定義

Alerts & AIのWorkflowメニューにてEnvironmentを選択し、Workflowを定義していきます。これによりインシデントの発生時にアラート通知が可能になります。設定の詳細については、別ブログ(柔軟になったアラート通知設定を活用してインシデント対応を効率化する)やオンラインマニュアルを参考にしてください。

 

既存のNotification Channelの移行

本ブログ執筆時点 (2022/6)では既存のNotification Channelを自動的に移行する手段はありません。これまでNotification Channelを利用されている場合は、Workflowへ移行の検討が必要です。

アラート条件にNotification Channelが定義されている場合は削除します。

delete notification channel

 

削除後は、以下のような画面になります。
もし、既に定義済みのWorkflowが存在し、かつ、そのWorkflowが今見ているアラート条件やポリシーを受け付けるような設定になっている場合は、特にアクションは必要ありません。

create workflow

 

ポリシーごとにWorkflowを作成したい場合は、Create workボタンを押下してWorkflowを新規に作成します。

create workflow

 

まとめ

本ブログでは、新たなアラート通知の定義方法であるWorkflowに関し、アカウントとの関係や管理方法について説明しました。運用ポリシーに応じた構成にしましょう。設定方法については、オンラインドキュメントに動画付きの解説がありますので、そちらもご確認ください。