Every Syself Autopilot cluster provides a few built-in observability components with no action needed from you: metrics-server, Hubble, and the node health daemon that drives self-healing. Beyond those, every core platform component exposes its own metrics for you to scrape securely, and the [control-plane](/docs/hetzner/apalla/observability/metrics/control-plane-metrics) and [data-plane](/docs/hetzner/apalla/observability/metrics/data-plane-and-addon-metrics) metrics guides show you how. The components that store, query, and alert on all of this data are yours to install. Here is the item-by-item breakdown.

## Built in

### metrics-server

metrics-server reads current CPU and memory usage from every node and serves it through the Kubernetes metrics API. It powers `kubectl top nodes` and `kubectl top pods`, and it feeds the HorizontalPodAutoscaler that scales a workload up or down based on CPU or memory. It keeps only the latest reading and not the history. See [metrics-server and live usage](/docs/hetzner/apalla/observability/metrics/metrics-server-and-live-usage).

### The node health daemon

A health daemon runs on every node and drives self-healing: on cloud servers it reboots a node and, if that does not fix it, replaces it. On bare-metal servers it reboots the machine. It records what it finds as conditions you can read or alert on and as a short health report in the node's annotations. On bare metal, only a `Ready=False` node reboots automatically, so you alert on the other conditions yourself. See [Detection vs retention](/docs/hetzner/apalla/observability/detection-vs-retention) for the full loop and [Platform alert rules](/docs/hetzner/apalla/observability/alerting/platform-alert-rules) for the conditions to watch.

### Hubble

Hubble is Cilium's network observability layer, on by default. It records every connection and every dropped packet. Its metrics bind to loopback on each node, so they stay private to the node; scrape them the secure, supported way the metrics pages describe. See [See flows with Hubble](/docs/hetzner/apalla/observability/network-flows/see-flows-with-hubble).

## Not built in

None of these run until you install them:

| Component                                                                                                           | How you install it                                              | What it gives you                                                   |
| ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------- |
| [Grafana Alloy](/docs/hetzner/apalla/observability/collection/using-alloy-for-observability)                        | Helm, twice: a node-level DaemonSet and a clustered StatefulSet | collects the metrics, logs, and traces and ships them to your store |
| [Prometheus operator](/docs/hetzner/apalla/observability/metrics/set-up-prometheus#install-the-operator)            | its `bundle.yaml`, through kustomize                            | the CRDs and the controller that run the next two                   |
| [Prometheus](/docs/hetzner/apalla/observability/metrics/set-up-prometheus#deploy-the-store)                         | a `Prometheus` object                                           | stores the samples the agents write, and evaluates your alert rules |
| [Alertmanager](/docs/hetzner/apalla/observability/alerting/set-up-alertmanager)                                     | an `Alertmanager` object                                        | turns a firing alert into a notification, and routes it             |
| [kube-state-metrics](/docs/hetzner/apalla/observability/metrics/kube-state-metrics)                                 | Helm                                                            | Kubernetes object state, including the node conditions above        |
| [node-exporter](/docs/hetzner/apalla/observability/metrics/node-and-hardware-metrics)                               | Helm                                                            | per-node CPU, memory, disk, and network                             |
| [Grafana](/docs/hetzner/apalla/observability/dashboards/set-up-grafana)                                             | Helm                                                            | one query surface and the dashboards over all of it                 |
| [Loki](/docs/hetzner/apalla/observability/logs/set-up-loki)                                                         | Helm                                                            | log aggregation and retention                                       |
| [Tempo or Jaeger](/docs/hetzner/apalla/observability/traces/install-tempo-or-jaeger)                                | Helm                                                            | trace storage                                                       |
| [Mimir, Thanos, or Victoria Metrics](/docs/hetzner/apalla/observability/metrics/long-term-storage-and-remote-write) | Helm                                                            | history beyond what one Prometheus holds                            |

One agent covers metrics, logs, and traces, which is why these guides use Alloy throughout rather than a Prometheus agent plus a log shipper plus a separate trace collector. Vector, Fluent Bit, and the OpenTelemetry Collector do the same jobs if you already run them; [Using Alloy for observability](/docs/hetzner/apalla/observability/collection/using-alloy-for-observability) explains what the choice does and does not commit you to.

## Why the platform ships no storage

Storing telemetry is an opinion about retention, cost, and where your data lives, and it is one you should own. Leaving it out means you pick the tools, keep the data in your own cluster or central store, and set retention to what your budget and compliance need.

The guides that follow show how to deploy them and how to securely scrape every metric the cluster exposes.