我已经使用 prometheus、AWS EC2 自动发现和节点导出器建立了一个监控系统。使用以下公式获取 CPU 利用率：
100 - (avg by (instance) (irate(node_cpu_seconds_total{instance="instancexyz" ,mode="idle"}[5m])) * 100)
但是，在一个特定的 ASG 中，我得到的 CPU 百分比是较大的负值。我打开了 instance:9100/metrics 链接，发现空闲值是大指数值。这是我得到的一个值：
node_cpu_seconds_total{cpu="0",mode="idle"} 4.25766215e+06
指标在我的所有实例上都运行良好，除了少数实例。知道发生了什么吗？
【问题讨论】：
标签： prometheus grafana prometheus-node-exporter
您看到的那些“大指数值”是累积的。 IE。自 VM 启动以来，CPU（或所有 CPU 内核？）已空闲 1000 多个小时（4.25e6 / 3600），因此它们看起来非常合理。
您获得负值的原因是采样。理论上，所有样本都恰好相隔 scrape_interval 秒到毫秒，并且每次抓取的网络延迟和导出器处理时间完全相同。实际上，刮擦可能会延迟甚至跳过，网络延迟会有所不同，并且您的目标 VM 可能会时不时地固定其 CPU（或因任何原因挂起）。
表示例如node_cpu_seconds_total 的一个样本完全有可能在（标称）时间T 具有值V，在（标称）时间V + 1 具有值T + 10s，导致空闲率为 110%。或者你想提出的任何价值观。 irate 加剧了这个问题，因为它总是查看两个连续的样本，从而增加了相对测量误差（相对于样本之间时间的误差）。
您对此无能为力，除非接受它不是一个完美的测量值并在其上打一个 clamp_min(<your_expression>, 0)。使用 rate 而不是 irate 也可能会减少错误，这通常是一个好主意，除非您以全分辨率查看数据。
【讨论】：
node_cpu_seconds_total 值可能会不时下降，irate() 将其解释为计数器重置（例如，当计数器从 1000 变为 999 时，它被解释为已归零并返回到 999，因此与从 1000 到 1999 相同）。每当您发现峰值/较大的负值时，请检查您的基础时间序列，看看是否涉及重置。无论如何，lamp_min() 将消除这些一次性尖峰。