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

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