-
Notifications
You must be signed in to change notification settings - Fork 602
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
metrics to show the current GitRepository #3106
Comments
The |
I think we're suggesting that you would use a static analysis to prevent this configuration before it reaches the cluster. I don't know if that means we shouldn't expose this as a metric, there are a lot of different things we could expose as a metric. This one is very specific to the GitRepository kind. The branch name is not something I think we would usually consider as a metric to export. More examples of metrics we might collect:
Maybe we can provide a more generic way to determine which metrics are exported, or maybe we should just spend some focus time on this and build the right metrics in so all use cases are happy 👍 Or, we could build some kind of external reporter that monitors the Flux objects through GitOps Toolkit API and provides those metrics on-demand. That would be a really good use of the Flux APIs! |
In our current setup, terraform is managing the My only concern is loosing the ability to do pre-merge testing. As part of our workflow we often flip a cluster to a custom branch to test out changes. That workflow can be changed to opening a PR and merging it to update the ref but then we still have the issue of folks forgetting to flip that ref back to the original one.
This is what I was thinking about doing too but wanted to see what the others thought about adding the ref as a label or its own metric first. And not to get off-topic but since our |
I'm not for adding the ref to metrics, a ref in spec can be a semver rage or a commit SHA, if we report the resolved ref then our metrics will suffer from high cardinality, each commit will result in a unique metric breaking our dashboards and all the current alerts people are using. Also having a different set of metrics for Git means we need to drop our generic metric and come up with dedicated ones for each custom resource kind and all their combined fields. |
I was thinking this could be implemented as an additional metric and not added as a label to existing metrics because of all the reasons you listed (and I 100% agree). kube and istio do this with the
e.g. we could have something like |
Why not adding the current sha1 (not the ref) so it is alway the same kind of value ? |
Please refer to: This has been addressed, now you can create any metrics that you wish if the information is in the CRD spec or status, you can create a metric to report on it. See also: |
Wonderful, will try it soon! Thanks ! |
Describe the bug
People may flip
GitRepository::spec.ref.branch
to adev
branch to test/verify something and forget to revert back after.It would be great if flux2 can export metrics to show the current
GitRepository::spec.ref.branch
.and then we can alert(warn) if
GitRepository::spec.ref.branch
is not onmain/master/prod
branch.Steps to reproduce
N/A
Expected behavior
N/A
Screenshots and recordings
No response
OS / Distro
N/A
Flux version
N/A
Flux check
N/A
Git provider
No response
Container Registry provider
No response
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: