Prometheus中NaN是合法浮点数但会污染计算链，应从源头规避：避免rate(a)/rate(b)除零，改用先sum再除；利用NaN!=NaN过滤；用>0或or vector(0)兜底；禁用isnan()（原生不支持）。
直接在PromQL中过滤或规避NaN，而不是等它进入聚合再报错。Prometheus本身不把NaN当缺失值处理，而是当作一个合法浮点数——但它会“污染”整个计算链：只要参与运算的任意一端是NaN，结果就是NaN；而多数聚合函数（如avg、sum）对NaN无鲁棒性，尤其在分组场景下容易让整条曲线变空或告警失灵。
避免除零产生NaN源头
最常见来源是用rate(a)/rate(b)这类写法，当某时间窗口内b为0或无数据，rate(b)返回0，导致除零→NaN。正确做法是先分别聚合分子分母，再做除法：
- ❌ 错误：
avg by (job)(rate(http_requests_total[5m]) / rate(http_errors_total[5m])) - ✅ 正确：
sum by (job)(rate(http_requests_total[5m])) / sum by (job)(rate(http_errors_total[5m]))
这样即使某job在某个窗口无错误，分母为0，Prometheus会跳过该时间点（而非返回NaN），整体结果仍可计算。
用bool逻辑提前拦截NaN
PromQL支持NaN != NaN这一特性（因为标准浮点语义中NaN不等于任何值，包括自身）。可利用这点做显式过滤：
-
rate(http_errors_total[5m]) == bool rate(http_errors_total[5m])→ 只保留非NaN值 - 组合使用：
(rate(http_errors_total[5m]) > 0) or (rate(http_errors_total[5m]) == bool rate(http_errors_total[5m]))，兼顾正数与有效NaN判断（实际更推荐前者，因NaN本身无法比较大小）
也可封装为子查询或记录规则预处理，比如定义http_error_rate_clean = rate(http_errors_total[5m]) > 0，后续只基于该指标计算。
在仪表盘或告警中加兜底保护
前端展示或告警表达式里，别让NaN穿透到最终结果。常用技巧：
- 用
or vector(0)提供默认值：sum by (job)(rate(http_errors_total[5m])) or vector(0) - 用
count(...) > 0做存在性校验，避免空结果触发异常逻辑 - 开源Dashboard（如Grafana）常加
> 0条件，本质就是剔除NaN和负值干扰，例如：sum(irate(memcached_commands_total{job="cache"}[5m])) by (command) > 0
注意：不要依赖isnan()函数——PromQL原生不提供该函数，这是常见误区。
检查数据采集端是否异常注入NaN
某些Exporter（尤其是自研或老版本）可能误将空值、超时、初始化未就绪状态硬编码为NaN写入Prometheus。此时需回溯源头：
- 查
up{job="xxx"} == 0确认目标是否失联 - 用
count_values("value", your_metric)观察值分布，看是否有大量"NaN"字符串（说明是文本误写） - 检查Exporter日志，确认是否在无数据时返回
NaN而非跳过该指标
修复方式通常是升级Exporter、调整采集逻辑，或在中间加一层Telegraf/Vector做清洗。
