Every Syself Autopilot cluster ships live signals: metrics-server for current CPU and memory, Hubble for network flow visibility, and a health daemon that watches each node and drives self-healing. It does not ship the stack that stores and displays that data. Long-term metrics, dashboards, log aggregation, tracing, and alerting are yours to run. You keep the data and decide how long to hold it.

Most components bind their metrics to loopback, so they stay private and are never reachable over the network. The metrics guides show you the supported way to scrape them from the node itself. Nodes are sealed and replaced as part of self-healing, so keep your logs in a store off the node. A few node conditions, the health flags Kubernetes keeps on each node, are yours to alert on.

What Syself runs, what you run

Observability here has three parts:

• Syself Autopilot reacts to your infrastructure. A health daemon on every node watches for problems. It reports what it finds in two places: node conditions, which you can alert on, and a short health summary in the node's annotations. If a node stays unhealthy, Syself Autopilot reboots it. If the reboot does not fix it, Syself Autopilot replaces the node. See Detection vs retention for what the platform detects and what you keep. Every cluster also runs metrics-server and Hubble.
• You collect the cluster's own signals. Every component exposes its metrics securely, and Collection shows you the agents that gather them from each node, along with its logs.
• You choose the tooling on top. Storage, dashboards, logs, traces, and alerting are yours to pick and run, so the data stays in your own cluster or central store and you set your own retention.

Where to go next

Read these first:

• What ships and what you bring : what already runs in every cluster, and what you install yourself.
• Detection vs retention : what disappears when a node is replaced, and what you have to store yourself.
• Plan your observability stack : where the store runs, how long you keep data, and how large it grows.

Then each section, and what it covers:

• Collection : the Alloy agents that gather metrics, logs, and traces, kept separate so one application cannot take your node telemetry down with it.
• Metrics : metrics-server for live CPU and memory, and Prometheus for the history it does not keep.
• Reference: metrics per component : where each component exposes its metrics, and which collection method reaches it.
• Logs : what a sealed node logs, why those logs are gone once the node is replaced, and how to ship them to Loki first.
• Traces : follow one request across your services, from the spans your code sends to a store such as Tempo or Jaeger.
• Dashboards : Grafana over the data you already collect, the panels that reflect a Syself Autopilot cluster, and how to keep dashboards in Git.
• Alerting : turn a firing rule into a notification, route it to the right channel, and group or silence what you do not need to see.
• Network flows : Hubble runs in every cluster and records which connections are made, which packets are dropped, and why.
• Fleet and management cluster : alert on the Cluster API objects that describe your clusters, and query several clusters from one place.