Azure リソース ログ データを送信する

Azure リソース ログは、Azure リソース内で実行された操作に関する分析情報を提供するプラットフォーム ログです。 リソース ログの内容は、Azure サービスとリソースの種類によって異なります。 既定では、リソース ログは収集されません。 この記事では、各 Azure リソースがそのリソース ログを異なる宛先に送信するために必要な診断設定について説明します。

Log Analytics ワークスペースに送信する

次のような Azure Monitor ログの機能を有効にするには、リソース ログを Log Analytics ワークスペースに送信します。

  • リソース ログ データを、Azure Monitor によって収集されたその他の監視データと関連付けます。
  • 複数の Azure リソース、サブスクリプション、およびテナントのログ エントリを 1 つの場所に統合して、まとめて分析できるようにします。
  • ログ クエリを使用して複雑な分析を実行し、ログ データから詳細な分析情報を得ます。
  • 複雑なアラート ロジックを持つログ検索アラートを使用します。

リソース ログを Log Analytics ワークスペースに送信するには、診断設定を作成します。 このデータは、「Azure Monitor Logs の構造」の説明に従って、テーブルに格納されます。 リソース ログで使用されるテーブルは、リソースで使用されているコレクションの種類によって異なります。

  • Azure 診断 - すべてのデータが AzureDiagnostics テーブルに書き込まれます。
  • リソース固有 - データは、リソースのカテゴリごとに個別のテーブルに書き込まれます。

リソース固有

このモードでは、診断設定で選択されたカテゴリごとに、個別のテーブルが選択されたワークスペース内に作成されます。 次の理由から、この方法をお勧めします。

  • ログ クエリ内のデータの操作が容易になる。
  • スキーマとその構造の検出の可能性が高まる。
  • インジェストの待ち時間とクエリ時間でパフォーマンスが向上する。
  • 特定のテーブルに対して Azure ロールベースのアクセス制御権限を付与する機能が提供される。

すべての Azure サービスは、最終的にはリソース固有モードに移行します。

次の例では、3 つのテーブルを作成します。

  • テーブル Service1AuditLogs

    リソース プロバイダー カテゴリ A B C
    サービス 1 AuditLogs x1 y1 z1
    サービス 1 AuditLogs x5 y5 z5
    ...
  • テーブル Service1ErrorLogs

    リソース プロバイダー カテゴリ D E F
    サービス 1 ErrorLogs q1 w1 e1
    サービス 1 ErrorLogs q2 w2 e2
    ...
  • テーブル Service2AuditLogs

    リソース プロバイダー カテゴリ G I
    サービス 2 AuditLogs j1 k1 l1
    サービス 2 AuditLogs j3 k3 l3
    ...

Azure 診断モード

このモードでは、任意の診断設定に基づくすべてのデータが、AzureDiagnostics テーブルに収集されます。 これは、ほとんどの Azure サービスで現在使用されている従来の方法です。 複数の種類のリソースから同じテーブルにデータが送信されるため、そのスキーマは、収集されるすべての種類のデータ型のスキーマのスーパーセットになります。 このテーブルの構造の詳細と、この潜在的に多数の列でどのように機能するかについては、AzureDiagnostics のリファレンスを参照してください。

次のデータ型の診断設定が同じワークスペースに収集される例を考えてみます。

  • サービス 1 の監査ログには、列 A、B、C から構成されるスキーマがあります
  • サービス 1 のエラー ログには、列 D、E、F から構成されるスキーマがあります
  • サービス 2 の監査ログには、列 G、H、I から構成されるスキーマがあります

AzureDiagnostics テーブルは次の例のようになります。

ResourceProvider カテゴリ A B 貸方 借方 E G I
Microsoft.Service1 AuditLogs x1 y1 z1
Microsoft.Service1 ErrorLogs q1 w1 e1
Microsoft.Service2 AuditLogs j1 k1 l1
Microsoft.Service1 ErrorLogs q2 w2 e2
Microsoft.Service2 AuditLogs j3 k3 l3
Microsoft.Service1 AuditLogs x5 y5 z5
...

コレクション モードを選択する

ほとんどの Azure リソースでは、ユーザーに選択肢を与えることなく、Azure 診断またはリソース固有モードでワークスペースにデータが書き込まれます。 詳細については、「Azure リソース ログの共通およびサービス固有のスキーマ」を参照してください。

最終的にすべての Azure サービスで、リソース固有モードが使用されます。 この移行の一環として、一部のリソースでは診断設定でモードを選択できます。 リソース固有モードを使用すると、データの管理がしやすくなるため、新しい診断設定にはこのモードを指定してください。 また、後で複雑な移行を回避するのにも役立ちます。

Screenshot that shows the Diagnostics settings mode selector.

Note

Azure Resource Manager テンプレートを使用してコレクション モードを設定する例については、「Azure Monitor の診断設定用の Resource Manager テンプレートのサンプル」を参照してください。

既存の診断設定をリソース固有モードに変更できます。 この場合、既に収集されたデータは、ワークスペースの保持期間の設定に従って削除されるまで、AzureDiagnostics テーブル内に残ります。 新しいデータは専用のテーブルに収集されます。 両方のテーブルのデータに対してクエリを実行するには、union 演算子を使用します。

リソース固有モードをサポートしている Azure サービスに関するお知らせは、Azure の更新情報ブログを引き続きご覧ください。

Azure Event Hubs に送信する

リソース ログを Azure の外部に送信するには、イベント ハブに送信します。 たとえば、リソース ログは、サードパーティの SIEM またはその他のログ分析ソリューションに送信される場合があります。 イベント ハブからのリソース ログは、各ペイロードのレコードを含む records 要素を含む JSON 形式で消費されます。 「Azure リソース ログの共通およびサービス固有のスキーマ」で説明されているように、スキーマはリソースの種類によって異なります。

