Sloth项目中SLO仪表板NaN问题的分析与解决方案

问题背景

在使用Sloth项目的SLO规范与仪表板时，开发人员遇到了一个常见但棘手的问题：在Grafana仪表板中出现了NaN（非数字）值的显示。这种情况特别容易发生在系统刚部署或流量较低的时段，尤其是在使用5分钟SLI窗口的情况下。

问题本质分析

NaN值的出现源于PromQL查询的特殊性。当监控系统没有收到任何流量时，某些查询会返回NaN结果。具体到Sloth项目，当错误查询（error_query）和总查询（total_query）的比值为0/0时，Prometheus会返回NaN。这种情况在短时间窗口（如5分钟）内尤为常见。

技术解决方案

经过社区讨论和技术验证，目前有以下几种解决方案：

1. 基础查询修正法： 在总查询（total_query）中添加保护条件，确保分母永远不会为零。例如：

   (sum(rate(nginx_requests{path="/auth",service="myservice"}[{{.window}}])) >0) or on() vector(1)
   

2. 仪表板查询修正法： 直接修改仪表板中的查询表达式，添加类似的保护条件：

   slo:period_error_budget_remaining:ratio{sloth_service="${service}", sloth_slo="${slo}"} >0 or on() vector(1)
   

技术细节解析

1. on()操作符的作用： on()操作符在PromQL中用于指定标签匹配条件。在表达式(up{instance="x"} > 0) or on() vector(1)中，on()确保只产生一个时间序列，而不是多个。这对于SLO计算至关重要，因为它保证了结果的唯一性。

2. vector(1)的含义： vector(1)创建一个值为1的瞬时向量，当主查询条件不满足时作为默认值返回。这确保了即使在没有流量的情况下，查询也不会返回NaN。

3. 负值问题： 在某些情况下，修正后可能出现负百分比值（如-448%）。这通常表示错误预算已经被严重透支，系统性能远低于SLO目标。这种情况需要引起重视，可能表明系统存在严重问题。

最佳实践建议

1. 对于新部署的系统，建议在Sloth规范中预先添加保护条件，而不是等问题出现后再修正。

2. 对于短时间窗口（如5分钟）的SLO监控，更需要注意NaN问题的预防，因为短窗口更容易出现零流量的情况。

3. 当修改查询条件后，可能需要等待一个完整的窗口周期（如30天）才能完全消除历史NaN值的影响。在此期间，可以考虑临时重命名或重新标记SLO以获取准确数据。

4. 定期检查SLO仪表板，特别关注负百分比值，这可能是系统性能问题的早期预警信号。

通过理解这些技术细节和解决方案，开发人员可以更有效地使用Sloth项目进行SLO监控，避免NaN值带来的困扰，获得更准确可靠的系统性能指标。