【完全解説】4大クラウドの Datadog integrations アーキテクチャ【2024年版】

## はじめに
こんにちは、Datadog Japan で Sales Engineer をしている [**AoTo**](https://qiita.com/AoTo0330) です。

この投稿は **[<font color="#6495ED">AoTo Advent Calendar 2024</font>](https://qiita.com/advent-calendar/2024/aoto) 1日目**の記事です。

:::note info
この記事は定期的に更新されています。
現在は**2024年12月時点**での情報をもとにアップデートされています。[^1]

[^1]: この投稿は **[<font color="#632CA6">Datadog Advent Calendar 2022</font>](https://qiita.com/advent-calendar/2022/datadog) 8日目**の記事として執筆された、『[3大クラウドのDatadog Integrations アーキテクチャ](https://qiita.com/AoTo0330/items/545a229fd33d92c01562)』の最新版です。
:::

この記事では、Datadog が提供している、**Amazon Web Services(AWS)**, **Microsoft Azure**, **Google Cloud** のいわゆる「3大クラウド」に **Oracle Cloud Infrastructure(OCI)** を加えた「**4大クラウド**」からの監視・セキュリティ・コストの情報を収集するためのインテグレーションの全体像とアーキテクチャをまとめています。

:::note info
本記事内の「**4大クラウド**」の定義は、[**2024 Gartner®️ Magic Quadrant™️ for Strategic Cloud Platform Services**](https://www.gartner.com/en/documents/5851847) の内 **Leaders** に位置されるプラットフォームとしています。
:::

ここでは、各インテグレーションの設定方法に**言及しません**。
設定方法は以下の **Datadog の公式ドキュメント**をご参照ください。
 + [**AWS**](https://docs.datadoghq.com/ja/integrations/amazon_web_services/)
 + [**Microsoft Azure**](https://docs.datadoghq.com/ja/integrations/azure/)
 + [**Google Cloud**](https://docs.datadoghq.com/ja/integrations/google_cloud_platform/)
 + [**Orale Cloud Infrastructure**](https://docs.datadoghq.com/integrations/oracle_cloud_infrastructure/?tab=serviceconnectorhub)

## クラウドインテグレーション概要
Datadog は現在、[800以上のインテグレーション](https://docs.datadoghq.com/ja/integrations/)を提供しており、[インテグレーション入門](https://docs.datadoghq.com/ja/getting_started/integrations/)によるとインテグレーションは以下の3種類に大分されます。

 + エージェントベース
 + 認証(クローラー)ベース
 + ライブラリ

この中で、4大クラウドのインテグレーションは「**認証(クローラー)ベース**」にあたります。認証 (クローラー)ベース特徴として、「Datadog Agent/Tracer を利用しない」「Datadog API を利用する」「Datadog アプリケーション[^2]内で制御・設定される」ことが挙げられます。
[^2]: ここでの「Datadog アプリケーション」とは、Web ブラウザー上からアクセスできる `datadoghq.com` またはそのサブドメインで制御される SaaS 型のアプリケーションのことを指します。

特に、各クラウドインテグレーションは<INS>クラウド上に権限リソースを用意し、その情報を用いて Datadog アプリケーションのバックグラウンドで用意される**クローラー**による定期的な情報取得が行われる</INS>共通点があります。

![Cloud-Integrations.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/767eafae-730b-f142-8082-fcf13609843f.png)

### メトリクス収集
メトリクス収集は基本的に **Pull 型のデータ連携**です。

![Cloud-Integrations-Metrics.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/c1a54ae7-f064-f705-965d-31d68dd240bf.png)

各クラウドの監視サービスに保存されているメトリクスは、クラウド上に用意された権限リソースとクローラーによる定期的な情報取得によって Datadog に収集されます。この権限リソースは、図のようなメトリクスデータの取得だけではなく、<INS>各クラウドリソースのメタデータの取得・コスト情報の取得・セキュリティ/アセット情報の取得</INS>等[^3]にも利用されます。
[^3]: Datadog Log Management からのログのアーカイブや Datadog Monitor の通知にも利用されますが、本投稿では割愛します。

クローラーによる定期的な情報取得となるため、メトリクス取得用の API が提供されていることが前提条件となります。さらに、各クラウド上のメトリクスデータが利用可能となるまでに定められた時間があり、メトリクス取得頻度も5-10分間隔となるため、[メトリクスの遅延](https://docs.datadoghq.com/ja/integrations/guide/cloud-metric-delay/)を考慮する必要があります。

AWS, OCI ではこの方法に限らず、クラウド側からメトリクスを Push 型で送信する方法が提供されています。

### ログ収集
ログ収集は基本的に **Push 型のデータ連携**です。

![Cloud-Integrations-Logs.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/56ac6cc6-5dc1-9a27-9078-baee3db7f2ca.png)

各クラウドの監視サービスまたはオブジェクトストレージに保存されているログは、クラウド上のサーバレス関数をログの保管元の更新によりトリガーするイベント駆動型の情報取得によって Datadog に収集されます。

イベント駆動型の情報取得となるため、各クラウドで提供されているトリガー方式やサーバレス関数の仕組みや実装方法が多少異なります。さらに、既存の実働環境への影響を最小限とするため、サーバレス関数などのサービス利用の割り当て制限に注意する必要があります。

### コスト情報収集
コスト情報収集はクラウドの機能で出力したコスト情報を、**Pull 型のデータ連携**で取得します。

![Cloud-Integrations-Costs.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/9db6f82a-9f08-5c1d-3fe6-84ebb7e14ce0.png)

各クラウドは請求情報をその内訳と共にオブジェクトストレージにエクスポートする機能を備えており、**Datadog Cloud Cost Management** を有効化することで、メトリクス収集で利用している既存の認証情報を利用してコスト情報を収集できます。[^4]
[^4]: Datadog Cloud Cost Management は最大 15 か月分の履歴データを自動的に取り込みます。

これらのコスト情報は実際の請求を元に生成されるため、クラウド利用時の契約を反映し、Datadog ではカタログ価格である**オンデマンド(On-demand)**・契約に応じたディスカウントを含む**償却費(Amortized)と非混合費(Unblended)**・プライベートディスカウント等を対象とする**正味コスト(Net)** などに分類して表示可能です。

さらに、コスト情報を可視化するだけではなく、**EKS, ECS, AKS, GKE** などのコンテナサービスのコストをポッド、ノード、コンテナ、タスクなどのワークロード量に応じてコストの割り当てを行う[**コンテナコスト配分**](https://docs.datadoghq.com/cloud_cost_management/container_cost_allocation/)機能を利用できます。

### メタデータ収集
メタデータ収集は基本的に **Pull 型のデータ連携**です。

![Cloud-Integrations-Metadata.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/2becf5c3-173c-569a-59ce-ceca9e45c7aa.png)

メトリクス収集と同時に、クローラーが読み取り権限を利用して各リソースのメタデータを取得し Datadog 上の監視情報にタグとして付与します。

この他に、**Datadog Cloud Security Management** を有効化することで、クラウドの構成情報などを追加で取得してクラウド上の構成ミスを発見する Cloud Security Posture Management(CSPM) を実現できます。

さらに、クラウド認証情報の IAM 情報のリスクを評価する **Identity Risk 機能** をさらに活用するためには、実際の利用証跡である監査ログと併せて Cloud Infrastructure Entitlement Management(CIEM)を実現できます。

## AWS integration のアーキテクチャ
AWS integration で取得できる情報は AWS アカウント単位です。

**AWS Orgatnizations** 配下の複数の AWS アカウントに設定を行う場合は、CloudFormation Stack Sets を活用した、[AWS integrations for Multi-Accounts](https://qiita.com/AoTo0330/items/9ee7077af1a3c660af4e) の設定がサポートされています。[^5]
[^5]: [**AWS CloudWatch cross-account Observability**](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html) によって監視アカウントに監視情報が集約されている場合でも、個々のアカウントでの設定が必要となります。

![ Datadog-AWS-Integration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/41e81e73-123b-76ee-5819-141b10d4c98b.png)

インテグレーションに必要なリソースは、Datadog 内の [AWS integration 設定ページ](https://app.datadoghq.com/integrations/amazon-web-services)から [CloudFormation テンプレート](https://github.com/DataDog/datadog-cloudformation-resources/tree/master/datadog-integrations-aws-handler)を利用してデプロイ可能です。これにより、主にメトリクス収集をはじめとする Datadog からのクローラーベースのアクセスを許可するための IAM role とログを転送する Lambda 関数がデプロイされます。[^6]
[^6]: 他にも Datadog API を呼び出し Datadog 上での設定を完了させる Lambda 関数(DatadogAPICall)やログキャッシュ用の S3 などさまざまなリソースが作成されますが、ここでは割愛します。

:::note info
詳細は『[Datadog integrations Deep Dive - AWS 編](https://qiita.com/AoTo0330/items/ae8d5989f41171b1647b)』で解説しています。



:::

https://qiita.com/AoTo0330/items/ae8d5989f41171b1647b



### メトリクス収集
![ Datadog-AWS-Integration-Metrics.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/710acbda-e7fd-53cd-3939-48bb1268921c.png)

[CloudFormation](https://github.com/DataDog/datadog-cloudformation-resources/tree/master/datadog-integrations-aws-handler) または[手動](https://docs.datadoghq.com/ja/integrations/guide/aws-manual-setup/)で作成した IAM role の権限を利用して、外部 ID で登録された Datadog クローラーが存在する Datadog AWS アカウントから **CloudWatch Metrics API** へ**約10分に1回**の定期的なアクセスが行われます。

これにより、<INS>ほぼすべての CloudWatch Metrics に存在するメトリクス</INS>を[**15~20分の遅延**で Datadog に収集](https://docs.datadoghq.com/ja/integrations/guide/cloud-metric-delay/)します。この遅延は、アクセス頻度に加えて AWS 上の各メトリクスが API によって取得可能になるまでのタイムラグを考慮したものであり、[Datadog サポートへの依頼で頻度を変更する](https://docs.datadoghq.com/ja/integrations/guide/aws-integration-and-cloudwatch-faq/#cloudwatch-のメトリクスを-datadog-に受信する際の遅延を減らすにはどうしたらよいですか)か [**CloudWatch Metrics Streams** を利用する](https://docs.datadoghq.com/ja/integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/)ことで削減することが可能です。

:::note warn
既存の AWS サービスに新たに追加されたメトリクス[^7]は既存の名前空間(`AWS/<AWSサービス名>`)に追加されますが、Datadog のサポートが開始されるまではこれらのメトリクスを Datadog へ取り込むことができません。
[^7]: 2024年には、一部サービスの Serverless 系のメトリクスが新たにサポートされました。(e.g. [ElastiCach Serverless](https://app.datadoghq.com/release-notes/monitor-elasticache-serverless-deployments))
:::

:::note info
新たな AWS サービスのメトリクスや独自の名前空間を設定したカスタムメトリクスは、Datadog 上の AWS 設定画面より □ [Collect Custom Metrics] ラジオボタンを有効化することで[**カスタムメトリクス**として取り込む](https://docs.datadoghq.com/ja/integrations/guide/aws-integration-and-cloudwatch-faq/#インテグレーションで-aws-カスタムメトリクスを収集することは可能ですか)ことが可能です。

:::

### ログ収集
![ Datadog-AWS-Integration-Logs.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/8e4ff357-4847-3dc4-9b15-4954fdd5ddc5.png)

[CloudFromation で作成](https://docs.datadoghq.com/ja/logs/guide/forwarder/)した **Datadog Lambda Forwarder** はデータソースとして **CloudWatch Logs ロググループ** か **S3 バケット** を対象にし、それらのログは<INS>タグ付け・ログのフィルター・圧縮・暗号化などを経て **Datadog Logs intake API** に転送</INS>されます。

前者は**ロググループレベルのサブスクリプションフィルター**で、後者は **S3 イベント通知**によって **Datadog Lambda Forwarder** をトリガーします。これらは Datadog の AWS integration 画面で[トリガーを自動的にセットアップする](https://docs.datadoghq.com/ja/logs/guide/send-aws-services-logs-with-the-datadog-lambda-function/#トリガーを自動的にセットアップする)ことが可能です。

この他にも、[**アカウントレベルのサブスクリプションフィルター**を用いたログ転送](https://docs.datadoghq.com/ja/logs/guide/aws-account-level-logs/?tab=lambdaforwarder)も可能です。

:::note info
サブスクリプションフィルターを利用する際は、**Lambda の再起ループ**を防止するために、デフォルトで **CloudWatch Logs ロググループ**の `aws/lambda` 配下で文字列 `datadog-forwarder` を含むロググループでフィルターを作成しないよう設定されます。[^8]
[^8]:ある程度の再起ループは [Lambda 再帰ループ検出を使用した無限ループの防止](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/invocation-recursion.html)によって自動的に防止されますが、Datadog へログを転送する場合は検出されないサービスの組み合わせとなる可能性もあるため、設定時にも注意が必要です。
:::

### コスト情報収集
![ Datadog-AWS-Integration-Costs.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/a488445a-6aa9-5bfe-283c-04e5ab87debb.png)

[**AWS Cost and Usage Report**](https://docs.aws.amazon.com/ja_jp/cur/latest/userguide/what-is-cur.html) を利用して、<INS>1時間単位のレガシー CUR を S3 に出力し、Datadog クローラーが定期的にコスト情報をに収集する</INS>ことで **Datadog Cloud Cost Management** で可視化できるようになります。

:::note warn
2024年12月時点で、Datadog Cloud Cost Management は[レガシー CUR エクスポートの作成](https://docs.aws.amazon.com/ja_jp/cur/latest/userguide/dataexports-create-legacy.html)で作成された CUR のみをサポートしています。
:::

通常はアカウント全体の CUR をコスト情報として読み取りますが、[**AWS Billing Conductor**](https://docs.aws.amazon.com/billingconductor/latest/userguide/what-is-billingconductor.html) を利用している場合は、**Billing Conductor CUR** を利用してアカウントの一部の情報を元にしたコスト情報のみを対象とすることが可能です。

### メタデータ収集

![ Datadog-AWS-Integration-Costs-Metadata.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/2f48634b-a3c7-ac3c-e167-3945d20badaa.png)

各リソースの読み取り権限を用いてメタデータ(リソースの構成・タグ情報)取得し、Datadog 上の監視情報へのタグが付与されます。

**Datadog Cloud Security Management** を有効化し、追加で `Secyrity Audit` 権限での情報取得を行うことで、[**Misconfiguration(CSPM)**](https://docs.datadoghq.com/ja/security/cloud_security_management/misconfigurations/), [**Identity Risk(CIEM)**](https://docs.datadoghq.com/ja/security/cloud_security_management/identity_risks/) の機能を活用できます。[^9]
[^9]: その他の **Workload Secyrity(CWS), Vulnerability** は Datadog Agent の導入か [**Agentless Scanning**](https://docs.datadoghq.com/ja/security/cloud_security_management/agentless_scanning)(AWS のみ)が必要となります。

## Azure integraion のアーキテクチャ
Azure integration で取得できる情報は **Azure サブスクリプション**または**管理グループ**単位です。

<INS>Azure 管理グループレベルで**アプリ登録**の読み取り権限を割り当てる</INS>ことで、複数のサブスクリプションを監視し、管理グループ内の新しいサブスクリプションを自動的に監視することが可能です。

![Datadog-Azure-Integration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/831dab63-a696-3ee5-1b9f-830ac83b5f79.png)

インテグレーションに必要なリソースは、Datadog 内の [Azure integration 設定ページ](https://app.datadoghq.com/integrations/azure)から **ARM テンプレート**を利用してデプロイ可能です。これにより、<INS>Datadog からのクローラーベースのアクセスを許可するための **Service principal**</INS> と<INS>リソースログ・アクティビティログを転送する **Event Hub, Function App**</INS> がデプロイされます。

![AzureNativeIntegration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/40e738da-1686-2af6-9ead-665a9d62ff9c.png)


一方で、Datadog サイト **US3** を利用すると、リソースを Azure 管理とする [**Azure Native integration**](https://docs.datadoghq.com/ja/integrations/guide/azure-native-manual-setup/) が利用可能です。このインテグレーションは [Datadog Resource](https://portal.azure.com/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.Datadog%2Fmonitors) と呼ばれる Azure 管理の Datadog へ監視情報を連携する専用のリソースをデプロイすることができ、これにより一括でメトリクス・ログ・メタデータの情報収集が可能です。

:::note info
詳細については『[Datadog integrations Deep Dive - Azure 編](https://qiita.com/AoTo0330/items/82aa9d5bb9473f24d1f8)』で解説しています。
:::

https://qiita.com/AoTo0330/items/82aa9d5bb9473f24d1f8

### メトリクス収集
![Datadog-Azure-Integration-Metrics.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/a136285a-361a-44b0-68ea-dfb88c51b732.png)

前述の手順により作成された[アプリケーション登録](https://learn.microsoft.com/ja-jp/security/zero-trust/develop/app-registration)を通して利用されるサービスプリンシパルの権限を利用して、Datadog クローラーが **Azure Metrics Data plane API**[^10] へ**約2分に1回**の定期的なアクセスが行われます。
[^10]: Azure Metrics Data plane API による効率性とパフォーマンス改善の変遷は『[Azure Metrics Data plane API で何が変わったのか？](https://qiita.com/AoTo0330/items/10c18f9de0dbe4fce61a
)』で解説しています。

これにより、[対応するすべての Azure サービスメトリクス](https://docs.datadoghq.com/ja/integrations/azure/#概要)と [Azure Application Insights のカスタムメトリクス](https://learn.microsoft.com/ja-jp/azure/azure-monitor/app/api-custom-events-metrics)が[**4~5分程度の遅延**で Datadog に収集](https://docs.datadoghq.com/ja/integrations/guide/cloud-metric-delay/#azure)します。[^11]
[^11]: [Azure Monitor のカスタムメトリック](https://learn.microsoft.com/ja-jp/azure/azure-monitor/essentials/metrics-custom-overview)は現在プレビュー版であるため、Datadog での正式な取り込みのサポートはされていません。

### ログ収集
![Datadog-Azure-Integration-Logs.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/0825ab63-1555-347e-98b6-92167daae6f1.png)

ARM テンプレートで作成した **Azure Function App** はデータソースとして **Azure Monitor ログ** か **Blob Storage** を対象とし、それらのログは<INS>タグ付け・ログのフィルター・圧縮・暗号化などを経て Datadog Logs intake API に転送</INS>されます。

前者は[**診断設定(Diagnostic setting)**](https://learn.microsoft.com/ja-jp/azure/azure-monitor/essentials/diagnostic-settings)で、後者は [**Azure Blob Storage トリガー**](https://learn.microsoft.com/ja-jp/azure/azure-functions/functions-bindings-storage-blob-trigger)によって **Azure Function App** をトリガーします。

### コスト情報収集
![Datadog-Azure-Integration-Costs.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/c7375706-df57-539a-ef17-f95cee8bffda.png)

[**Azure Cost Managenent のエクスポート**](https://learn.microsoft.com/ja-jp/azure/cost-management-billing/costs/tutorial-export-acm-data)を利用して、<INS>CSV 形式のコストデータ を Azure Storage に出力し、Datadog クローラーが定期的にコスト情報をに収集する</INS>ことで **Datadog Cloud Cost Management** で可視化できるようになります。新しい[**エクスポート (プレビュー)**](https://learn.microsoft.com/ja-jp/azure/cost-management-billing/costs/tutorial-improved-exports)で作成されたコストデータも、<INS>正しいデータセットのバージョン・データ形式・データ圧縮形式を選択する</INS>ことで利用できます。

### メタデータ収集
![Datadog-Azure-Integration-Metadata.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/c179e030-d9a8-3ebf-a0a4-97638f9d0b40.png)

各リソースの読み取り権限を用いてメタデータ(リソースの構成・タグ情報)取得し、Datadog 上の監視情報へのタグが付与されます。

**Datadog Cloud Security Management** を有効化し、追加で [**Microsoft Graph API 権限**へのアクセス](https://docs.datadoghq.com/ja/integrations/guide/azure-graph-api-permissions/)行うことで、[**Misconfiguration(CSPM)**](https://docs.datadoghq.com/ja/security/cloud_security_management/misconfigurations/), [**Identity Risk(CIEM)**](https://docs.datadoghq.com/ja/security/cloud_security_management/identity_risks/) の機能を活用できます。

## Google Cloud integration のアーキテクチャ
Google Cloud integration で取得できる情報は Google Cloud 組織・フォルダ・プロジェクトごと、正確にはサービスアカウントから見えるすべてのプロジェクトです。[^12]
[^12]: 複数のプロジェクトの監視情報を集約する、[指標(メトリクス)スコープ](https://cloud.google.com/monitoring/settings)を利用したスコーピング プロジェクトの場合、外部の監視対象プロジェクトのメトリクスは収集できません。

[サービスアカウントの権限借用](https://cloud.google.com/iam/docs/service-account-overview?hl=ja#impersonation)と<INS>プロジェクトの自動発見</INS>を使用して複数プロジェクトを対象にできます。サービスアカウント権限借用は、対象のプロジェクトに IAM ロールを割り当てることで Datadog クローラー用のサービスアカウントの参照権限を広げられます。

インテグレーションは Datadog 内の [Google Cloud Platform integration 設定ページ](https://app.datadoghq.com/integrations/google-cloud-platform)から発行された **Datadog プリンシパル**を使用して、適切な権限を付与したサービスアカウントを作成し登録することで完了します。ログ収集に必要なリソース(Pub/Sub, Dataflow, ログシンク)は、[手順](https://docs.datadoghq.com/ja/integrations/google_cloud_platform/＃ログ収集)に従って手動で構成します。

![Datadog-GoogleCloud-Integration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/53d729b4-d0b2-9bd1-a242-d0b11309de0c.png)

:::note info
詳細については『[Datadog integrations Deep Dive - Google Cloud 編](https://qiita.com/AoTo0330/items/bfa3f204b491f83bcab1)』で解説しています。
:::

https://qiita.com/AoTo0330/items/bfa3f204b491f83bcab1

### メトリクス収集
![Datadog-GoogleCloud-Integration-Metrics.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/f7de23f8-07e7-6004-9acf-dddab1638236.png)

前述のサービスアカウントの権限を利用して、Datadog クローラーが[前提条件](https://docs.datadoghq.com/ja/integrations/google_cloud_platform/#前提条件)を満たすプロジェクトの **Cloud Monitoring API** へ**約5分に1回**の定期的なアクセスします。

これにより、ほぼすべての Cloud Monitoring に存在するメトリクスを[**7~8分の遅延**で Datadog 上に収集]((https://docs.datadoghq.com/ja/integrations/guide/cloud-metric-delay/#gcp))します。

### ログ収集
![Datadog-GoogleCloud-Integration-Logs.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/09c227c3-9dc5-1b8f-faef-3fadcb5a8b1d.png)

AWS, Azure とは異なり、Cloud Logging ログシンクを Pub/Sub トピックに転送し、[プルサブスクリプション](https://cloud.google.com/pubsub/docs/create-subscription?hl=ja)と Dataflow ジョブでそれらのログを取り出し Datadog へ転送します。

そのため、<INS>対象の Pub/Sub トピックにログを転送する適切な IAM 権限を持たせる</INS>ことで、外部プロジェクトのログや Cloud Logging 以外のデータソースのログを転送できます。

:::note alert
非推奨の方式(Pub/Sub トピックとプッシュサブスクリプションによるログ転送)
![Datadog-GoogleCloud-Integration-Logs-depricated.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/1f64ce6c-876f-33ce-bc60-a9ba4ee2c293.png)

過去に標準的な方法であった、Pub/Sub トピックと[プッシュサブスクリプション](https://cloud.google.com/pubsub/docs/create-push-subscription?hl=ja)を利用する方式は現在**非推奨**となっています。その理由として、<INS>プライベート接続方式が提供されない点</INS>や<INS>ログ転送の信頼性/効率性が担保されない点</INS>があります。
[設定ドキュメント](https://docs.datadoghq.com/ja/logs/guide/collect-google-cloud-logs-with-push/)はトラブルシューティングやレガシーセットアップの変更のためにのみ残されており、こちらの構成での**サポートは提供されません**。
:::

### コスト情報収集
![Datadog-GoogleCloud-Integration-Costs.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/3a8c94cc-9a3c-7a48-2fad-5e881397dbfa.png)

[**Cloud Billing** のデータを **BigQuery** にエクスポート](https://cloud.google.com/billing/docs/how-to/export-data-bigquery?hl=ja)し、Datadog クローラーが定期的にコスト情報を変換・メタデータの付与・収集することで **Datadog Cloud Cost Management** で可視化できるようになります。

インテグレーションで監視対象プロジェクトと異なるプロジェクトに課金情報をエクスポートする場合は、**BigQuery データ転送サービス(BigQuery Data Transfer Service)** で[プロジェクト間のサービスアカウントの承認](https://cloud.google.com/bigquery/docs/enable-transfer-service?hl=ja#cross-project_service_account_authorization)を行いコストデータを収集できます。

### メタデータ収集
![Datadog-GoogleCloud-Integration-Metadata.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/dc69d21d-853e-74b0-4bc3-18be0f898fde.png)

各リソースの読み取り権限を用いてメタデータ(リソースの構成・タグ情報)取得し、Datadog 上の監視情報へのタグが付与されます。

**Datadog Cloud Security Management** を有効化し、デフォルトでも必要とされる権限の中でも主に[**Cloud Asset API**](https://cloud.google.com/asset-inventory/docs/reference/rest)へのアクセスを行うことで、[**Misconfiguration(CSPM)**](https://docs.datadoghq.com/ja/security/cloud_security_management/misconfigurations/), [**Identity Risk(CIEM)**](https://docs.datadoghq.com/ja/security/cloud_security_management/identity_risks/) の機能を活用できます。

## OCI integration のアーキテクチャ
OCI(Oracle Cloud Infrastructure) integration で収集できる情報はテナンシー単位です。

現状、複数テナンシーの監視情報を収集する方法は提供されていません。

![Datadog-OracleCloud-Integration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/4e5d7d82-c12b-6fb9-32c0-254b4a6d805e.png)

### メトリクス収集
![Datadog-GoogleCloud-Integration-Metadata.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/ba4ef142-4af7-e6d1-a3db-e7d81ed02869.png)

Datadog が提供する Terraform スタックを [**OCI Resource Manager(ORM)**](https://docs.oracle.com/ja-jp/iaas/Content/ResourceManager/Concepts/resourcemanager.htm) で使用して、[メトリクス転送スタックの作成](https://docs.datadoghq.com/ja/integrations/oracle_cloud_infrastructure/#メトリクス転送スタックを作成する)します。メトリクスの転送は、**OCI Metrics** をデータソースとして **Function App** から **VCN** 内の S**ervice Gateway**, **NAT Gateway** を経由して送信します。

OCI integration は<INS>メトリクス転送を push 型で行い</INS>、一方でメタデータの収集は別途 API 経由で行います。

![Datadog-OracleCloud-Integration-Metadata.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/5687bd4b-55d8-84da-acaa-75ee73e91741.png)

メタデータ取得は他のクラウドインテグレーションと同様に、権限リソースであるを介して行われます。OCI は権限リソースにユーザーを利用する必要があるため、Datadog は専用の `DatadogAuthUser` を利用します。ユーザーはグループに所属しアクセス・ポリシーによって権限制御されるため、これらも Datadog が提供する Terraform を **ORM** を使用して、[ポリシースタックを作成](https://docs.datadoghq.com/ja/integrations/oracle_cloud_infrastructure/#ポリシースタックを作成する)します。[^13]
[^13]: OCI の IAM は独特な概念を持っているため、詳しくは「[IAMの概要](https://docs.oracle.com/ja-jp/iaas/Content/Identity/getstarted/identity-domains.htm)」をご参照ください。

### ログ収集
![Datadog-OracleCloud-Integration-Logs.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/035cee62-01cf-6384-f7b6-63eb4f097ffa.png)

Datadog が公開している GitHub リポジトリ上から Python コードを使用して **Function App ** を作成し、データソースとして **OCI Logging** か **Object Storage** を対象とし、それらのログは<INS>タグ付け・ログのフィルター・圧縮・暗号化などを経て Datadog Logs intake API に転送</INS>されます。

前者は[**サービスコネクターハブ**](https://docs.oracle.com/ja-jp/iaas/Content/connector-hub/overview.htm)で、後者は [**Object Event**](https://docs.oracle.com/ja-jp/iaas/Content/Events/Concepts/eventsoverview.htm)によって **Function App** をトリガーします。

## おわりに
本記事は『[3大クラウドのDatadog Integrations アーキテクチャ](https://qiita.com/AoTo0330/items/33d7b58a3cfddcbd3fe2)』のアップデートとして執筆しました。

https://qiita.com/AoTo0330/items/33d7b58a3cfddcbd3fe2

Datadog はアップデートが早く、クラウドインテグレーション機能も効率化・機能追加を繰り返し、カスタマイズ性も向上しています。2024年には4大クラウドの4つ目として記載した Oracle Cloud Infrastructure のメトリクス収集機能が追加され、4大クラウドすべてのマネージド監視ソリューションから Datadog に監視情報やリソース情報を連携できるようになりました。

https://www.datadoghq.com/ja/blog/monitor-oci-with-datadog/

また、それぞれのインテグレーションを実際に活用するためにはいくつかの考慮事項があり、こちらは各「Dive Deep」記事でまとめています。クラウドの監視ソリューションとして Datadog を最大限活用するためにも是非ご覧ください🐶