Azure数据收集规则TimeGenerated转换失效问题求助

问题场景 #

通过Azure Monitor Log Ingestion API向自定义表写入数据，配置了数据收集规则（DCR），用以下KQL转换将自定义timestamp字段转为TimeGenerated：

"transformKql": "source\n| extend TimeGenerated = todatetime(substring(timestamp, 0, 23))\n| project-away timestamp\n"

其中timestamp格式为2024-02-07 23:10:05.000 CET，DCR查询构建器用示例数据测试转换正常，但实际摄入日志后，TimeGenerated (UTC)显示的是日志摄入时间（接近_TimeReceived），而非自定义timestamp的时间。

可能原因 #

1. 字段名称不匹配：KQL对字段名大小写敏感，如果提交的日志数据中字段是Timestamp或其他拼写形式，和转换中引用的timestamp不一致，会导致TimeGenerated生成null值，Azure Monitor会自动用摄入时间填充该字段。
2. 时区解析错误：直接截取前23位去掉CET时区标识后，todatetime()转换出的是无时区的datetime值，Azure Monitor无法识别其原始时区，可能导致解析异常生成null，进而触发默认的摄入时间填充；或者未正确处理CET/CEST的时区偏移（CET为UTC+1，CEST为UTC+2），导致转换后的时间不符合预期。
3. DCR配置未生效：Log Ingestion API请求中指定的DCR资源ID错误，或者DCR的转换规则未正确保存发布，导致转换逻辑未执行。
4. 转换逻辑被覆盖：DCR中存在后续转换步骤（如其他extend/project语句），覆盖了已生成的TimeGenerated字段。

解决办法 #

1. 校验字段一致性 #

检查提交的日志数据中，自定义时间字段的名称、拼写、大小写是否与转换中的timestamp完全一致，确保字段存在且格式符合预期。

2. 修正时区转换逻辑 #

修改KQL转换，正确解析带时区的timestamp字符串，避免丢失时区信息：

• 方法一：替换时区标识为UTC偏移量

  source
  | extend TimeGenerated = todatetime(replace_string(replace_string(timestamp, 'CEST', '+02:00'), 'CET', '+01:00'))
  | project-away timestamp
  

• 方法二：用parse函数解析并计算时区偏移

  source
  | parse timestamp with dt:datetime ' ' tz:string
  | extend TimeGenerated = dt + case(tz == 'CET', 1h, tz == 'CEST', 2h, 0h)
  | project-away timestamp, dt, tz
  

  转换后的TimeGenerated会包含正确的时区偏移，Azure Monitor将自动转换为UTC存储，TimeGenerated (UTC)会显示原始时间对应的UTC值。

3. 验证DCR配置有效性 #

• 确认Log Ingestion API请求中使用的DCR资源ID正确；
• 重新发布DCR，确保转换规则已更新生效；
• 可以在转换中添加一个临时字段（如OriginalTimestamp）验证转换是否执行：

  source
  | extend OriginalTimestamp = timestamp, TimeGenerated = todatetime(replace_string(timestamp, 'CET', '+01:00'))
  | project-away timestamp
  

  摄入后查看是否存在OriginalTimestamp字段，以此判断转换逻辑是否被执行。

4. 检查转换步骤顺序 #

查看DCR的完整转换规则，确保没有后续步骤修改或覆盖TimeGenerated字段。

内容的提问来源于stack exchange，提问作者Dino