Observability in Platform Base

Platform Base ships a metrics and logs stack that works without further configuration. It is built from two independent roles. You can run both in one cluster, which is the default, or spread them over several clusters.

Collector and storage

Role	Components	Switch
Collector	Grafana Alloy, kube-state-metrics, node-exporter	observability.collector.enabled
Storage	Grafana Mimir (metrics), Grafana Loki (logs), Grafana	observability.storage.enabled

The collector gathers metrics and logs of the cluster it runs in and forwards them. It sends them to the storage of the same cluster, to an external target such as the storage of another cluster, or to both.

The storage role stores and shows the data. It can also run without a local collector.

A cluster can therefore be collector-only (storage off, data sent to an external target), storage-only, or both. Enabling storage requires both observability.storage.metrics.enabled and observability.storage.logs.enabled.

What the collector gathers

Alloy gathers:

• Metrics from every ServiceMonitor, PodMonitor and Probe in the cluster, from the kubelet and cAdvisor, from the API server, and optionally from the scheduler, the controller manager and kube-proxy.
• Rules and alerts from PrometheusRule and AlertmanagerConfig resources. It syncs them into Mimir's ruler and Alertmanager. The CRDs come from the prometheus-crds Application, so your own workloads can ship them.
• Kubernetes events. Pod logs are only collected when you set observability.collector.logs.allPods to true, or create your own PodLogs objects.

Every metric gets the label cluster="<observability.clusterName>". A series that already has a cluster label keeps it. Mimir and Loki use the same value for their own series, and the dashboards select on this label.

Tenants and datasources

Mimir and Loki are multi-tenant. Platform Base uses one tenant per platform, named after observability.clusterName (default: the first entry of baseDomains). Alloy sends data with that tenant ID, and Grafana has one datasource per tenant, named mimir/<tenant> and loki/<tenant>. The first metrics datasource is the default.

Alerts and dashboards

Each component ships its own alert rules and Grafana dashboards, and turns them on together with its monitor. Rules need the Mimir ruler, dashboards need Grafana.

Dashboards are read-only and appear in the Grafana folder Platform. Alert rules from your own PrometheusRule resources are evaluated by Mimir, and AlertmanagerConfig resources define where notifications go.

Profiles

observability.profile sizes the whole stack together:

Profile	Mimir, Loki and Alloy
singleNode	One replica of everything, replication factor 1, Loki as a single binary.
small	The default. Chart default replica counts for Mimir, three replicas per Loki target, replication factor 3.
large	More replicas and resources for high availability and throughput.

Object storage

By default Mimir and Loki each run the bundled MinIO of their chart, with generated credentials. Set observability.storage.backend.type to s3 to use an external S3-compatible endpoint for both.

Retention is shared by Mimir and Loki and defaults to 30 days (observability.retention).

warning

Choose the profile and the storage backend before the first sync. Changing either on a running cluster does not migrate data. The volume claim templates of the StatefulSets and the layout of the bundled MinIO cannot change in place, so Argo CD either fails to sync or leaves the old data behind. The same applies to observability.storage.storageClass.

See Configure observability for the options.