我们的设置包括：
- 一些 Debian 9.12 节点，其中安装了 Prometheus node_exporter v. 0.18.1 作为服务
- Prometheus 服务器 v. 2.14.0（在 Windows Server 2016 上）从节点抓取指标
- Grafana 可视化指标
基本上，我们的负载可能是不稳定的，因此我们希望捕获详细信息，因此目前我们每 10 秒抓取一次指标，并在 Grafana 中显示 1 分钟的费率，查询如下：
rate(node_network_receive_bytes_total{instance=~'$node',device!~'tap.*|veth.*|br.*|docker.*|virbr*|lo*'}[1m])*8
在 Grafana 中，我们看到了巨大的峰值，对于平均吞吐量低于 100Mbit/s 的网络实例，峰值超过每秒数百 Gigabits，这显然在技术上是不可能的。CPU 负载、CPU 等待时间、磁盘 iops 和其他node_exporter指标也是如此，一般看起来是这样的，看看平均值和最大值之间的巨大差异：
显然，这种情况发生是因为 Prometheus 似乎“遗漏”了单个数据点，并且根据其rate工作原理，它会将“最后一个”点与零进行比较，并node_network_receive_bytes_total与自上次启动以来累积的当前值进行比较，从而使输出猛增。如果我们尝试切换到irate峰值，则跳得更高，这似乎证明了我们的猜测。
查询我们的 Prometheus 收集服务器以获取rate出现峰值的特定时间范围内的数据点，我们没有看到任何零点，“峰值”时间范围内的数据看起来连续增加：
node_network_receive_bytes_total{device="ens8",instance="cassandra-xxxxxxxxx0:9100",job="cassandra-xxxxxxxxx"}
3173659836137 @1585311247.489
3173678570634 @1585311257.49
3173696782823 @1585311267.491
3173715943503 @1585311277.492
3173715937480 @1585311277.493
3173731328095 @1585311287.495
3173743034248 @1585311297.502
3173756482486 @1585311307.497
3173775999916 @1585311317.497
3173796096167 @1585311327.498
3173814354877 @1585311337.499
3173833456218 @1585311347.499
3173852345655 @1585311357.501
图上相同：
rate查询rate(node_network_receive_bytes_total{instance="cassandra-xxxxxxxxx0:9100",device!~'tap.*|veth.*|br.*|docker.*|virbr*|lo*'}[1m])*8在同一时间范围内显示了令人惊讶的不同的图片：
虽然 Prometheus 文档指出它应该推断缺失的数据点，但某些问题rate仍然irate存在广受认可，目前我们对上述内容感到很困惑。
我们最大的问题是峰值使得可视化以及更重要的是设置限制/警报变得不可能。
目前我们唯一可以确定的是 Grafana 没有问题，问题出在我们的 Prometheus 上，问题是——你是否遇到过类似的事情？如果是，你会如何处理？
如果没有，也许您可以建议一些进一步的诊断方法？
无论如何，至少感谢大家读到这里。
答案1
3173715943503 @1585311277.492
3173715937480 @1585311277.493
这些值正在倒退，这被视为计数器重置。这通常表示内核错误，但考虑到这些值仅相差一毫秒，我猜发生的事情是，您没有提到关键细节，即这实际上是来自两个不同 Prometheus 服务器的合并数据 - 这与您所发现的并不相符。