Datadog のCross-org Paging で複数組織のOn-Call Team を1つの組織に集約する
こんにちは、なおにしです。
Datadog のCross-org Paging を使用して、複数Datadog 組織のOn-Call Team を単一のDatadog 組織に集約する構成を試す機会がありましたのでご紹介します。
はじめに
Datadog を複数の組織（Organization）に分けて運用していると、On-Call Team やスケジュール、エスカレーションポリシーを組織ごとに用意することになります。
実際に一次対応するメンバーは同じなのに、同じ設定を組織の数だけ複製して管理するのは運用負荷が高くなるかと思います。
そうした場合に使える機能がCross-org Paging です。
Cross-org paging enables users to automatically trigger alerts to On-Call Teams that reside in other Datadog organizations or data centers. Cross-org paging is useful when your operational or organizational setup spans multiple Datadog orgs or data centers, and you want to centralize incident response in one single org.
(和訳)
Cross-org Paging を使用すると、他のDatadog 組織やデータセンターに存在するOn-Call Team に対して、アラートを自動的にトリガーできます。Cross-org Paging は、運用体制や組織構成が複数のDatadog 組織やデータセンターにまたがっており、インシデント対応を1つの組織に集約したい場合に役立ちます。
執筆時点ではPublic Preview の機能で、対象はモニターアラートなどの自動化されたワークフローに限られています。
Cross-org paging is in Public Preview and is supported only for automated workflows, such as monitor alerts and incident notification rules. Manual paging through the Datadog UI or API is limited to the local organization and data center.
(和訳)
Cross-org Paging はPublic Preview であり、モニターアラートやインシデント通知ルールなどの自動化されたワークフローでのみサポートされています。Datadog のUI やAPI を通じた手動のページングは、ローカルの組織およびデータセンター内に限定されます。
Cross-org Paging では、2つの組織をsource orgとdestination orgという呼び方で区別します。
To enable paging between orgs or datacenters, you must establish a secure connection between the source org (where alerts originate) and the destination org (where the On-Call Team is managed).
(和訳)
組織間またはデータセンター間のページングを有効にするには、source org（アラートの発生元）と destination org（On-Call Team を管理する組織）の間に安全な接続を確立する必要があります。
整理すると以下のとおりです。
| 用語 | 意味 | 本記事の構成での役割 |
|---|---|---|
| source org | アラートの発生元となる組織 | モニターを設定している各組織 |
| destination org | On-Call Team を管理する組織 | On-Call Team を集約する組織 |
On-Call Team を集約する側がdestination org、アラートを送る側がsource org です。
後述の設定作業ではどちらの組織で何を設定するのかが重要になるので、この対応は押さえておいていただければと思います（私は上記を最初取り違えてました。詳細は末尾の補足をご参照ください）。
やってみた
事前準備
今回はsource org・destination org ともにAP1（日本）サイトの組織を使用しています。
Cross-org Paging の接続はdestination org で発行したAPI キーとアプリケーションキーをsource org に登録する方式で、今回はAP1 同士の組織かつ親子関係（Multiple-Organization）でなくても接続できることを確認しています。
なお、ドキュメントには異なるデータセンター（サイト）をまたいでページングできることが記載されています。
Page teams across regional or compliance boundaries: Page teams in compliant regions (like US1 or AP1) while keeping alerting logic where it originates.
(和訳)
リージョンやコンプライアンスの境界を越えてチームをページング：アラートのロジックは発生元に残したまま、コンプライアンスに準拠したリージョン（US1 やAP1 など）のチームをページングできます。
今回の設定作業で、どちらの組織で何を作成/設定するかは以下のとおりです。
| 組織 | 作成・設定するもの | 個数 |
|---|---|---|
| destination org | On-Call 権限を持つカスタムロール | 1つ |
| destination org | サービスアカウント | 1つ |
| destination org | API キー | 1つ（全source org 共通） |
| destination org | アプリケーションキー（サービスアカウントで作成） | source org ごとに1つ |
| source org | Cross-org Paging の接続 | 接続先のdestination org ごとに1つ |
キーの類はすべてdestination org 側で作成し、source org 側では接続の設定をするだけです。以降、この表の上から順に設定していきます。
① destination org でサービスアカウント用のロールを作成する
ドキュメントでは、サービスアカウントに以下の権限を持つロールを割り当てるよう記載されています。
on_call_read- Read access to On-Call Teams and configurationson_call_page- Ability to trigger Pages to On-Call Teamson_call_respond- Respond to On-Call Pagesuser_access_read- Read user information (automatically included in most roles)(和訳)
on_call_read- On-Call Team と設定の読み取りon_call_page- On-Call Team へのページのトリガーon_call_respond- On-Call のページへの応答user_access_read- ユーザー情報の読み取り（ほとんどのロールに自動的に含まれます）
destination org の[Organization Settings] - [Roles] から[New Role]を選択し、On-Call Service Account Roleというロールを作成します。
Permissions をon_callで絞り込み、On-Call Read・On-Call Page・On-Call Responderの3つを有効にしました。ページングに必要な権限だけに絞るため、On-Call WriteとOn-Call Adminは無効のままにしています。
残るuser_access_readについては、ドキュメントに以下の注意書きがあります。
Service accounts created with Terraform may be missing the
user_access_readpermission. This permission is automatically added to roles created through the UI, but it cannot be manually added through the UI and may not be included in Terraform-configured roles. If cross-org paging fails with permission errors, add an additional role to your service account that includes theuser_access_readpermission.(和訳)
Terraform で作成したサービスアカウントには
user_access_read権限が欠けている場合があります。この権限はUI で作成したロールには自動的に追加されますが、UI から手動で追加することはできず、Terraform で設定したロールには含まれない場合があります。Cross-org Paging が権限エラーで失敗する場合は、user_access_read権限を含む追加のロールをサービスアカウントに割り当ててください。
実際に確認してみたところ、ロールの編集画面・サービスアカウントの詳細画面のどちらにもuser_access_readの項目は表示されず、UI 上で付与状況を確認することはできませんでした。
ただ、UI で作成した上記ロールのままで後述のページングと電話の着信まで問題なく成功しているため、UI でロールを作成する場合は特に意識しなくて良さそうです。Terraform でロールやサービスアカウントを管理する場合はご注意ください。
② サービスアカウントを作成する
destination org の[Organization Settings] - [Service Accounts] からサービスアカウントを作成します。Name はOn-Call Accountとし、Assign Roles には①で作成したロールを割り当てました。
③ destination org でAPI キーを作成する
destination org の[Organization Settings] - [API Keys] からAPI キーを作成します。
API キーはdestination org で1つ作成すれば全source org で共通して使えます。以下のとおり、ドキュメントでもアプリケーションキーはsource org ごとにキーを分けるように記載されていますが、API キーについては記載されていません。
- In your destination org, create an API key.
- In your destination org, create an application key for each source org you want to allow. Ensure that each application key is unscoped (not restricted to specific scopes).
(和訳)
- destination org でAPI キーを作成します。
- destination org で、許可したいsource org ごとにアプリケーションキーを作成します。各アプリケーションキーは unscoped（特定のスコープに制限されていない状態）にしてください。
④ サービスアカウントのアプリケーションキーを作成する
続いてアプリケーションキーを作成します。
②で作成したOn-Call Accountサービスアカウントを選択し、サービスアカウント自身のApplication Keys から[New Key]を選択します。Name はOn-Call-<source org 名>のように、どのsource org 用のキーか分かる名前にしました。
画面の背景に見えているとおり、アプリケーションキーには以下の説明が表示されています。
Application Keys are associated with the user account that created them and have the permissions of that user.
(和訳)
アプリケーションキーは、作成したユーザーアカウントに紐づき、そのユーザーの権限を持ちます。
アプリケーションキーは作成したアカウントの権限を持つため、管理者個人の[Personal Settings] - [Application Keys] から作成すると、個人アカウントの権限に紐づいたキーになってしまいます。①で権限を絞ったロールを使いたいので、サービスアカウント側から作成してください。
作成したアプリケーションキーの値はこのタイミングでしか取得できないため、忘れずに控えておきましょう。source org が複数ある場合は、この手順をsource org の数だけ繰り返します。
⑤ source org でCross-org Paging の接続を作成する
ここからはsource org 側の作業です。
[On-Call] - [Settings] - [Cross-org Paging] を開き、[Add Connection]を選択すると接続の入力行が追加されます。Datacenter のデフォルト値はUS1 - Eastになっているため、destination org のデータセンター（今回はAP1 - Japan）に変更する必要があります。
API Key には③で作成したAPI キーを、Application Key には④でこのsource org 用に作成したアプリケーションキーを入力して保存します。
保存すると、Organization Name の欄には接続先のdestination org の組織名が自動で表示されました。作成直後はインジケーターがグレーで、ホバーするとNot synced yet. It can take up to 5 minと表示されます。
ドキュメントにも接続の作成後にdestination org のOn-Call Team のハンドルを取得するまで最大5分かかると記載されています。
When you create this connection, Datadog securely stores your credentials and fetches available On-Call Team handles from the destination org. This process may take up to five minutes.
(和訳)
この接続を作成すると、Datadog は認証情報を安全に保存し、destination org から利用可能なOn-Call Team のハンドルを取得します。この処理には最大5分かかる場合があります。
しばらく待つとインジケーターが緑色になり、ホバーするとLast synced at Sep 24, 2026, 8:38 pmのように最終同期時刻が表示されるようになりました。
⑥ モニターから別組織のOn-Call Team にページングする
同期が完了すると、destination org のOn-Call Team のハンドルがsource org のオートコンプリートに表示されるようになります。
After this process is complete, destination org team handles appear in your source org's autocomplete menus (for example, in monitors).
(和訳)
この処理が完了すると、destination org のチームのハンドルがsource org のオートコンプリートメニュー（モニターなど）に表示されます。
実際にsource org 側のモニター編集画面で@を入力すると、On-Callカテゴリの中にdestination org で管理しているOn-Call Team「管理者」（@oncall-team-admin）が表示されました。
見た目も扱いも、ローカルの組織のOn-Call Team と変わりません。
source org のsystem.load.1を対象にしたテスト用のモニターで、メッセージに@oncall-team-adminを含めてテスト通知を送信してみます。
destination org 側でPage #1 が作成され、Team「管理者」がpaged の状態となり、実際に電話が着信しました。Page 詳細画面のTimeline にはPage #1 was TRIGGERED by a monitor from another Datadog organization (<source org 名>)と表示されており、どの組織から来たページなのかが記録されていることが分かります。
なお、Page のタイトルにはモニター名がそのまま使われます。複数のsource org からのページがdestination org に集まることを考えると、モニター名に送信元の組織名を含めておくと（例：[<source org 名>] system.load.1 high）一覧で見分けやすくなるかと思います。
また、ドキュメントの制限事項には、通知内のリンクについて以下の記載があります。
Links in cross-org notifications (for example, monitor or incident URLs) point to the source org. They may not resolve cleanly in the destination org UI.
(和訳)
組織間の通知に含まれるリンク（モニターやインシデントのURL など）はsource org を指しています。destination org のUI では正しく解決されない場合があります。
実際に、destination org 側でPage 詳細画面のTimeline にある送信元組織名のリンクをクリックしてみましたが、イベントを正しく開くことはできませんでした。モニターの詳細を確認したい場合は、source org にログインして確認する形になるかと思います。
制限事項には手動でのページングについても以下の記載があります。今回は未検証ですが、UI やAPI からの手動のページングは組織をまたげない点にご注意ください。
Manual paging (for example, through the API or web UI) is not supported across orgs. Manual paging is only supported within your current org or data center.
(和訳)
手動のページング（API やWeb UI を通じたものなど）は、組織をまたいではサポートされていません。手動のページングは、現在の組織またはデータセンター内でのみサポートされています。
補足：Cross-org Paging で作成できる接続数の上限は5つ
ドキュメントをちゃんと読めば分かるのですが、今回実際に設定する前はsource org とdestination org の関係を逆に捉えており、On-Call Team を集約する組織の方で接続を作るものと思い込んでいました。
このため、念のため[Add Connection]を何度か押下したところ、以下のようにYou have reached the maximum number of connectionsと表示されました。
接続数の上限について執筆時点ではドキュメントに記載が見当たりませんでしたが、上記のとおり5つが上限のようです。
今回の構成では各source org から集約先のdestination org に向けて接続を1つずつ作成するので、1つのsource org の画面にある接続は1つで済みます。
つまり、1つのsource org から複数のdestination org に対してページングしたいというケースでなければ、この上限を意識する場面は少ないかと思います。
まとめ
複数の組織を運用する中でOn-Call を1つの組織に集約したい状況があり、Cross-org Paging を試してみました。
source org とdestination org の向きや、API キーとアプリケーションキーの役割を取り違えると迷う部分もあるかもしれませんが、設定自体はシンプルで、モニターからのメンションもローカルのOn-Call Team と同じ感覚で利用できます。
執筆時点ではPublic Preview の機能なので、今後の仕様変更にはご注意ください。
本記事がどなたかのお役に立てれば幸いです。
