New Label for the application-controller: argocd_app_labels
- Dominant language
- Go
- Stars
- 24.2k
- Forks
- 7.8k
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 239
Description
# Summary
It would be nice if the application-controller would expose an additional metric which I'd call `argocd_app_labels`. This metric would contain label information for the application in question.
# Motivation
A lot of teams deploy applications into kubernetes and also do create alerts using metrics for these.
The problem here is how to achieve a situation were alerts are only shown to teams who are actually interested in them?
One incomplete solution would be that each alert has unique label matchers that match the instance label for example, if the instance label is the one used by argocd to know to which application an object belongs. One problem of this that there will be a multitude of alerts which only differ in label matchers. And the other problem is that there are alerts to which no information of the application
can be retrieved. Like alerts on metrics scraped by kube-state-metrics or cadvisor.
Alerting on an unready endpoint for example. Or memory usage by a container.
# Proposal
If I had the `argocd_app_labels` metric for example, which could hold information like this for an `example-app`:
```
argocd_app_labels{name="example-app",project="example-project",label_some_label_name="some_label_value",label_other_label_name="other_label_value"}
```
I could add a team-label to the application object like `app.organisation.tld/team: TheTeam`.
This could be translated into the metrics label `label_app_organisation_tld_team="TheTeam"`
By knowing that argocd inserts the application name into the instance label I could map the team label into my alert. And do specific routing inside e.g alertmanager.
One argument against this approach would be the possibility to use kustomize and add the team-label as a commonLabel, but this would drag this labels into all selectors which would not be very nice.
Adding it into all objects individually or via mutating webhook, seems like a huge overhead.
Thanks for your time and consideration of my request.
Contributor guide
Research direction
The issue names the application-controller and proposes an argocd_app_labels metric, but it does not identify files, tests, or entry points. Start by locating the application-controller metrics implementation and existing metric tests; done means the metric exposes the requested application and label information with documented, tested behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- backend, observability
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100