Loki告警问题：告警通知中数据不一致

以下是针对告警数据时准不准问题的排查思路和优化建议：

1. 日志采集延迟导致统计偏差 #

你的日志链路是ALB > S3 > Python脚本 > Loki，脚本每分钟拉取S3日志，这里存在天然延迟：

• 部分日志可能还未写入S3，或脚本拉取/发送失败，导致Loki缺失部分时间段日志，使得告警查询的总请求数/错误数不准。
• 排查技巧：
  • 查看Python脚本运行日志，检查是否有S3下载超时、发送Loki失败的报错；
  • 对比S3中某一时间段的原始日志条数和Loki中count_over_time({job="logs"} | json [10m])的结果，确认是否有日志缺失；
  • 调整查询逻辑，给时间窗口添加偏移，确保大部分日志已入库：

    sum(count_over_time({job="logs"} | json | status_code != "" [10m] offset 1m))
    

2. 告警评估周期与查询窗口不匹配 #

如果告警评估间隔（比如每分钟评估一次）和10分钟查询窗口未对齐，会导致每次评估的统计窗口重叠，延迟入库的日志会让不同时间点的查询结果不一致：

• 排查技巧：
  • 检查告警规则的evaluation_interval设置，建议将评估间隔设为10分钟，与查询窗口一致，避免重叠统计；
  • 使用Loki的$__rate_interval变量替代固定10m窗口，该变量会根据评估间隔自动调整窗口大小，减少统计偏差：

    sum(count_over_time({job="logs"} | json | status_code != "" [$__rate_interval]))
    

3. 查询逻辑的潜在漏洞 #

你的查询存在几个可能导致统计不准的点：

• 总请求数统计不全：查询A中status_code != ""会排除status_code为空或JSON解析失败的日志，这部分实际是有效请求，会导致总请求数偏低、错误率偏高。
  • 优化后的查询A：

    sum(count_over_time({job="logs"} | json | __error__ = "" [10m]))
    

    用__error__ = ""确保只统计JSON解析成功的日志，避免遗漏有效请求。
• 错误率波动导致误判：查询F的($A > 0) * ($C > 2)在错误率接近2%时，可能因日志逐步入库导致F值在0和1之间反复变化，出现误告警或恢复异常。可调整触发条件，比如要求F大于0.5且持续2个评估周期，减少波动影响。

4. Loki集群的一致性问题 #

如果是分布式Loki集群，日志写入后需要时间同步到所有分片，此时查询会出现结果不一致的情况：

• 排查技巧：
  • 针对同一时间段的日志，多次执行查询A和B，对比结果是否一致；
  • 检查Loki Ingester组件状态，确认没有日志写入阻塞或分片异常；
  • 若Loki支持，可调整查询一致性级别（如设置为strong），确保查询到所有已写入的日志。

5. Python脚本的日志采集逻辑问题 #

ALB日志默认按小时生成并写入S3，若脚本每分钟拉取，可能会拉取未完全生成的日志文件，导致后续新增日志被遗漏：

• 排查技巧：
  • 检查脚本逻辑，是否只拉取已完成写入的日志文件（比如等待S3文件最后修改时间超过一定阈值再拉取）；
  • 添加脚本监控，统计每次拉取的日志条数，观察是否有异常波动，判断是否存在漏拉或重复拉取的情况。

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