Ars*_* V. 5 grafana prometheus
我们的设置包括:
基本上,我们的负载可能会不稳定,因此我们希望捕获详细信息,因此目前我们每 10 秒抓取一次指标,并在 Grafana 中显示 1 分钟的速率,查询如下:
rate(node_network_receive_bytes_total{instance=~'$node',device!~'tap.*|veth.*|br.*|docker.*|virbr*|lo*'}[1m])*8
Run Code Online (Sandbox Code Playgroud)
在 Grafana 中,我们看到巨大的峰值,对于平均吞吐量低于 100Mbit/s 的网络实例,峰值超过每秒数百吉比特,这显然在技术上是不可能的。CPU 负载、CPU 等待时间、磁盘 iops 和其他node_exporter
指标也会发生同样的情况,通常看起来像这样,看看平均值和最大值之间的巨大差异:
显然,发生这种情况是因为普罗米修斯似乎“错过”了单点数据,并且根据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
Run Code Online (Sandbox Code Playgroud)
同样在图上:
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 内部,问题是 - 您是否遇到过类似的情况?如果是,你如何处理?
如果没有,也许您可以建议一些进一步的诊断方法?
无论如何,至少感谢大家阅读到这里。
3173715943503 @1585311277.492
3173715937480 @1585311277.493
Run Code Online (Sandbox Code Playgroud)
这些值正在向后移动,这被视为计数器重置。这通常表明存在内核错误,但是考虑到这些值仅相隔一毫秒,我猜测发生的情况是您没有提及关键细节,即这实际上是来自两个不同 Prometheus 的合并数据服务器 - 这不会像你发现的那样工作。
归档时间: |
|
查看次数: |
1254 次 |
最近记录: |