I have a custom counter metric that should increase one time a day at a specific time period. and I have to create an alerting rule that fires if this metric doesn't increase.
Infrastructure: Kubernetes
So for my case, I used the next alerting expression:
increase(my_custom_metric[1d]) == 0
But it seems to be some issues with using it. Suppose the pod restarted and the counter reset, after a couple of hours the counter increased by one, but the value of the expression above still remains 0. What expression should be used to account for such situations?
Related
given the following promql with alertmanager integration:
what's a good way to alter this expression so that when a pod restart is indicated by this promql and an alert triggered (expected) that an alert isn't automatically resolved on the next check since on the next check it's likely a restart will no longer register (unless a pod is flapping or something). We want to be alerted so we can check it out so we want to manually resolve the alert:
sum(rate(kube_pod_container_status_restarts_total[2m])*100) by (namespace,container) > 0
A potential alertmanager rule would be the following, but we don't yet have an actual rule.
- alert: Unexpected POD restart(s) occurring
expr: sum(rate(kube_pod_container_status_restarts_total[2m])*100) by (namespace,container) > 0
for: 10s
annotations:
summary: POD restarts occurring
An alert is raised when your query produces at least one metric and the alert is resolved when it no longer produces a metric.
sum by (...) (rate(kube_pod_container_status_restarts_total[2m])) > 0
means that it calculates the rate over the last two minutes. So if a restart occurs, the this expression will result in 0 after 2 minutes and your alert is resolved.
What you could do is simply increase the time interval:
sum by (...) (rate(kube_pod_container_status_restarts_total[1h])) > 0
so the alert stays on for an hour.
May be you dont want to check for every single restart, but if there are pods that restart within a specific time at least twice, so that might be the better expression:
sum by (...) (increase(kube_pod_container_status_restarts_total[24h])) > 2
meaning if a container restert at least two times within a day that might be a situation you want to have a look at.
I'm trying to create a graph of total POST requests per minute in a graph, but there's this "ramp up" pattern that leads me to believe that I'm not getting the actual total of requests per minute, but getting an accumulative value.
Here is my query:
sum_over_time(django_http_responses_total_by_status_view_method_total{job="django-prod-app", method="POST", view="twitch_webhooks"}[1m])
Here are the "ramp up" patterns over 7days (drop offs indicating a reboot):
What leads me to believe my understanding of sum_over_time() is incorrect is because the existing webhooks should always exist. At the time of the most recent reboot, we have 72k webhook subscriptions, so it doesn't make sense for the value to climb over time, it would make more sense to see a large spike at the start for catching webhooks that were not captured during downtime.
Is this query correct for what I'm trying to achieve?
I am using django-prometheus for exporting.
You want increase rather than sum_over_time, as this is a counter.
If the django_http_responses_total_by_status_view_method_total metrics is a counter, then increase() function must be used for returning the number of requests during the last minute:
increase(django_http_responses_total_by_status_view_method_total[1m])
Note that increase() function in Prometheus can return fractional results even if django_http_responses_total_by_status_view_method_total metric contains only integer values. This is due to implementation details - see this comment and this article for details.
If the django_http_responses_total_by_status_view_method_total metric is a gauge, which shows the number of requests since the previous sample, then sum_over_time() function must be used for returning requests per last minute:
sum_over_time(django_http_responses_total_by_status_view_method_total[1m])
I would like Prometheus to scrape metrics every hour and display these hourly scrape events in a table in a Grafana dashboard. I have the global scrape interval set to 1h in the prometheus.yml file. From the prometheus visualizer, it seems like Prometheus scrapes around the 43 minute mark of every hour. However, it also seems like this data is only valid for about 3 minutes: Prometheus graph
My situation, then, is this: In a Grafana table, I set the min step of a query on this metric to 1h, but this causes the table to say that there are no data points. However, if I set the min step to 5 minutes, it displays the hourly scrape events with a timestamp on the 45 minute mark. My guess as to why this happens is that Prometheus starts on the dot of some hour and steps either forward or backward by the min step.
This does achieve what I would like to do, but it also has potential for incorrect behavior if Prometheus ever does something like can been seen at the beginning of the earlier graph. I also know that I can add a time shift, but it seems like it is always relative to the current time rather than an absolute time.
Is it possible to increase the amount of time that the scrape data is valid in Prometheus without having to scrape again every 3 minutes? Or maybe tell Prometheus to scrape at the 00 minute mark of every hour? Or if not, then can I add a relative time shift to the table so that it goes from the 45 minute mark instead of the 00 minute mark?
On a side note, in the above Prometheus graph, the irregular data was scraped after Prometheus was started. I had started Prometheus around 18:30 on the 22nd, but Prometheus didn't scrape until 23:30, and then it scraped at different intervals until it stabilized around 2:43 on the 23rd. Does anybody know why?
Your data disappear because of the staleness strategy implemented in Prometheus. Once a sample has been ingested, the metric is considered stale after 5 minutes. I didn't find any configuration to change that value.
Scraping every hour is not really the philosophy of Prometheus. If your really need to scrape with such a low frequency, it could be a better idea to schedule a job sending the data to a push gateway or using a prom file fed to a node exporter (if it makes sense). You can then scrape this endpoint every 1-2 minutes.
You could also roll your own exporter that memorize the last scrape and scrape anew only if the data age exceeds one hour. (That's the solution I would prefer)
Now, as a quick solution you can request the data over the last hour and average on it. That way, you'll get the last (old) scrape taken into account:
avg_over_time(old_metric[1h])
It should work or have some transient incorrect values if there is some jitters in the scheduling of the scrape.
Regarding the issues you had about late scraping, I suspect the scraping failed at those dates. Prometheus retries only at the next schedule (1h in your case).
If the metric is scraped with intervals exceeding 5 minutes, then Prometheus would return gaps to Grafana because of staleness mechanism. These gaps can be filled with the last raw sample value by wrapping the queried time series into last_over_time function. Just specify the lookbehind window in square brackets, which equals or exceeds the interval between samples. For example, the following query would fill gaps for my_gauge time series with one hour interval between samples:
last_over_time(my_gauge[1h])
See these docs for time durations format, which can be used in square brackets.
I have an application that consumes work to do from an AWS topic. Work is added several times a day and my application quickly consumes it and the queue length goes back to 0. I am able to produce a metric for the length of the queue.
I would like a metric for the time since the length of queue was last zero. Any ideas how to get started?
Assuming a queue_size gauge that records the size of the queue, you can define a recorded rule like this:
# Timestamp of the most recent `queue_size` == 0 sample; else propagate the previous value
- record: last_empty_queue_timestamp
expr: timestamp(queue_size == 0) or last_empty_queue_timestamp
Then you can compute the time since the last time the queue was empty as simply as:
timestamp(queue_size) - last_empty_queue_timestamp
Note however that because this is a gauge (and because of the limitations of sampling), you may end up with weird results. E.g. if one work item is added every minute, your sampling interval is one minute and you sample exactly after the work items have been added, your queue may never (or very rarely) appear empty from the point of view of Prometheus. If that turns out to be an issue (or simply a concern) you may be better off having your application export a metric that is the last timestamp when something was added to an empty queue (basically what the recorded rule attempts to compute).
Similar to Alin's answer; upon revisiting this problem I found this from the Prometheus documentation:
https://prometheus.io/docs/practices/instrumentation/#timestamps,-not-time-since
If you want to track the amount of time since something happened, export the
Unix timestamp at which it happened - not the time since it happened.
With the timestamp exported, you can use the expression time() -
my_timestamp_metric to calculate the time since the event, removing the need for
update logic and protecting you against the update logic getting stuck.
I have a very simple case where I want to see how many time a user click on the ButtonA in my app. I'm using DropWizard metrics counter to archive this and the coursera reporter to report them to DataDog every 1 minutes.
registry.counter("buttonA").inc();
But what is happening is that this counter doesn't behave like I thought it would. so for example if the buttonA has been clicked 4 times, the counter will keep the value 4 until the app restart which is not very useful.
Is there an other metrics I'm not aware about that would keep a count and at each reports reset to 0 ? So that on Datadog dashboard I can easily sum all the count and manage to get the exact numbers even if the app is restarted it will not affect the metrics.
I don't think there is something that does this for you automatically. You have to reset the counter yourself at each reporting interval. Something like this should work:
long count = registry.counter("buttonA").getCount();
dataDogReporter.report("buttonA", count);
registry.counter("buttonA").dec(count);