你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Monitor 中的资源日志

2025-07-22

Azure 资源日志提供有关在 Azure 资源上执行的操作的见解。对于每种资源类型，资源日志的内容不同。它们可以包含有关对资源执行的操作、这些操作的状态以及其他详细信息，这些信息可帮助你了解资源的运行状况和性能。

收集资源日志

默认不会收集资源日志。若要收集这些资源，必须为每个 Azure 资源创建诊断设置。有关详细信息，请参阅 Azure Monitor 中的诊断设置。以下信息提供有关可将资源日志发送到的不同目标的更多详细信息。

注释

资源日志不会完全丢失。它们基于存储和转发体系结构，旨在以经济实惠的方式每天大规模移动 PB 级数据。此功能包括跨平台的内置冗余和重试，但不提供事务性保证。每当标识永久性数据丢失源时，其解决方法和将来的预防将优先进行。在 Azure 中分发的临时非重复服务问题中，仍可能会发生少量数据丢失。

目的地

创建诊断设置时，可以选择将资源日志发送到以下一个或多个目标。您选择的目标是基于您的分析需求、数据保留需求以及与其他系统集成的需求。

以下部分介绍每个目标的资源日志的详细信息。

将资源日志发送到 Log Analytics 工作区以获取以下功能：

使用日志查询将资源日志与其他日志数据相关联。
从资源日志条目创建日志警报。
使用 Power BI 访问资源日志数据。

收集模式

资源日志使用的 Log Analytics 工作区中的表取决于资源类型和资源使用的集合的类型。资源日志有两种类型的收集模式：

Azure 诊断：所有数据将写入到 AzureDiagnostics 表中。
特定于资源：每个类别的资源的数据将写入到单独的表中。

特定于资源

对于使用“特定于资源”模式的日志，将会根据在诊断设置中选择的每个日志类别，在所选工作区中创建各个表。与 Azure 诊断日志相比，特定于资源的日志具有以下优势：

更方便地处理日志查询中的数据。
提高对架构及其结构的发现能力。
改善引入延迟和查询时间方面的性能。
可以授予针对特定表的 Azure 基于角色的访问控制权限。

有关特定于资源的日志和表的说明，请参阅 Azure Monitor 支持的资源日志类别

Azure 诊断模式

在 Azure 诊断模式下，来自任何诊断设置的所有数据都将收集到 AzureDiagnostics 表中。当今大多数 Azure 服务都使用此传统方法。由于多个资源类型会将数据发送到同一个表，因此其架构是所收集的所有不同数据类型的架构的超集。如需详细了解此表的结构以及如何处理如此大量的列，请参阅 AzureDiagnostics 参考。

AzureDiagnostics 表包含生成日志的资源的 resourceId、日志类别、生成日志的时间以及特定于资源的属性。

选择收集模式

大多数 Azure 资源在 Azure 诊断模式或资源特定模式下将数据写入工作区，不给您选择的机会。有关详细信息，请参阅 Azure 资源日志的通用架构和特定于服务的架构。

所有 Azure 服务最终都将使用特定于资源的模式。在进行这种过渡期间，某些资源允许在诊断设置中选择模式。为任何新的诊断设置指定特定于资源的模式，因为此模式可以简化数据管理。它还有助于在今后避免复杂的迁移。

注释

有关使用 Azure 资源管理器模板设置收集模式的示例，请参阅 Azure Monitor 中的诊断设置的资源管理器模板示例。

可将现有的诊断设置修改为特定于资源的模式。在这种情况下，已收集的数据将保留在 AzureDiagnostics 表中，直到根据工作区的保留设置删除了这些数据。新数据将收集到专用表中。可以使用 union 运算符跨两个表查询数据。

请继续查看Azure Updates博客，以了解支持特定于资源模式的 Azure 服务的公告。

将资源日志发送到事件中心，以将其发送到 Azure 之外。例如，可将资源日志发送到第三方 SIEM 或其他日志分析解决方案。

来自事件中心的资源日志以 JSON 格式使用，其中的 records 元素包含每个有效负载中的记录。架构取决于资源类型，如 Azure 资源日志的通用架构和特定于服务的架构中所述。

以下示例输出数据来自资源日志的 Azure 事件中心：

{
    "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 存储，以将其存档保留。创建诊断设置以后，一旦在已启用的日志类别之一中出现事件，就会在存储帐户中创建存储容器。

注释

存档的另一种替代方式是将资源日志发送到 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 都包含一个 JSON 对象，其中包含在 Blob URL 中指定的小时内收到的日志文件中的事件。在当前小时内，收到的事件将被追加到 PT1H.json 文件中，无论它们是在何时生成的。 URL m=00 中的分钟参数始终为 00，因为 Blob 是每小时创建一次的。

在 PT1H.json 文件中，每个事件按以下格式存储。它使用通用顶级架构，但该架构对于每个 Azure 服务是唯一的，如资源日志架构中所述。

注释

日志将根据收到日志的时间写入 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 资源日志的通用架构和服务特定的架构。有关每个服务支持的不同类别以及指向每个类别架构的链接，请参阅 Azure Monitor 支持的资源日志类别。