在 Azure Monitor 中监视和排查 DCR 数据收集问题

Artículo
08/28/2024

本文提供了详细的指标和日志，可用于监视并排查 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/00000000-0000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"

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

DCRLogErrors
| where _ResourceId == "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"
| where InputStreamId == "Custom-MyTable_CL"

DCR 指标

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

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

常见问题疑难解答

如果 Log Analytics 工作区中缺少预期数据，请按以下基本步骤排查问题。前提是已按如上所述启用 DCR 日志记录。

检查 Logs Ingestion Bytes per Min 和 Logs Rows Received per Min 等指标，以确保数据到达 Azure Monitor。如果未到达，检查数据源以确保其按预期发送数据。
检查 Logs Rows Dropped per Min 以确定是否删除了任何行。这有可能不会显示错误，因为转换确实可能会删除这些行。但如果删除的行与 Logs Rows Dropped per Min 相同，则不会在工作区中引入任何数据。检查 Logs Transformation Errors per Min 以确认是否有任何转换错误。
检查 Logs Transformation Errors per Min 以确定应用于传入数据的转换是否有任何错误。这可能因数据结构或转换本身发生更改所致。
检查 DCRLogErrors 是否有任何记录的引入错误。这可以在确定问题的根本原因时提供更多详细信息。

监视日志引入

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

Signal	可能的原因和操作
`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，在记录任何错误时发出警报。

Compartir a través de