Skip to main content
Version: main 🚧

Fleet metrics architectures

Use Fleet Observability for new fleet-wide metrics deployments. It's the Platform-managed observability feature. The other pages in this section are operator-maintained reference architectures that predate Fleet Observability.

The architectures don't share a label contract. Dashboards, alerts, and recording rules built for one architecture don't automatically work with another.

Compare the architectures​

Fleet ObservabilityFleet monitoring with OpenTelemetryAggregating Metrics
StatusRecommended Platform featureReference architectureReference architecture
Identity labelsvcluster_platform_*, authenticatedvcluster_*/cluster, self-reportedloft_*, self-reported
Read access controlScoped per tenant or cluster, Platform-authorizedNone, any reader sees all dataNone, any reader sees all data
GPU observabilityDCGM, NVSentinelNot coveredNot covered
Requires Argo CD for the bundled deploy pathYes (manual config available for Standalone)NoNo
Runs on embedded Kubernetes platform deploymentsNoYesYes
Included examplesQuery examplesPromQL library and two Grafana dashboardsPrometheus and Grafana example
Operational ownershipPlatform gateway and access policy, plus your metrics backendYou maintain and validate the collector Apps and backendYou maintain and validate the collector and backend

When a reference architecture is necessary​

Fleet Observability's bundled Argo CD deployment doesn't cover vCluster Standalone. You can still configure a collector manually. Embedded Kubernetes deployments can't run the observability gateway.

If either constraint applies, the older guides can help you design a direct collector path:

These guides aren't maintained as turnkey production configurations. Validate chart versions, security settings, resource sizing, and backend compatibility for your environment.

Next steps​