Datadog integrations Deep Dive - Azure 編

はじめに

こんにちは、Datadog Japan で Sales Engineer をしている AoTo です。

本記事は『【完全解説】4大クラウドの Datadog integrations アーキテクチャ【2024年版】』で解説仕切れなかった、Datadog Azure integration の細かな仕様と注意点を解説します。

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

Azure integration の全体像

デフォルトのデータ転送

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

Azure integration のネットワーク接続

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

Azure Private Link を介して Datadog に接続するオプションはありますが、AWS とは異なり Private Link を介した Azure Monitor ログの送信は正式にはサポートされていません。

Azure Native のデータ転送

前述の US3 の Datadog Site のみ、Azure Native integration が利用できます。これは、デフォルトのアプリケーション登録でのメトリクス収集と 診断設定, Event Hub, Function App でのログ収集の代わりに Datadog リソース と呼ばれる外部 ISV リソースを作成します。

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

この仕組みはデフォルトのデータ転送と異なり、一時的なカスタマートークンによりシステム割り当てのマネージド ID を借用し、Azure 環境からメトリクスを継続的に検出・収集します。

このワークフローは Azure と統合された Datadog 内で自動的に行われ、継続的なデータ収集が実現されます。詳細なアーキテクチャと仕組みは、『Azure インテグレーションアーキテクチャと構成』で詳しく説明されています。

メトリクス収集

ニアリアルタイムのメトリクス収集

Azure Monitor メトリクスを操作できる Azure Monitor Metrics Data plane API は、2023年後半に従来の Azure Monitor Metrics REST API に代わり Datadog Azure integration で利用され始めました。詳細は昨年のブログにまとめています。

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

収集メトリクスの除外・制限

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

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

Datadog 独自の生成メトリクス

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

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

アプリケーション登録の仕組み

Azure integration は Microsoft Entra ID のアプリケーションの登録により実現されます。Microsoft Entra ID に Datadog アプリケーションを登録すると、アプリはアプリケーションオブジェクトとサービスプリンシパルで表されます。

アプリケーションオブジェクト¹は、「サービスがアプリケーションにアクセスするためにトークンを発行する方法」「アプリケーションがアクセスする必要があるリソース」「アプリケーションが実行できるアクション」を示します。つまり、Datadog からのアクセスにどのように・どのような権限が与えられ何が実行できるか、が事前に定めれます。

サービスプリンシパル²は、アプリを登録すると自動的に作成され、アプリケーションオブジェクトから特定のプロパティを継承します。サービスプリンシパルオブジェクトは、「特定のテナント内でアプリが実際に実行できること」「アプリにアクセスできるユーザー」「アプリからアクセスできるリソース」を定義します。

認証はサービス プリンシパル メソッドに沿って行われます。Datadog クローラーからのアクセスに応じて、サービスプリンシパルは登録されたアプリを確認し、エンドポイントに要求を送信し Microsoft ID プラットフォームと通信します。Datadog から送信されたクライアント ID・シークレットにより認証されると、アプリは Datadog にアクセストークンを返し、Datadog ではこれを一定期間キャッシュします。

Azure インテグレーションの代替構成(非推奨)

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

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

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

ログ収集

ログソースに応じた関数のデプロイ

上記の構成図でも Function App は1つにしていますが、公式ドキュメントによるとAzure Monitor ログに保存されているActivity/Resource ログと Blob Storage に保存されているログのどちらのソースからログを送信するかで、異なるコードを Function App をデプロイする案内があります。

具体的には、前者の Azure Monitor ログの場合は Datadog-Azure 関数コード(Azure Monitor)は GitHub のdatadog-serverless-functions/azure/activity_logs_monitoring/index.js から、後者の Blog Storage ログの場合は Datadog-Azure 関数コード(Blob Storage)は GitHub のdatadog-serverless-functions/azure/blobs_logs_monitoring/index.js から、どちらも JavaScript コードが用意されています。³

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

さらに、利用する Datadog Logs intake API が v1 と v2 の差異があり、個人的にはどちらの場合も Datadog-Azure 関数コード(Azure Monitor) を利用されることをお勧めします。⁴

送信するログの制限

すべての Azure Monitor 上のログを Datadog に送信したくない場合は、作成する診断設定により一定の制限が可能です。Activity ログの場合はカテゴリ毎に、Resource ログの場合はリソース毎に診断設定の作成を限定できます。

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

おわりに

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

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

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

1. アプリケーションオブジェクトのプロパティのスキーマは、Microsoft Graph Application エンティティによって定義されています。 ↩

2. サービス プリンシパル オブジェクトのプロパティのスキーマは、Microsoft Graph ServicePrincipal エンティティによって定義されています。 ↩

3. さらに、Datadog-Azure 関数コード(Blob Storage) は Function App の実行環境として Windows OS の指定が手順として指定されています。 ↩

4. 公式の案内とは異なるため、サポートが提供されない可能性があります。 ↩