HTTP データ コレクター API からログ インジェスト API に移行して Azure Monitor ログにデータを送信する

Azure Monitor ログ インジェスト API では、レガシ HTTP データ コレクター API よりも、ログの取り込みとテーブルの管理において、より優れた処理能力と柔軟性が提供されます。 この記事では、データ コレクター API とログ インジェスト API の違いについて説明し、新しいログ インジェスト API に移行するためのガイダンスとベスト プラクティスを提供します。

注意

Morten Insiderorp Knudsen は Microsoft MVP としてこの記事に貢献し、重要なフィードバックを提供しました。 ログ インジェスト API のセットアップと継続的な使用を自動化する方法の例については、Morten の一般公開されている AzLogDcrIngestPS PowerShell モジュールを参照してください。

ログ インジェスト API の利点

ログ インジェスト API には、データ コレクター API に比べて次の利点があります。

  • 変換がサポートされています。これにより、変換先テーブルに取り込まれる前にデータを変更できます (フィルター処理やデータ操作など)。
  • 複数の変換先にデータを送信できます。
  • 変換先テーブル スキーマ (列名を含む) と、ソース データ スキーマが変更されたときに新しい列を変換先テーブルに追加するかどうかを管理できます。

前提条件

この記事で説明する移行手順では、次のものがあることを前提としています。

必要なアクセス許可

アクション 必要なアクセス許可
データ収集エンドポイントを作成します。 Microsoft.Insights/dataCollectionEndpoints/write アクセス許可。これは、たとえば、監視共同作成者の組み込みロールによって提供されます。
データ収集ルールを作成または変更します。 Microsoft.Insights/DataCollectionRules/Write アクセス許可。これは、たとえば、監視共同作成者の組み込みロールによって提供されます。
Data Collector API を使用するテーブルをデータ収集ルールと Log Ingestion API に変換します。 Microsoft.OperationalInsights/workspaces/tables/migrate/action アクセス許可。これは、たとえば、Log Analytics 共同作成者の組み込みロールによって提供されます。
新しいテーブルを作成するか、テーブル スキーマを変更します。 microsoft.operationalinsights/workspaces/tables/write アクセス許可。これは、たとえば、Log Analytics 共同作成者の組み込みロールによって提供されます。
Log Ingestion API を呼び出す DCR にアクセス許可を割り当てる」を参照してください。

ログ インジェスト API に必要な新しいリソースを作成する

ログ インジェスト API では、HTTP データ コレクター API では必要ない 2 種類の新しいリソースを作成する必要があります。

既存のカスタム テーブルを移行するか、新しいテーブルを作成する

現時点で、Data Collector API を使用してデータの送信先となっている既存のカスタム テーブルがある場合は、次のことができます。

  • ログ インジェスト API を使用して同じテーブルに引き続きデータを取り込むには、テーブルを移行します。

  • 既存のテーブルとデータを維持し、ログ インジェスト API を使用してデータを取り込む新しいテーブルを設定します。 準備ができたら、以前のテーブルを削除できます。

    これは、特に既存のテーブルに変更を加える必要がある場合に推奨されるオプションです。 既存のデータ型を変更し、既存のデータ コレクター API カスタム テーブルに対して複数のスキーマ変更を行うと、エラーが発生する可能性があります。

ヒント

データ コレクター API を使用するテーブルを識別するには、テーブルのプロパティを表示します。 データ コレクター API を使用するテーブルの Type プロパティはカスタム テーブル (クラシック) に設定されています。 旧式の Log Analytics エージェント (MMA) でデータを取り込むエージェントでも、Type プロパティがカスタム テーブル (クラシック) に設定されています。 MMA テーブルを変換する前に、必ず Log Analytics エージェントから Azure Monitor エージェントに移行してください。 移行しない場合、テーブルの変換後、これらのテーブルでデータをカスタム フィールドに取り込むことを停止します。

こちらの表は、各オプションに関する留意すべき考慮事項をまとめたものです。

テーブルの移行 サイド バイ サイドの実装
テーブル名と列名 既存のテーブル名を再利用します。
列の名前付けオプション:
- 新しい列名を使用し、新しい名前の列に受信データを送信する変換を定義します。
- 以前の名前を引き続き使用します。
新しいテーブル名を自由に設定します。
新しいテーブルに切り替える前に、統合、ダッシュボード、アラートを調整する必要があります。
移行手順 1 回限りのテーブル移行です。 移行したテーブルをロールバックすることはできません。 移行は、テーブルごとに段階的に行うことができます。
移行後 HTTP データ コレクター API を使用して、既存の列に引き続きデータを取り込むことができます (カスタム列は除きます)。
ログ インジェスト API のみを使用して、新しい列にデータを取り込みます。
以前のテーブル内のデータは、保持期間が終了するまで使用できます。
初めて新しいテーブルを設定するか、スキーマを変更するときには、データの変更が変換先テーブルに表示され始めるまでに 10 - 15 分かかる場合があります。

データ コレクター API を使用するテーブルをデータ収集ルールとログ インジェスト API に変換するには、テーブルに対して次の API 呼び出しを発行します。

POST https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/{tableName}/migrate?api-version=2021-12-01-preview

この呼び出しはべき等であるため、テーブルが既に変換されている場合は効果がありません。

API 呼び出しにより、そのテーブルですべての DCR ベースのカスタム ログ機能が有効になります。 データ コレクター API では引き続き、既存の列にデータが取り込まれますが、新しい列は作成されません。 以前に定義したカスタム フィールドへの入力はすべて継続されません。 既存のテーブルをデータ収集ルールを使用するように移行するもう 1 つの方法ですが、必ずしもログ インジェスト API によってテーブルにワークスペース変換が適用されるとは限りません。

重要

  • 列名は、先頭を文字にする必要があり、最大 45 文字の英数字とアンダースコア (_) で構成できます。
  • _ResourceIdid_ResourceId_SubscriptionIdTenantIdTypeUniqueIdTitle は予約されている列名です。
  • ユーザーが Azure テーブルに追加するカスタム列には、サフィックス _CF が必要です。
  • Log Analytics ワークスペースのテーブル スキーマを更新する場合は、新しい列または変更された列にデータを取り込むため、データ収集ルールの入力ストリーム定義も更新する必要があります。

ログ インジェスト API を呼び出す

ログ インジェスト API を使用すると、呼び出しごとに最大 1 MB の圧縮データまたは非圧縮データを送信できます。 1 MB を超えるデータを送信する必要がある場合は、複数の呼び出しを並列で送信できます。 これは、呼び出しごとに最大 32 MB のデータを送信できるデータ コレクター API からの変更です。

ログ インジェスト API を呼び出す方法については、ログ インジェスト REST API 呼び出しに関するページを参照してください。

ソース データ オブジェクトの変更に基づいてテーブル スキーマとデータ収集ルールを変更する

データ コレクター API では、ソース データ オブジェクト スキーマが変更されたときに変換先テーブル スキーマが自動的に調整されますが、ログ インジェスト API では調整されません。 これにより、作成する予定のない列に新しいデータが収集されることがなくなります。

ソース データ スキーマを変更する場合、次のことができます。

  • 変換先テーブル スキーマデータ収集ルールを変更して、ソース データ スキーマの変更に合わせます。
  • データ収集ルールで変換を定義して、新しいデータを変換先テーブルの既存の列に送信します。
  • 変換先テーブルとデータ収集ルールは変更しません。 この場合、新しいデータは取り込まれません。

Note

列名は、列に対して定義された元のデータ型と異なるデータ型では再利用することはできません。

次のステップ