Skip to content
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

Expose MR Metrics #555

Closed
Tracked by #4620
humoflife opened this issue Sep 21, 2023 · 5 comments
Closed
Tracked by #4620

Expose MR Metrics #555

humoflife opened this issue Sep 21, 2023 · 5 comments
Assignees
Labels

Comments

@humoflife
Copy link

humoflife commented Sep 21, 2023

What problem are you facing?

Crossplane users would benefit from the ability to offer service level objectives (SLOs) to their users. To do this they need MR related metrics.

How could Crossplane help solve your problem?

At the Crossplane pod port 8080/metrics interface, expose the following:

  • number of MRs total, by claim, by composition

  • number of MRs in Synched False State total, by claim, by composition

  • number of MRs in Synched True State total, by claim, by composition

  • number of MRs in Synched Unkown State total, by claim, by composition

  • number of MRs in Ready False State total, by claim, by composition

  • number of MRs in Ready True State total, by claim, by composition

  • number of MRs in Ready Unknown State total, by claim, by composition

  • number of MRs in Synched True and Ready True State total, by claim, by composition

  • number of MRs in Synched False and Ready True State total, by claim, by composition

  • number of MRs in Synched Unknown and Ready True State total, by claim, by composition

  • number of MRs in Synched True and Ready False State total, by claim, by composition

  • number of MRs in Synched False and Ready False State total, by claim, by composition

  • number of MRs in Synched Unknown and Ready False State total, by claim, by composition

  • for each MR, time to readiness (Synched True -> Ready True)

  • for each MR, time to non-readiness (Ready True -> Synched !True)

  • for each MR, number of Synched state changes

  • for each MR, number of Ready state changes

  • for each MR, time from deletion request to external resource and MR deletion

  • for each claim, time to readiness (from claim created to ready)

  • for each claim, time to delete all associated resources (from claim to external resources removed)

  • if possible, control plane availability and uptime (since last Crossplane pod restart).

The implementation of the metric gathering could be performed in the Crossplane runtime reconciler code, line 675+.
https://github.com/crossplane/crossplane-runtime/blob/master/pkg/reconciler/managed/reconciler.go#L675

An example time to readiness calculation is located in Uptest at https://github.com/upbound/uptest/blob/6e567ebd9ed30f1b1670d2cbbb679fde9beebc6b/cmd/perf/internal/managed/managed.go#L171

@negz
Copy link
Member

negz commented Feb 28, 2024

Something to double-check for whoever works on this: do we need to add all of these metrics as individual time series? Let's make sure we focus on adding low-level, flexible time series that can be composed to produce useful higher level metrics.

@blut
Copy link

blut commented Mar 20, 2024

For anyone working with crossplane https://github.com/crossplane-contrib/x-metrics might provide useful metrics to aggregate the requested metrics.

@pierluigilenoci
Copy link

@ezgidemirel, from your experience and knowledge, how much hope is there to see this or something similar implemented in Crossplane? 🙏🏻

Thank you. ❤️

@momoXD007
Copy link

From an observability point of view Crossplane so far is lacking a good strategy to monitor the MRs and claims in "kubernetes native way".
It is hard to track the overall health of an environment without understanding if just one single claim or MR is not synched or suddenly hundreds of them are not synched.

It is currently also hard to understand adoption of Crossplane in a bigger environment: if you can't pinpoint which compositions are used the most.

@ezgidemirel
Copy link
Member

Hi @pierluigilenoci, as we discussed in the slack thread, I'm closing this issue as completed.

We have introduced MR metrics with #683 but decided not to add MR names, claim names or composite names to the exposed metrics as labels. The reason is, we don't want to create a metric for each managed resource created on the cluster. This will increase the cardinality dramatically. You can see more details in the comment here.

Further discussions about having more detailed metrics can be carried on within this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants