prometheus / prometheus/alertmanager
Prometheus link in Alertmanager notification loads latest data
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 8.6k
- Forks
- 2.5k
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 61
Description
What did you do?
I have an Alertmanager up and running. I created an alert rule that check the status of the RS:
- alert: ReplicaSetReplicasDown
expr: |
kube_replicaset_status_replicas
- kube_replicaset_status_ready_replicas > 0
for: 10m
labels:
severity: critical
annotations:
description: "*Count:* `{{ $value }}` \n
*ReplicaSet:* `{{ $labels.replicaset }}` \n
*Namespace:* `{{ $labels.namespace }}` \n
*Cluster:* `{{ $labels.monitor }}`"
summary: ReplicaSet pods are down
Everything is working as expected. When the pods are down I get a notification in Slack. Today I was investigating an old alert and saw that the link that the alert manager sends to Slack is loading the latest data in Prometheus.
What did you expect to see?
If the alert was triggered at 15:06 on 17.02.22 I expect the link in the notification to open the Prometheus and load the metrics from that timeframe.
What did you see instead? Under which circumstances?
Every time I open the link I am presented with the current data.
Is there a way to achieve the desired behaviour? I go over the documentation but did not find anything.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Alertmanager notification's Prometheus link and the related documentation; reproduce the Slack link from an old alert and compare it with the alert timestamp. Determine whether the link can open data from the firing time, then document or test the behavior once the expected historical view is defined.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, prometheus
- Domain
- observability
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100