本ブログの記載内容はブログ執筆時点(2022/6/10)のものです。2023/1/28時点でアカウント横断でのEnvironmentは作成できないようになっていますのでご注意ください。ご不明点がある場合は、弊社アカウントチームやサポートににお問合せください。
既に本ブログやドキュメントでご案内している通り、従来のアラート通知方式（Notification Channel）がWorkflowを活用した通知方式に変更される予定です（2023年前半）。
Workflowは、インシデント発生時のアラート通知のルールを定義するものであるという点は従来のNotification Channelと同じですが、インシデント発生時のコンテキスト情報を通知内容に付与したり、通知の条件や通知先などの設定の柔軟性が格段に向上しています。（参考：柔軟になったアラート通知設定を活用してインシデント対応を効率化する）
Workflowによって定義されるアラート通知のルールは組織の運用のしかたによって様々ですが、本ブログではWorkflowの管理単位についてご説明します。具体的には、Workflowをアカウント単位で管理するか、アカウント横断の共通的なものとして管理するかについてです。
Workflowによる新たなアラート通知ルールを整備する前に本ブログにて構成を確認するようにしてください。
Environmentとは
Environmentとは、Workflowの管理単位で、一つ以上のアカウントと関連づきます。例えば、以下の図の場合、各アカウントはそれぞれ独立したEnvironmentと関連付いています。この場合、”Account A"で発生したインシデントに対するアラート通知ルール（Workflow）は、”Environment Account A”に定義し、それ以外のアカウントで発生したインシデントには関与しません。
場合によってはアカウント横断でルールを定義したいケースもあるでしょう。その場合は、該当する複数のアカウントを一つのEnvironmentにまとめて関連づけることができます。以下の図の”Manual Cross-Account A”というEnvironmentに定義されたWorkflowは、”Account A"および”Account B"で発生したインシデントの両方をハンドリングすることができるようになります。
現在の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”となります。
このような場合は、UI上（Workflowメニュー）ではアカウント名と同じ数だけのEnvironmentが表示されていることが確認できます。プルダウンでEnvironmentを選択し、それぞれのアカウントに対する通知ルールをWorkflowとして定義していきます。
逆に、1つのEnvironmentが複数のアカウントに関連づいている場合は、以下の画像のような結果となります。この時Environmentのkind属性はCROSS_ACCOUNT_ENVIRONMENTとなります。
この例では、アカウント横断のEnvironmentとアカウント単位のEnvironmentがそれぞれ一つなので、以下の画像の通り、UI上はEnvironmentが2つ表示されます。
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を削除する際に必要になります。
次に、以下のGraphQLでアカウント横断のEnvironmentを削除します。xxxxxxの部分は前段で記憶したIDを指定します。
mutation {
incidentIntelligenceEnvironmentDeleteEnvironment(accountId: xxxxxxx) {
result
}
}
最後に、アカウント横断のEnvironmentが削除されていることを確認します。無事に全てのEnvironmentがアカウント単位に変更されました。
アカウント別のEnvironmentをアカウント横断のEnvironmentにする
現状の構成を確認し、Environmentがアカウント単位であること（kind: SINGLE_ACCOUNT_ENVIRONMENT）を確認します。GraphQLは先の説明と同じです。
次に以下のGraphQLにて、アカウント横断のEnvironmentを作成します。
mutation {
incidentIntelligenceEnvironmentCreateEnvironment(associatedAccountIds: [xxxxx, yyyyy], incidentIntelligenceAccountId: xxxxx, name: "Shared Account") {
result
}
}重要な属性は以下です。
associatedAccountIds: Environmentに関連づけるアカウントのIDを配列で指定します。省略した場合、全てのアカウントIDが同一のEnvironmentに関連づきます。
incidentIntelligenceAccountId: Environmentの情報を格納するアカウントのIDを指定します。associatedAccountIdsのアカウントIDのいずれかになります。
無事に、アカウント横断のEnvironment（kind: CROSS_ACCOUNT_ENVIRONMENT）が作成できました。
実行後は画面上でも確認してみましょう。
Workflowの定義
Alerts & AIのWorkflowメニューにてEnvironmentを選択し、Workflowを定義していきます。これによりインシデントの発生時にアラート通知が可能になります。設定の詳細については、別ブログ（柔軟になったアラート通知設定を活用してインシデント対応を効率化する）やオンラインマニュアルを参考にしてください。
既存のNotification Channelの移行
本ブログ執筆時点 (2022/6）では既存のNotification Channelを自動的に移行する手段はありません。これまでNotification Channelを利用されている場合は、Workflowへ移行の検討が必要です。
アラート条件にNotification Channelが定義されている場合は削除します。
削除後は、以下のような画面になります。
もし、既に定義済みのWorkflowが存在し、かつ、そのWorkflowが今見ているアラート条件やポリシーを受け付けるような設定になっている場合は、特にアクションは必要ありません。
ポリシーごとにWorkflowを作成したい場合は、Create workボタンを押下してWorkflowを新規に作成します。
まとめ
本ブログでは、新たなアラート通知の定義方法であるWorkflowに関し、アカウントとの関係や管理方法について説明しました。運用ポリシーに応じた構成にしましょう。設定方法については、オンラインドキュメントに動画付きの解説がありますので、そちらもご確認ください。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
