Inspect cluster health

Open a native managed cluster’s Grafana from its observability component in Portal. Grafana opens Cluster overview. Confirm the cluster ID in the title before investigating; it is the registration ID, which can differ from a Portal display name.

The dashboards are provisioned in the Cluster folder and maintained with the observability add-on. Portal users have Viewer access. To retain an operator’s custom dashboard, save a separate copy under a different UID instead of changing the provisioned definition.

Start with collection and readiness

1. Check collection health on Cluster overview. A missing or failed scrape makes the related data unavailable; it does not indicate zero usage or a healthy cluster.
2. Check node readiness and workload availability. Use Nodes and capacity for pressure and resource headroom, or Workloads and pod health to narrow the namespace and workload.
3. Follow a pod’s logs link into Loki Explore. The namespace, pod and time range help focus the investigation. Empty logs can mean no matching entries, a collection problem or data outside retention.

Dashboards start with the last hour and refresh every minute. Narrow the time range and namespace for detailed investigation. Largest-consumer views are bounded; they are not a complete inventory of every application.

Investigate platform components

Use Cluster System and add-ons to inspect observed readiness, pod restarts and Argo reconciliation. Optional components that are not observed are not reported as unhealthy installations. Cross-check the cluster’s component view in Portal when deciding whether a component should be installed.

Kubernetes readiness alone does not prove that agents delivered reports, the VPN can carry traffic, authentication works or registry transfers succeed. Confirm those operations separately when investigating a functional failure.

Distinguish data gaps from capacity problems

Use Observability pipeline to check scrape health, sample counts, Prometheus storage, rule evaluation and available component metrics. A failed kubelet scrape can remove CPU or memory usage while Kubernetes object-state metrics remain available. Do not compare those panels as if both were current.

Resource requests reserve scheduling capacity. Limits constrain running containers. An absent limit is Not set, not zero capacity; containers without CPU limits can use available CPU. Volume statistics depend on the storage driver and can be unavailable even when a volume is bound.

The dashboards contain no VPA recommendations or automatic resource changes. They do not add alert rules or external notifications. Namespace filters are navigation aids: every authenticated Context member with Grafana access can query all telemetry in that Context’s eligible clusters.

For access requirements and troubleshooting, see Access cluster Grafana through Portal.

Inspect managed tunnels

On a native managed cluster’s detail page, open Tunnels, or choose View tunnels from the VPN component. Admins see all current sessions for that cluster within the selected Context, including CI. Other members see their own corectl and Portal access sessions across devices. CI jobs have separate identities; starting a workflow does not make its tunnel a human-owned session.

Filter by purpose, Portal service or observed state. Each row shows purpose and service, owner for admins, reported streams/state, transport, session age and lease time remaining. Portal access / Grafana identifies the currently supported browser service without making the proxy Grafana-specific. Transport shows the last observed path for that session and remains visible between requests or while reports are unavailable. Unknown means no path has been observed yet. A remembered transport does not establish current connectivity.

Expand a row for its copyable session ID, last confirmed renewal, lease expiry, observation time and safe reported reason. Use the ID to correlate a CLI session or lifecycle log when troubleshooting. A valid lease establishes authorization; an open stream observation does not prove current traffic or target health.

Idle means the connector last confirmed that the session had no open streams. It remains Idle while that same connector continues reporting, even if the session has no new traffic. If connector reporting stops for 90 seconds, it becomes Stale. Open and Recovering observations need a new session report within 90 seconds; a connector heartbeat alone does not keep them current. Missing observations, including after a connector restart, show Unknown until that connector reports the session. Idle does not prove that the next connection will succeed, and renewing a lease alone does not refresh the reported state.

Portal refreshes only the current page while the Tunnels tab is active and the browser is visible. During an API outage, previously displayed rows remain marked as last known; their observations age locally. An elapsed last-known lease is not proof that the remote session has expired, because Portal may have renewed it after the last read. An unavailable initial read is distinct from an empty inventory.

The view shows current status, with no remote disconnect or historical audit. Direct Kubernetes connections that bypass managed tunnels are not listed. Use corectl get tunnels --context core-platform/engineering for local worker inspection during a Portal outage; get clusters still needs the cluster API.