发送 Azure 资源日志数据

项目
09/24/2024

Azure 资源日志是平台日志，可以通过它深入了解已在 Azure 资源中执行的操作。资源日志的内容因 Azure 服务和资源类型而异。默认不会收集资源日志。本文介绍每个 Azure 资源将其资源日志发送到不同目标所需的诊断设置。

发送到 Log Analytics 工作区

将资源日志发送到 Log Analytics 工作区以启用 Azure Monitor 日志的功能，在其中可以：

将资源日志数据与 Azure Monitor 收集的其他监视数据关联。
将来自多个 Azure 资源、订阅和租户的日志项合并到一个位置一起进行分析。
使用日志查询执行复杂分析，并深入了解日志数据。
使用带有复杂警报逻辑的日志搜索警报。

创建诊断设置，以便将资源日志发送到 Log Analytics 工作区。如 Azure Monitor 日志的结构中所述，此数据将存储在表中。资源日志使用的表取决于资源使用的收集类型：

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

特定于资源

在此模式下，将会根据在诊断设置中选择的每个类别，在所选工作区中创建各个表。建议使用此方法的原因是：

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

所有 Azure 服务最终都会迁移到特定于资源的模式。

以下示例将会创建三个表：

表 Service1AuditLogs

资源提供程序 Category A B C

服务 1 AuditLogs x1 y1 z1

服务 1 AuditLogs x5 y5 z5

...
表 Service1ErrorLogs

资源提供程序 Category D E F

服务 1 ErrorLogs q1 w1 e1

服务 1 ErrorLogs q2 w2 e2

...
表 Service2AuditLogs

资源提供程序 Category G H I

服务 2 AuditLogs j1 k1 l1

服务 2 AuditLogs j3 k3 l3

...

资源提供程序	Category	A	B	C
服务 1	AuditLogs	x1	y1	z1
服务 1	AuditLogs	x5	y5	z5
...

资源提供程序	Category	D	E	F
服务 1	ErrorLogs	q1	w1	e1
服务 1	ErrorLogs	q2	w2	e2
...

资源提供程序	Category	G	H	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	Category	A	B	C	D	E	F	G	H	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 服务最终都将使用特定于资源的模式。在进行这种过渡期间，某些资源允许在诊断设置中选择模式。为任何新的诊断设置指定特定于资源的模式，因为此模式可以简化数据管理。它还有助于在今后避免复杂的迁移。

注意

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

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

有关支持特定于资源模式的 Azure 服务的公告，请继续阅读 Azure 更新博客。

发送到 Azure 事件中心

将资源日志发送到事件中心，以将其发送到 Azure 之外。例如，可将资源日志发送到第三方 SIEM 或其他日志分析解决方案。来自事件中心的资源日志以 JSON 格式使用，其中的 records 元素包含每个有效负载中的记录。架构取决于资源类型，如 Azure 资源日志的通用架构和特定于服务的架构中所述。

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

{
    "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": "chinanorth",
                    "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": "chinanorth",
                    "actionName": "Send_email"
                },
                "correlation": {
                    "actionTrackingId": "042fb72c-7bd4-439e-89eb-3cf4409d429e",
                    "clientTrackingId": "08587330012106702632"
                }
            }
        }
    ]
}

发送到 Azure 存储

将资源日志发送到 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/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 都包含一个 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": "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}}

通过