I have been gradually integrating Prometheus into my monitoring workflows, in order to gather detailed metrics about running infrastructure.

During this, I have noticed that I often run into a peculiar issue: sometimes an exporter that Prometheus is supposed to pull data from becomes unresponsive. Maybe because of a network misconfiguration - it is no longer accessible - or just because the exporter crashed.

Whatever the reason it may be, I find that some of the data I expect to see in Prometheus is missing and there is nothing in the series for a certain time period. Sometimes, one exporter failing (timing out?) also seems to cause others to fail (first timeout pushed entire job above top-level timeout? just speculating).

Gap in data

All I see is a gap in the series, like shown in the above visualization. There is nothing in the log when this happens. Prometheus self-metrics also seem fairly barren. I have just had to resort to manually trying to replicate what Prometheus is doing and seeing where it breaks. This is irksome. There must be a better way! While I do not need realtime alerts, I at least want to be able to see that an exporter failed to deliver data. Even a boolean "hey check your data" flag would be a start.

How do I obtain meaningful information about Prometheus failing to obtain data from exporters? How do I understand why gaps exist without having to perform a manual simulation of Prometheus data gathering? What are the sensible practices in this regard, perhaps even when extended to monitoring data collections in general, beyond Prometheus?

  • Do you have any log entries or warnings/errors relevant to the problem? – kenorb Mar 1 '17 at 10:41
  • Nothing whatsoever, I just see a gap in the data series. The Prometheus output just has the normal regular lines about saving pending changes every few minutes and whatnot (unless I miss some hidden logs to look at). – Sander Mar 1 '17 at 11:17
  • We are also facing this issue. @Sander were you able to find the cause? – Deepak N Aug 28 '17 at 6:01
  • @DeepakN no, I have no useful insight to add here, unfortunately. It remains a pain point when using Prometheus. – Sander Aug 28 '17 at 6:04

I think your can do some kind of alerting on a metric rate with something like this:

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

The main idea is to alert whenever the metric rate is at 0 for 3 minutes, with the proper metric name and a label somewhere telling from which exporter it comes it should give you the correct information.

Choosing the right metric to monitor by exporter could be complex, without more insight is hard to give a better advice out of vacuum.
This blog post could be an inspiration also for a more generic detection.

  • rate calculates a rate per second for a given counter. This has nothing to do with the rate at which metrics are scraped (-> scrape_interval). Your example would alert if the given counter (metric_name) doesn't increase for 3 minutes which is probably not what the OP wants. – Johannes 'fish' Ziemke Aug 31 '17 at 9:49
  • @Johannes'fish'Ziemke That why I said finding the right metric could be complex. Using the time metric on a node exporter for example would do. If you have a better way to alert on an exporter failing, feel free to add an answer – Tensibai Aug 31 '17 at 10:10
  • @Johannes'fish'Ziemke Welcome on devops.se btw :) – Tensibai Aug 31 '17 at 10:13

There are a few reasons which might have caused the gap. Most likely the exporter isn't reachable in which case the up timeseries will be 0. You can alert on this like this (taken from 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" }
    summary = "Instance {{ $labels.instance }} down",
    description = "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.",

On the status page you should also see that it's down including an error message. Unfortunately there is no way to see past error but there is an issue to track this: https://github.com/prometheus/prometheus/issues/2820

Your Prometheus server can be also overloaded causing scraping to stop which too would explain the gaps. In that case you should see Storage needs throttling. Scrapes and rule evaluations will be skipped. errors in the log and increases in the prometheus_target_skipped_scrapes_total metrics. You should alert on that too, e.g:

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

I'm not sure if this is the same problem you are seeing. But we saw these random gaps for Java applications that did not specifically set the GC settings. Meaning we were seeing gaps when the data collection stopped because the activity for the instance stopped while the JVM was doing a Full GC. If you are using Java this can happen. Our fix was to explicitly use the G1 garbage collector (Java 8+) with a specified limit on the length of GC activity to prevent these time gaps in the data collection.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.