次の方法で共有


Azure リソース ログを Log Analytics ワークスペース、Event Hubs、または Azure Storage に送信する

Azure リソース ログは、Azure リソース内で実行される操作に関する分析情報を提供するプラットフォーム ログです。 リソース ログの内容は、リソースの種類ごとに異なります。 既定では、リソース ログは収集されません。 リソース ログを収集するには、診断設定を有効にして構成するか、データ収集ルールを使用する必要があります。 データ収集ルールの詳細については、「Azure Monitor のデータ収集ルール」を参照してください。 この記事では、各 Azure リソースがそのリソース ログを Log Analytics ワークスペース、Event Hubs、または Azure Storage に送信するために必要な診断設定について説明します。

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

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

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

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

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

リソース固有

リソース固有モードを使用するログの場合、選択されたワークスペース内に、診断設定で選択されたログ カテゴリごとに個別のテーブルが作成されます。 リソース固有のログには、Azure 診断ログに比べて次のような利点があります。

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

リソース固有のログとテーブルについては、「Azure Monitor でサポートされているリソース ログ カテゴリ」を参照してください

Azure 診断モード

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

AzureDiagnostics テーブルには、ログを生成したリソースの resourceId、ログのカテゴリ、ログが生成された時刻に加えて、リソース固有のプロパティも含まれます。

Log Analytics ワークスペース内の AzureDiagnostics テーブルを示すスクリーンショット。

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

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

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

[診断設定] モード セレクターを示すスクリーンショット。

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/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
            "resourceId": "/SUBSCRIPTIONS/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/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": "AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E",
                    "resourceGroupName": "JohnKemTest",
                    "workflowId": "2222cccc-33dd-eeee-ff44-aaaaaa555555",
                    "workflowName": "JohnKemTestLA",
                    "runId": "08587330013509921957",
                    "location": "westus",
                    "actionName": "Send_email"
                },
                "correlation": {
                    "actionTrackingId": "3333dddd-44ee-ffff-aa55-bbbbbbbb6666",
                    "clientTrackingId": "08587330013509921958"
                }
            }
        },
        {
            "time": "2019-07-15T18:01:15.7532989Z",
            "workflowId": "/SUBSCRIPTIONS/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
            "resourceId": "/SUBSCRIPTIONS/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/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": "AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E",
                    "resourceGroupName": "JohnKemTest",
                    "workflowId": "dddd3333-ee44-5555-66ff-777777aaaaaa",
                    "workflowName": "JohnKemTestLA",
                    "runId": "08587330012106702630",
                    "location": "westus",
                    "actionName": "Send_email"
                },
                "correlation": {
                    "actionTrackingId": "ffff5555-aa66-7777-88bb-999999cccccc",
                    "clientTrackingId": "08587330012106702632"
                }
            }
        }
    ]
}

Azure Storage への送信

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

Note

アーカイブに代わる方法としては、低コストで長期保有の 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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": "a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1","category": "NetworkSecurityGroupRuleCounter","resourceId": "/SUBSCRIPTIONS/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/RESOURCEGROUPS/TESTRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/TESTNSG","operationName": "NetworkSecurityGroupCounters","properties": {"vnetResourceGuid": "{aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e}","subnetPrefix": "10.3.0.0/24","macAddress": "000123456789","ruleName": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/testresourcegroup/providers/Microsoft.Network/networkSecurityGroups/testnsg/securityRules/default-allow-rdp","direction": "In","type": "allow","matchedConnections": 1988}}

Azure Monitor パートナーとの統合

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

次のステップ