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. What it does not ship is the stack that keeps that data: long-term metric storage, dashboards, log aggregation, tracing, and alerting are yours to run. You own the data and the retention, so no vendor holds your telemetry.

Most components bind their metrics to loopback, the node's own internal address, 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. Because nodes are sealed and replaced as part of self-healing, you keep your logs in a store off-node, and 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 runs on every node and self-heals: on cloud servers it reboots a node and, if that does not help, replaces it; on bare-metal servers it reboots the machine. It records what it finds as node conditions you can alert on and as a short health report in the node's annotations. metrics-server and Hubble run in every cluster too. See Detection vs retention for how detection and self-healing work.
• 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#

• What ships and what you bring
• Plan your observability stack
• Collection
• Metrics
• Reference: metrics per component
• Logs
• Network flows