Dashboards for a Syself Autopilot cluster
The stock "Kubernetes cluster" dashboards assume a stock cluster. On a cluster created with Syself Autopilot, some of their panels are empty (a panel is one chart, and these scrape endpoints that are not there), and some real signals have no panel at all (Cilium, the CCM, the node integrity conditions). The dashboards that follow reflect what the cluster actually runs, assuming the collectors are scraping the targets in Collection .
Start with the community dashboards#
Nothing installs dashboards for you, so the day-to-day resource views come from grafana.com. These four cover it, and they work as-is because they read kube-state-metrics, node-exporter, and the kubelet, all of which you are collecting:
| ID | Dashboard | What it shows |
|---|---|---|
1860 | Node Exporter Full | per-node CPU, memory, filesystem, disk, and network |
13332 | kube-state-metrics-v2 | Deployment, PVC, Job, and quota state |
15757 | Kubernetes / Views / Global | cluster-wide resource use, with 15759 for nodes and 15760 for pods |
9578 | Alertmanager | notification and delivery rates for the alerting plane itself |
Add the platform components#
These have no panel in the generic set, and they are where Syself-specific problems show up:
- Cilium and Hubble. The Cilium project maintains Grafana dashboards for the agent, the operator, and Hubble flows. Import them from the Cilium repository. They read the
cilium-agentandhubblemetrics you scrape over loopback. - CCM. Cloud API call rates, rate-limit headroom, and load-balancer reconcile results, from the
ccm-metricstarget. This is where a Hetzner API rate-limit problem or a stuck load balancer becomes visible. - CSI. Volume provision, attach, and resize results, from the CSI controller and node metrics. Watch this when a PVC is slow to bind.
- Control plane and etcd. etcd's database size, fsync latency, and leader changes, plus controller-manager and scheduler queue depths, from the loopback control-plane scrape. Rising etcd fsync latency is an early warning on a busy control plane.
Add node integrity#
The node health conditions have no generic panel, and on bare metal they are the signal that does not self-heal. Build a small panel from kube_node_status_condition that lights up when VerityCorruption, NodeTampered, or a disk condition is set on any node, next to the alerts in Platform alert rules .
Importing and what to skip#
Import a community dashboard by its ID from grafana.com (Dashboards, New, Import, then the numeric id), and pick your Prometheus as the data source. Skip the panels that will never fill on this platform:
- kube-proxy panels: Cilium replaces kube-proxy, so there is nothing to show.
- In-tree cloud provider panels: the CCM is the out-of-tree Hetzner provider; use its own metrics instead.
A dashboard whose kube-proxy row is permanently empty is not broken; it is measuring something this cluster does not run.