在 Azure Monitor 中监视 DCR 数据收集

项目
2025-04-18

本文提供了详细的指标和日志，可用于监视并排查 Azure Monitor 中与数据收集相关的性能及其他问题。此遥测目前可用于数据收集规则 (DCR) 定义的数据收集方案，例如 Azure Monitor 代理和日志引入 API。

重要

本文仅涉及使用 DCR 的数据收集方案，包括以下方案：

使用 Azure Monitor 代理 (AMA) 收集的日志
使用日志引入 API 引入的日志
使用工作区转换 DCR 的其他方法收集的日志

请参阅其他方案的文档，了解任何其他监视和故障排除信息。

DCR 诊断功能包括日志处理期间发出的指标和错误日志。 DCR 指标提供有关要引入的数据量、任何处理错误的数量和性质以及与数据转换相关的统计数据的信息。 DCR 错误日志在数据处理不成功及数据未到达其目标时生成。

DCR 错误日志

如果数据到达 Azure Monitor 引入管道但未能到达其目标时会生成错误日志。错误情况的示例包括：

日志传递错误
转换错误，其中日志的结构使转换 KQL 无效
日志引入 API 调用：
- 具有除 200/202 以外的任何 HTTP 响应
- 具有包含格式不正确的数据的有效负载
- 具有超过任何引入限制的有效负载
- 由于 API 调用限制超额而导致的限制

为避免过多记录同一数据流的持续性错误，系统将在每小时内针对这一类型的错误进行有限次数的记录，并在后续以错误消息摘要形式呈现。这样，系统会暂时屏蔽这类错误，直到一小时结束为止。给定错误的记录次数可能因 DCR 的部署区域而异。

不会记录某些日志引入错误，因为无法将其与 DCR 关联。可能不会记录以下错误：

格式不正确的调用 URI 导致的失败（HTTP 响应代码 404）
某些内部服务器错误（HTTP 响应代码 500）

启用 DCR 错误日志

DCR 错误日志以 Azure Monitor 中资源日志的形式实现。通过为 DCR 创建诊断设置来启用日志收集。每个 DCR 需有自己的诊断设置。有关详细过程，请参阅在 Azure Monitor 中创建诊断设置。选择“日志错误”类别和“发送到 Log Analytics 工作区”。可能需要选择 DCR 所用的同一工作区，也可能需要在单个工作区中合并所有错误日志。

检索 DCR 错误日志

错误日志将被写入诊断设置中指定的 Log Analytics 工作区中的 DCRLogErrors 表。下面是可在 log Analytics 中用于检索这些日志的示例查询。

检索特定 DCR 的所有错误日志

DCRLogErrors
| where _ResourceId == "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"

检索特定 DCR 中特定输入流的所有错误日志

DCRLogErrors
| where _ResourceId == "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"
| where InputStreamId == "Custom-MyTable_CL"

DCR 指标

将为所有 DCR 自动收集 DCR 指标，您可以像分析其他 Azure 资源的平台指标一样，使用指标浏览器分析这些指标。 输入流以维度形式包含，如果有含多个输入流的 DCR，可通过筛选或拆分来分析每个输入流。某些指标包括其他维度，如下表所示。

指标	维度	说明
每分钟日志引入字节数	输入流	每分钟接收的总字节数。
每分钟的日志引入请求数	输入流 HTTP 响应代码	每分钟接收到的呼叫数
每分钟删除的日志行数	输入流	处理期间每分钟删除的日志行数。这包括因 KQL 转换中的筛选条件删除的行以及因错误删除的行。
每分钟接收的日志行数	输入流	每分钟接收待处理的日志行数。
每分钟的日志转换持续时间	输入流	每分钟的平均 KQL 转换运行时。表示 KQL 转换代码效率。转换运行时间较长的数据流可能会经历数据处理延迟和更大的数据延时。
每分钟的日志转换错误数	输入流错误类型	每分钟遇到的处理错误数

监视日志引入

以下信号可用于监视您通过 DCR 进行日志收集时的运行状况。创建警报规则来标识这些情况。

信号	可能的原因和措施
`DCRErrorLogs` 中的新条目或 `Log Transform Errors` 的突然改变。	- 日志引入 API 配置的问题，例如身份验证、对 DCR 或 DCE 的访问、调用负载问题。 - 数据结构更改导致 KQL 转换失败。 - 数据目标配置更改导致数据传递失败。
`Logs Ingestion Bytes per Min` 突然变化	- 客户端上日志引入的配置更改，包括 AMA 设置。 - 发送的日志的结构更改。
`Logs Ingestion Bytes per Min` 与 `Logs Rows Received per Min` 之间比率的突然变化	- 发送的日志的结构更改。检查更改，以确保数据在 KQL 转换时得到正确处理。
`Logs Transformation Duration per Min` 突然变化	- 日志结构更改，影响了 KQL 转换中设置的日志筛选条件的效率。检查相关更改，确保已使用 KQL 转换正确处理数据。
`Logs Ingestion Requests per Min` 或 `Logs Ingestion Bytes per Min` 接近日志引入 API 服务限制。	- 检查和优化 DCR 配置以避免受限制。

警报

创建警报规则，在产生潜在错误条件时主动接收问题通知，而不是被动排查问题。下表提供了可创建的用于监视日志引入的警报规则的示例。

条件	警报详细信息
删除行的突然变化	对 `Logs Rows Dropped per Min` 使用动态阈值的指标警报规则。
接近服务限制的 API 调用数	对 `Logs Ingestion Requests per Min` 使用静态阈值的指标警报规则。将阈值设置为接近 12,000，即每个 DCR 每分钟最大请求数服务限制。
错误日志	使用 `DCRLogErrors` 记录查询警报。使用“表行”度量值，并将“阈值”设为“1”，就能在记录任何错误时触发警报。

通过