Increase issue

[slavede]

What did you do?
Tried to get increase over one minute.

What did you expect to see?
Increase values

What did you see instead? Under which circumstances?
I've got No datapoints found

Environment

• System information:

  Linux 2.6.32-358.el6.x86_64 x86_64

• Prometheus version:

prometheus, version 1.1.3 (branch: master, revision: ac374aa)
build user: root@3e392b8b8b44
build date: 20160916-11:36:30
go version: go1.6.3

• Alertmanager version:
• Prometheus configuration file:

# my global config
global:
  scrape_interval:     60s # By default, scrape targets every 60 seconds.
  evaluation_interval: 60s # By default, scrape targets every 60 seconds.
  # scrape_timeout is set to the global default (10s).

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
      monitor: 'codelab-monitor'

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first.rules"
  # - "second.rules"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # Override the global default and scrape targets from this job every 5 seconds.
    # scrape_interval: 5s

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
      - targets: ['localhost:9091']

• Alertmanager configuration file:

• Logs:

Should not I see jumps where value increased? Instead I've got "No datapoints found"

[brian-brazil]

With a 1m scrape interval, a 1m increase will very rarely work. Try increasing the window of the increase.

[slavede]

I just tried it, any idea why I get values like 1.5, or 2.5 then?

[juliusv]

Yes, the rate / increase functions extrapolate. The problem is that the
actual raw samples will never exactly align with your time range window
([1m]), so the first sample will be somewhat after the window boundary, and
the last sample will be somewhat before that. Depending on how exactly your
window is aligned, you might still catch the next sample or not, leading to
a different rate. At least for the normal case of fast-moving counters, it
is better to extrapolate from the actual interval between the first and
last sample to the desired rate / increase interval, because that is
usually a better indication of the true rate / increase. That extrapolated
rate / increase can then be non-integer.

On Tue, Oct 4, 2016 at 4:16 PM, Slaven Tomac notifications@github.com
wrote:

I just tried it, any idea why I get values like 1.5, or 2.5 then?

[image: image]
https://cloud.githubusercontent.com/assets/2838038/19077707/f11ea7f6-8a4d-11e6-897d-fb5ad9e16c68.png

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2052 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAg1mAWcpWPhxM4M2zr5cv6AHR1tGhABks5qwl_UgaJpZM4KNiFS
.

[slavede]

Thanks for the explanation!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.