Datadog integrations Deep Dive - Azure 編

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

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

本記事は『[【完全解説】4大クラウドの Datadog integrations アーキテクチャ【2024年版】](https://qiita.com/AoTo0330/items/33d7b58a3cfddcbd3fe2)』で解説仕切れなかった、<INS>Datadog Azure integration の細かな仕様と注意点</INS>を解説します。

主にメトリクス・ログ収集に関する Azure integration の様々なオプションについて解説しているので、参考にしていただけると幸いです🐶

## Azure integration の全体像
### デフォルトのデータ転送
![Datadog-Azure-Integration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/a816d46e-4b84-4b8f-ea09-6d655c8ac1b5.png)

Datadog Azure integration は主に Azure Monitor からのメトリクス・ログ情報の収集と、各リソースのメタデータの参照と監視情報への紐付けを行います。

### Azure integration のネットワーク接続
Azure integration はメトリクス・ログを Datadog Organization 毎に用意された API Key による認証でデータを適切な Datadog Org に収集します。この時、Datadog Site として **US3** を選択することで、<INS>暗黙的に Azure バックボーン通信</INS>が行われ、安全性と効率性が高い状態での監視データ連携ができます。

https://learn.microsoft.com/ja-jp/azure/networking/microsoft-global-network#get-the-premium-cloud-network

[Azure Private Link を介して Datadog に接続する](https://docs.datadoghq.com/ja/agent/guide/azure-private-link/)オプションはありますが、AWS とは異なり Private Link を介した Azure Monitor ログの送信は**正式にはサポートされていません**。

### Azure Native のデータ転送
![Datadog-Azure-Native-Integration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/ae078a6e-4128-8269-c0c3-87993dc8d22e.png)

前述の **US3** の Datadog Site のみ、[**Azure Native integration**](https://docs.datadoghq.com/ja/integrations/guide/azure-native-manual-setup/?site=us3) が利用できます。これは、デフォルトの[**アプリケーション登録**](https://learn.microsoft.com/ja-jp/security/zero-trust/develop/app-registration)でのメトリクス収集と **診断設定, Event Hub, Function App** でのログ収集の代わりに **Datadog リソース** と呼ばれる**外部 ISV リソース**を作成します。

Datadog リソースは Azure マネージドなリソースとして、デフォルトの Azure Monitor メトリクスとログを作成・リンクした Datadog Organization に自動的に送信します。

この仕組みはデフォルトのデータ転送と異なり、一時的なカスタマートークンにより[システム割り当てのマネージド ID](https://learn.microsoft.com/ja-jp/entra/identity/managed-identities-azure-resources/overview#managed-identity-types) を借用し、Azure 環境からメトリクスを継続的に検出・収集します。

このワークフローは Azure と統合された Datadog 内で自動的に行われ、**継続的なデータ収集**が実現されます。詳細なアーキテクチャと仕組みは、『[Azure インテグレーションアーキテクチャと構成](https://docs.datadoghq.com/ja/integrations/guide/azure-architecture-and-configuration/?site=us3)』で詳しく説明されています。


## メトリクス収集
![Datadog-Azure-Integration-Metrics.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/af3d1136-6f0d-411d-666c-cec23b8e8d37.png)

### ニアリアルタイムのメトリクス収集
Azure Monitor メトリクスを操作できる [Azure Monitor Metrics Data plane API](https://learn.microsoft.com/ja-jp/azure/azure-monitor/essentials/data-plane-versus-metrics-export) は、2023年後半に従来の [Azure Monitor Metrics REST API](https://learn.microsoft.com/ja-jp/rest/api/monitor/) に代わり Datadog Azure integration で利用され始めました。詳細は[昨年のブログ](https://qiita.com/AoTo0330/items/10c18f9de0dbe4fce61a)にまとめています。

https://qiita.com/AoTo0330/items/10c18f9de0dbe4fce61a

この高効率・高パフォーマンスな API により、Azure integration で利用される Datadog クローラーは**約2分に1回**の高頻度でメトリクスデータを収集します。これにより、メトリクスストリーミングを提供していない Azure Monitor メトリクスをニアリアルタイムに Datadog へ連携できます。

### 収集メトリクスの除外・制限
メトリクスの連携が不要な Azure VM, Azure App Service Plan は**ホワイト/ブラックリスト**の両形式で<INS>リソースタグに応じたメトリクス収集の限定</INS>ができます。これにより、Azure VM, Azure Appservice Plan のインスタンス数に応じた Datadog 上の課金を制限できます。

Azure Web App, Function App など App Service Plan を実行環境とするリソースは、Standard ティア以上の場合 App Service Plan インスタンス数に応じた Datadog 上の課金がありますが、Shared, Dynamic, Free ティアの場合は課金に影響しません。
詳細は「[Azure インテグレーションの請求](https://docs.datadoghq.com/ja/account_management/billing/azure/)」ガイドを併せてご参照ください。

### Datadog 独自の生成メトリクス
![Datadog-Azure-Integration-Metadata.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/f855133d-b990-6b09-90ba-5e06b4400843.png)

Datadog は 2020年より、Azure integration を強化しリソース固有のメタデータを Azure Metadata API から自動的に収集し、独自メトリクス・タグを付与します。対象は **App Services, Azure Functions, App Service Plans, Azure SQL Databases, Azure Load Balancers, Azure Virtual Networks(VNet)** などのサービスと各サービスの**利用量・クォータ・リソース数・ステータス**です。

https://www.datadoghq.com/ja/blog/datadog-generated-metrics-azure/

独自メトリクスはサービス毎に提供されるものが異なりますが、サービスの特性に合わせてより詳細な分類や可視化をしたい際に役立つものが多くあります。例えば、すべてのサービスに共通するリソース数メトリクスは `azure.<サービス名>.count` の形式で簡単にサブスクリプション上のリソースの集計が実現できます。

### アプリケーション登録の仕組み
Azure integration は **Microsoft Entra ID** の[アプリケーションの登録](https://learn.microsoft.com/ja-jp/security/zero-trust/develop/app-registration)により実現されます。Microsoft Entra ID に Datadog アプリケーションを登録すると、アプリは[**アプリケーションオブジェクト**](https://learn.microsoft.com/ja-jp/entra/identity-platform/app-objects-and-service-principals#application-object)と[**サービスプリンシパル**](https://learn.microsoft.com/ja-jp/entra/identity-platform/app-objects-and-service-principals#service-principal-object)で表されます。

**アプリケーションオブジェクト**[^1]は、「サービスがアプリケーションにアクセスするためにトークンを発行する方法」「アプリケーションがアクセスする必要があるリソース」「アプリケーションが実行できるアクション」を示します。つまり、Datadog からのアクセスにどのように・どのような権限が与えられ何が実行できるか、が事前に定めれます。
[^1]: アプリケーションオブジェクトのプロパティのスキーマは、Microsoft Graph [Application エンティティ](https://learn.microsoft.com/ja-jp/graph/api/resources/application)によって定義されています。

**サービスプリンシパル**[^2]は、アプリを登録すると自動的に作成され、アプリケーションオブジェクトから特定のプロパティを継承します。サービスプリンシパルオブジェクトは、「特定のテナント内でアプリが実際に実行できること」「アプリにアクセスできるユーザー」「アプリからアクセスできるリソース」を定義します。
[^2]: サービス プリンシパル オブジェクトのプロパティのスキーマは、Microsoft Graph [ServicePrincipal エンティティ](https://learn.microsoft.com/ja-jp/graph/api/resources/serviceprincipal)によって定義されています。

![Datadog-Azure-Integration-Authentication.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/2efb2bc4-41ab-7568-42f6-537d94a668dd.png)

認証は[**サービス プリンシパル メソッド**](https://learn.microsoft.com/ja-jp/azure-sphere/deployment/authenticate-options?view=azure-sphere-legacy#service-principal-method)に沿って行われます。Datadog クローラーからのアクセスに応じて、サービスプリンシパルは登録されたアプリを確認し、エンドポイントに要求を送信し **Microsoft ID プラットフォーム**と通信します。Datadog から送信されたクライアント ID・シークレットにより認証されると、アプリは Datadog にアクセストークンを返し、Datadog ではこれを一定期間キャッシュします。

### Azure インテグレーションの代替構成(非推奨)
デフォルトで、サービスプリンシパル(デフォルト)またはマネージド ID(Native) は **`Monitoring Reader` 権限**を持ち、**親サブスクリプション**をスコープにします。これらの権限とスコープを使用するることが**推奨**されていますが、権限とスコープを制限することも可能です。

<INS>サブスクリプション未満のリソースグループ単位・個別リソース単位をスコープ</INS>として、サービスプリンシパル・マネージド ID を割り当てることで、Datadog が監視できるリソースがサブスクリプションの一部に限定できます。ただし、バッチ処理が無効化されることによる**遅延の増加**・**Azure 内のコスト上昇**・**新規リソースのオートディスカバリーの制限**などのデメリットが考えられます。

<INS>`Monitoring Reader` 権限未満の権限</INS>をサービスプリンシパル・マネージド ID に割り当てることで、Datadog が収集できる情報を制限できます。しかし、適切な権限を付与することは難しく、権限不足によるデータ消失や Datadog の特定機能が利用できなくなる可能性があります。

## ログ収集
![Datadog-Azure-Integration-Logs.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/f118a571-7104-7c20-ce7a-127d22e85cbb.png)

### ログソースに応じた関数のデプロイ
上記の構成図でも **Function App** は1つにしていますが、[公式ドキュメント](https://docs.datadoghq.com/ja/logs/guide/azure-logging-guide/)によると**Azure Monitor ログ**に保存されているActivity/Resource ログと **Blob Storage** に保存されているログのどちらのソースからログを送信するかで、異なるコードを Function App をデプロイする案内があります。

具体的には、前者の Azure Monitor ログの場合は [Datadog-Azure 関数コード(Azure Monitor)](https://github.com/DataDog/datadog-serverless-functions/blob/master/azure/activity_logs_monitoring/index.js)は GitHub の`datadog-serverless-functions/azure/activity_logs_monitoring/index.js` から、後者の Blog Storage ログの場合は [Datadog-Azure 関数コード(Blob Storage)](https://github.com/DataDog/datadog-serverless-functions/blob/master/azure/blobs_logs_monitoring/index.js)は GitHub の`datadog-serverless-functions/azure/blobs_logs_monitoring/index.js` から、どちらも JavaScript コードが用意されています。[^4]
[^4]: さらに、Datadog-Azure 関数コード(Blob Storage) は Function App の実行環境として Windows OS の指定が手順として指定されています。

実は、Datadog-Azure 関数コード(Azure Monitor) は Datadog-Azure 関数コード(Blob Storage) の拡張版であり、**Microsoft Defender for Cloud**や **Activity ログ**の**ログ解析やメタデータ抽出**と**再送処理**が実装されています。

さらに、利用する Datadog Logs intake API が `v1` と `v2` の差異があり、**個人的には**どちらの場合も Datadog-Azure 関数コード(Azure Monitor) を利用されることをお勧めします。[^3]
[^3]: 公式の案内とは異なるため、サポートが提供されない可能性があります。

### 送信するログの制限
すべての Azure Monitor 上のログを Datadog に送信したくない場合は、作成する診断設定により一定の制限が可能です。Activity ログの場合は[カテゴリ](https://learn.microsoft.com/ja-jp/azure/azure-monitor/essentials/activity-log-schema#categories)毎に、Resource ログの場合はリソース毎に診断設定の作成を限定できます。

一方で、診断設定による詳細なフィルタリングは許可されていないため、同一カテゴリやリソース内のログをログの内容によって送信するログは制限できません。この場合、Datadog の [**Logging without Limits™︎**](https://docs.datadoghq.com/logs/guide/getting-started-lwl/) を活用して Datadog に取り込み後に保持するログを制限することでログによる課金の増加を抑制できます。

## おわりに
本記事では Dtadog - Azure integration の理解を深めるために**オリジナルの図**と共に解説しました。

Azure Native インテグレーションは Azure 環境をメインとする方々に強くお勧めできる、ユーザーの管理範囲が最小限となったマネージドリソースです。オプションで設定できる範囲が限定されている Azure integration ですが、詳細を理解することで実際に利用する際のベストケースを考慮できるはずです。

基本的な機能については『[【完全解説】4大クラウドの Datadog integrations アーキテクチャ【2024年版】](https://qiita.com/AoTo0330/items/33d7b58a3cfddcbd3fe2)』でも説明しているため、こちらも是非ご参照ください。