Categorygithub.com/rexagod/resource-state-metrics
repositorypackage
0.0.0-20250120224100-51a1f2043fe4
Repository: https://github.com/rexagod/resource-state-metrics.git
Documentation: pkg.go.dev
Overview
Dependencies
13
Dependents
0

# Packages

No description provided by the author
No description provided by the author

# README

resource-state-metrics

CI Go Report Card Go Reference

Summary

resource-state-metrics is a Kubernetes controller that builds on Kube-State-Metrics' Custom Resource State's ideology and generates metrics for custom resources based on the configuration specified in its managed resource, ResourceMetricsMonitor.

The project's conformance benchmarking shows 3x faster RTT for resource-state-metrics as compared to Kube-State-Metrics' Custom Resource Definition Metrics (ea5826a) feature-set:

Thu Nov 21 05:06:09 IST 2024
[RESOURCESTATEMETRICS]
BUILD:	1059ms
RTT:	1107ms
[CUSTOMRESOURCESTATE]
BUILD:	1116ms
RTT:	3196ms

Development

Start developing by following these steps:

  • Set up dependencies with make setup.
  • Test out your changes with make apply apply-testdata local.
    • Telemetry metrics, by default, are exposed on :9998/metrics.
    • Resource metrics, by default, are exposed on :9999/metrics.
  • Start a pprof interactive session with make pprof.

For more details, take a look at the Makefile targets.

Notes

  • Garbage in, garbage out: Invalid configurations will generate invalid metrics. The exception to this being that certain checks that ensure metric structure are still present (for e.g., value should be a float64).
  • Library support: The module is never intended to be used as a library, and as such, does not export any functions or types, with pkg/ being an exception (for managed types and such).
  • Metrics stability: There are no metrics stability guarantees, as the metrics are user-generated.
  • No middle-ware: The configuration is unmarshalled into a set of stores that the codebase directly operates on. There is no middle-ware that processes the configuration before it is used, in order to avoid unnecessary complexity. However, the expression(s) within the value and labelValues may need to be evaluated before being used, and as such, are exceptions.
  • The managed resource, ResourceMetricsMonitor is namespace-scoped, but, to keep in accordance with Kube-State-Metrics' CustomResourceState, which allows for collecting metrics from cluster-wide resources, it is possible to omit any field or label selectors to achieve that result. Similarly, to isolate metrics between namespaces (or teams), the selectors may be levied, and a utility such as prom-label-proxy to enforce selective namespace(s) or custom label(s).
    • Enforce namespaced-collection behind a flag (for cluster admins)?

TODO

In the order of priority:

  • CEL expressions for metric generation (or *unstructured.Unstructured, if that suffices).
  • Conformance test(s) for Kube-State-Metrics' Custom Resource State API.
  • Benchmark(s) for Kube-State-Metrics' Custom Resource State API.
  • E2E tests covering the controller's basic functionality.
  • s/CRSM/CRDMetrics.
  • Draft out a KEP.
  • s/CRDMetrics/ResourceStateMetrics.
  • Make ResourceMetricsMonitor namespaced-scope. This allows for:
    • per-namespace configuration (separate configurations between teams), and,
    • garbage collection (without finalizers), since currently the namespace-scoped deployment manages its cluster-scoped resources.
  • Meta-metrics for metric generation failures.
  • Dynamic admission control for ResourceMetricsMonitor CRD.
License