我一直在逐渐将Prometheus集成到我的监视工作流程中,以便收集有关运行基础结构的详细指标。

在此期间,我注意到我经常遇到一个特殊的问题:有时Prometheus的出口商是应该从中提取数据变得无响应。也许是由于网络配置错误-它不再可访问-或仅仅是因为出口商崩溃了。而且该系列在特定时间内没有任何内容。有时,一个出口商失败(计时?)也似乎导致其他出口商失败(第一次超时将整个作业推到了顶级超时之上?只是推测)。



我看到的只是该系列中的空白,如上面的可视化效果所示。发生这种情况时,日志中没有任何内容。普罗米修斯的自我指标似乎也很贫乏。我只是不得不手动尝试复制Prometheus所做的事情并查看它在哪里中断。真讨厌肯定有更好的办法!尽管我不需要实时警报,但我至少希望能够看到导出器无法传递数据。甚至是布尔值“嘿检查您的数据”标志都将是一个开始。我如何理解为什么无需执行Prometheus数据收集的手动模拟而存在差距?在这方面有哪些明智的做法,甚至扩展到普罗米修斯(Prometheus)以外的一般监视数据收集的地方?

评论

您是否有与此问题相关的日志条目或警告/错误?

没什么,我只是看到数据系列中的空白。 Prometheus输出仅具有正常的常规代码行,每隔几分钟便会保存待处理的更改,除非如此(除非我错过了一些隐藏的日志来查看)。
我们也面临这个问题。 @Sander找到原因了吗?

@DeepakN不,很遗憾,我没有有用的见解可在此处添加。使用Prometheus时,它仍然是一个痛点。

#1 楼

我认为您可以对rate指标执行某种警报,如下所示:

ALERT DropInMetricsFromExporter
  IF rate(<metric_name>[1m]) == 0
  FOR 3m
  ANNOTATIONS {
    summary = "Rate of metrics is 0 {{ $labels.<your_label> }}",
    description = "Rate of metric dropped, actually: {{ $value }}%",
}


主要思想是,每当指标速率为0表示3时发出警报分钟,并带有正确的度量标准名称和标签,以告诉它来自哪个出口商,它应该为您提供正确的信息。

选择合适的度量标准来监控出口商可能很复杂,没有更多的见识很难凭空提出更好的建议。检测。

评论


rate计算给定计数器的每秒速率。这与刮擦指标的速率无关(-> scrape_interval)。您的示例将警告给定的计数器(metric_name)在3分钟内没有增加,这可能不是OP想要的。

–约翰内斯(Johnhannes)的鱼Ziemke
17年8月31日在9:49

@ Johannes'fish'Ziemke为什么我说找到正确的度量标准可能很复杂。例如,可以在节点导出器上使用时间度量。如果您有更好的方式提醒出口商失败,请随时添加答案

–滕西拜
17年8月31日上午10:10

@ johannes'fish'Ziemke欢迎来到devops.se btw :)

–滕西拜
17年8月31日在10:13

#2 楼

有一些原因可能造成了差距。在这种情况下,up时间序列很有可能是出口商无法到达的。您可以对此发出警报(取自https://prometheus.io/docs/alerting/rules/#templating):
# Alert for any instance that is unreachable for >5 minutes.
ALERT InstanceDown
  IF up == 0
  FOR 5m
  LABELS { severity = "page" }
  ANNOTATIONS {
    summary = "Instance {{ $labels.instance }} down",
    description = "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.",
  }


在状态页面上,您还应该看到它已关闭,其中包含一条错误消息。不幸的是,没有办法看到过去的错误,但是有一个问题可以跟踪:https://github.com/prometheus/prometheus/issues/2820

您的Prometheus服务器也可能过载,从而导致抓取停止,这也可以解释差距。在这种情况下,您应该在日志中看到Storage needs throttling. Scrapes and rule evaluations will be skipped.错误,并且prometheus_target_skipped_scrapes_total指标有所增加。您也应该注意这一点,例如:

ALERT PrometheusSkipsScrapes
  IF rate(prometheus_target_skipped_scrapes_total[2m]) > 0
  FOR 5m


#3 楼

我不确定这是否与您看到的问题相同。但是,对于没有专门设置GC设置的Java应用程序,我们看到了这些随机差距。这意味着在数据收集停止时我们看到了差距,因为在JVM执行Full GC时实例的活动停止了。如果您使用Java,则可能会发生这种情况。我们的解决方法是显式使用G1垃圾收集器(Java 8+),并且对GC活动的时间有指定的限制,以防止数据收集中出现这些时间间隔。