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 metrics guides show you how. The tooling that stores, queries, and alerts on all of this data is 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, the controller that scales a workload up or down based on CPU or memory. It keeps only the latest reading, not 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: Each one is a separate install with its own page, so you add the pieces you want and know what each is for: | 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) | its `bundle.yaml`, through kustomize | the CRDs and the controller that run the next two | | [Prometheus](/docs/hetzner/apalla/observability/metrics/set-up-prometheus) | 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, not inherit. Shipping a fixed metric or log store would put your operational data in a component Syself controls, size it for you, and bill you for it. Leaving it out means you pick the tools, keep the data in your own cluster or your own central store, and set retention to what your budget and compliance need. You self-host the same Prometheus, Grafana, and Loki a SaaS charges per-metric and per-GB for, on servers you already pay for. You own the data and you own the retention. The guides that follow show how to stand it up and how to scrape every metric the cluster exposes, the secure way.