你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
将 Azure 资源日志发送到 Log Analytics 工作区、事件中心或 Azure 存储
Azure 资源日志是平台日志，可以通过它深入了解在 Azure 资源中执行的操作。 对于每种资源类型，资源日志的内容不同。 默认不会收集资源日志。 若要收集资源日志，必须启用并配置诊断设置或使用数据收集规则。 有关数据收集规则的详细信息，请参阅 Azure Monitor 中的数据收集规则。 本文介绍了每个 Azure 资源将其资源日志发送到 Log Analytics 工作区、事件中心或 Azure 存储所需的诊断设置。
发送到 Log Analytics 工作区
将资源日志发送到 Log Analytics 工作区以启用 Azure Monitor 日志的功能，在其中可以：
- 将资源日志数据与 Azure Monitor 收集的其他监视数据关联。
- 将来自多个 Azure 资源、订阅和租户的日志项合并到一个位置一起进行分析。
- 使用日志查询执行复杂分析，并深入了解日志数据。
- 使用带有复杂警报逻辑的日志搜索警报。
创建诊断设置，以便将资源日志发送到 Log Analytics 工作区。 如 Azure Monitor 日志的结构中所述，此数据将存储在表中。 资源日志使用的表取决于资源类型和资源使用的收集类型。 资源日志有两种类型的收集模式：
- Azure 诊断：所有数据将写入到 AzureDiagnostics 表中。
- 特定于资源：每个类别的资源的数据将写入到单独的表中。
特定于资源
对于使用“特定于资源”模式的日志，将会根据在诊断设置中选择的每个日志类别，在所选工作区中创建各个表。 与 Azure 诊断日志相比，特定于资源的日志具有以下优势：
- 更方便地处理日志查询中的数据。
- 更好地发现架构及其结构。
- 改善引入延迟和查询时间方面的性能。
- 可以授予针对特定表的 Azure 基于角色的访问控制权限。
有关特定于资源的日志和表的说明，请参阅 Azure Monitor 支持的资源日志类别
Azure 诊断模式
在 Azure 诊断模式下，来自任何诊断设置的所有数据都将收集到 AzureDiagnostics 表中。 当今大多数 Azure 服务都使用此传统方法。 由于多个资源类型会将数据发送到同一个表，因此其架构是所收集的所有不同数据类型的架构的超集。 如需详细了解此表的结构以及此表如何适用于如此大量的列，请参阅 AzureDiagnostics 参考。
AzureDiagnostics 表包含生成日志的资源的 resourceId、日志类别、生成日志的时间以及特定于资源的属性。
选择收集模式
大多数 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/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 存储
将资源日志发送到 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 中的合作伙伴解决方案。 有关这些解决方案的列表及其配置方式的详细信息，请参阅 Azure Monitor 合作伙伴集成。