次のサンプル出力データは、リソース ログの Azure Event Hubs からのものです。

{
    "records": [
        {
            "time": "2019-07-15T18:00:22.6235064Z",
            "workflowId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
            "resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA/RUNS/08587330013509921957/ACTIONS/SEND_EMAIL",
            "category": "WorkflowRuntime",
            "level": "Error",
            "operationName": "Microsoft.Logic/workflows/workflowActionCompleted",
            "properties": {
                "$schema": "2016-04-01-preview",
                "startTime": "2016-07-15T17:58:55.048482Z",
                "endTime": "2016-07-15T18:00:22.4109204Z",
                "status": "Failed",
                "code": "BadGateway",
                "resource": {
                    "subscriptionId": "00000000-0000-0000-0000-000000000000",
                    "resourceGroupName": "JohnKemTest",
                    "workflowId": "243aac67fe904cf195d4a28297803785",
                    "workflowName": "JohnKemTestLA",
                    "runId": "08587330013509921957",
                    "location": "westus",
                    "actionName": "Send_email"
                },
                "correlation": {
                    "actionTrackingId": "29a9862f-969b-4c70-90c4-dfbdc814e413",
                    "clientTrackingId": "08587330013509921958"
                }
            }
        },
        {
            "time": "2019-07-15T18:01:15.7532989Z",
            "workflowId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
            "resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA/RUNS/08587330012106702630/ACTIONS/SEND_EMAIL",
            "category": "WorkflowRuntime",
            "level": "Information",
            "operationName": "Microsoft.Logic/workflows/workflowActionStarted",
            "properties": {
                "$schema": "2016-04-01-preview",
                "startTime": "2016-07-15T18:01:15.5828115Z",
                "status": "Running",
                "resource": {
                    "subscriptionId": "00000000-0000-0000-0000-000000000000",
                    "resourceGroupName": "JohnKemTest",
                    "workflowId": "243aac67fe904cf195d4a28297803785",
                    "workflowName": "JohnKemTestLA",
                    "runId": "08587330012106702630",
                    "location": "westus",
                    "actionName": "Send_email"
                },
                "correlation": {
                    "actionTrackingId": "042fb72c-7bd4-439e-89eb-3cf4409d429e",
                    "clientTrackingId": "08587330012106702632"
                }
            }
        }
    ]
}

Azure Storage への送信

リソース ログを Azure Storage に送信し、アーカイブ用に保持します。 診断設定の作成後、有効にしたいずれかのログ カテゴリのイベントが発生するとすぐ、ストレージ アカウントにストレージ コンテナーが作成されます。

注意

別のアーカイブ方法として、アーカイブ ポリシーを使用して、リソース ログを Log Analytics ワークスペースに送信することもできます。

コンテナー内の BLOB には、次の名前付け規則が使用されます。

insights-logs-{log category name}/resourceId=/SUBSCRIPTIONS/{subscription ID}/RESOURCEGROUPS/{resource group name}/PROVIDERS/{resource provider name}/{resource type}/{resource name}/y={four-digit numeric year}/m={two-digit numeric month}/d={two-digit numeric day}/h={two-digit 24-hour clock hour}/m=00/PT1H.json

ネットワーク セキュリティ グループの BLOB には、この例のような名前を付けることができます。

insights-logs-networksecuritygrouprulecounter/resourceId=/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/TESTRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUP/TESTNSG/y=2016/m=08/d=22/h=18/m=00/PT1H.json

各 PT1H.json BLOB には、BLOB URL で指定されている時間に受信したログ ファイルからのイベントを含む JSON オブジェクトが含まれています。 現在の時間中、イベントは生成された時間に関係なく、受信されたときに PT1H.json ファイルに追加されます。 BLOB は 1 時間ごとに作成されるため、URL の分を示す数値 (m=00) は常に 00 です。

PT1H.json ファイル内では、各イベントは、次の形式で保存されます。 これには一般的な最上位スキーマが使用されますが、「リソース ログのスキーマ」で説明されているように、各 Azure サービスに固有です。

Note

ログは、生成された時間に関係なく、ログが受信された時刻に基づいて BLOB に書き込まれます。 つまり、BLOB には、BLOB の URL で指定されている時間外のログ データが含まれる可能性があるということです。 古いテレメトリのアップロードがサポートされている Application Insights のようなデータ ソースの場合、BLOB には過去 48 時間のデータが含まれている可能性があります。
新しい時間単位の開始時に、新しいログは新しい時間の BLOB に書き込まれている一方、既存のログが依然として前の時間の BLOB に書き込まれてしまう可能性があります。

{"time": "2016-07-01T00:00:37.2040000Z","systemId": "46cdbb41-cb9c-4f3d-a5b4-1d458d827ff1","category": "NetworkSecurityGroupRuleCounter","resourceId": "/SUBSCRIPTIONS/s1id1234-5679-0123-4567-890123456789/RESOURCEGROUPS/TESTRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/TESTNSG","operationName": "NetworkSecurityGroupCounters","properties": {"vnetResourceGuid": "{12345678-9012-3456-7890-123456789012}","subnetPrefix": "10.3.0.0/24","macAddress": "000123456789","ruleName": "/subscriptions/ s1id1234-5679-0123-4567-890123456789/resourceGroups/testresourcegroup/providers/Microsoft.Network/networkSecurityGroups/testnsg/securityRules/default-allow-rdp","direction": "In","type": "allow","matchedConnections": 1988}}

Azure Monitor パートナーとの統合

リソース ログは、Azure に完全に統合されたパートナー ソリューションに送信することもできます。 これらのソリューションのリストと構成方法の詳細については、Azure Monitor パートナーとの統合に関する記事をご覧ください。

次のステップ