如何解决Prometheus数据库中丢失的数据？

13

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

在此期间，我注意到我经常遇到一个奇特的问题：有时候，一个应该被Prometheus提取数据的出口商变得毫无反应。可能是由于网络配置错误-它不再可访问-或仅仅是因为出口商崩溃了。

无论是什么原因，我都会发现我希望在Prometheus中看到的某些数据丢失了，并且在一定时间内该系列中没有任何数据。有时，一个出口商失败（计时？）也似乎导致其他出口商失败（第一次超时将整个作业推到了顶级超时之上？只是推测）。

我看到的只是该系列中的空白，如上面的可视化效果所示。发生这种情况时，日志中没有任何内容。普罗米修斯的自我指标似乎也很贫乏。我只是不得不手动尝试复制Prometheus所做的事情并查看它在哪里中断。真讨厌一定会有更好的办法！尽管我不需要实时警报，但我至少希望能够看到导出器无法传递数据。即使是布尔值“嘿检查您的数据”标志也将是一个开始。

我如何获得有关普罗米修斯未能从出口商获得数据的有意义的信息？我如何理解为什么无需执行Prometheus数据收集的手动模拟而存在差距？在这方面有哪些明智的做法，甚至扩展到普罗米修斯（Prometheus）以外的总体监测数据收集方面？

monitoring prometheus

— 桑德
source

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

— kenorb

没什么，我只是看到数据系列中的空白。Prometheus输出仅具有正常的常规行，每隔几分钟便会保存未完成的更改，除非如此（除非我想念一些隐藏的日志）。

— 桑德

我们也面临这个问题。@Sander您能找到原因吗？

— Deepak N

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

— 桑德

5

我认为您可以对指标执行某种警报，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分钟发出警报，并带有正确的度量标准名称和标签，以告诉该出口商来自哪个出口商，它应该为您提供正确的信息。

选择正确的指标来由出口商监控可能很复杂，没有更多的见识很难凭空提出更好的建议。
这篇博客文章也可能会启发人们进行更通用的检测。

— Tensibai
source

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

— Johannes'fish'Ziemke

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

— Tensibai

@ Johannes'fish'Ziemke欢迎来到devops.se顺便说一句：）

— Tensibai，

1

有一些原因可能造成了差距。在这种情况下，很可能无法导出导出器，在这种情况下，up时间序列将为0。您可以对此发出警报（取自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

— 约翰内斯·“鱼”·齐姆克
source

1

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

— wa
source