Inspect Health, Logs and Audits
Use Management for current appliance state and Grafana for dashboards and retained operational and audit history. Local monitoring is separate from optional customer metrics and Syslog forwarding.
Work as a Management administrator with active cluster access. If Management or its cluster access is unavailable, restore access before interpreting missing dashboards as appliance failure.
Check current Health
-
Open Appliance > Overview.
-
Check Cluster status, Current release and Last live check. Stale or missing status cannot tell you whether the appliance is healthy or has failed.
-
Inspect each node’s Live readiness. Expand a node to compare configured network and disk details with the reported addresses.
-
Open Grafana from the Management header. Inspect the appliance and ERS service dashboards for the affected interval.
-
Test the application operation affected by the incident, such as opening CLM or performing the required enrollment task.
Useful dashboards include ERS Service Health, Observability Health, Backup and Recovery and Customer Log Export. Check monitoring collection and delivery when several unrelated panels stop reporting at once.
Check that alert notifications reach the operators responsible for responding. Dashboard alert state alone does not confirm delivery.
Read API-server Availability and Alert State
The API-server dashboards show availability and service-level objectives, or SLOs, over time. An error budget is the amount of failure allowed by the objective; burn rate shows how quickly failures use up that allowance. These measurements describe the Kubernetes API, not end-to-end ERS service availability.
Mimir evaluates the API-server SLO and burn-rate rules against retained metrics. A fresh installation has only the history collected so far, so a 30-day view is incomplete until enough history exists. Missing data or Unknown is not evidence of healthy operation.
Prometheus continues to evaluate operational alerts, including monitoring failures. Grafana uses Mimir for dashboard metrics and a separate prometheus-alerts source for current local alert state. That source is not a fallback store for historical dashboard queries. Both rule evaluators send alerts to the appliance’s Alertmanager.
If MimirRuleEvaluationFailed fires, inspect Observability Health and Mimir ruler logs in Headlamp. Check rule errors, storage access and cluster membership. After a network interruption, a ready Mimir Pod alone does not prove that all Mimir members have rejoined. Collect diagnostics if the problem persists.
Inspect operational Logs
Use Grafana’s Logs and Events Explorer dashboard or Explore to select the relevant appliance, node, component and time range. Correlate errors with the time of the action and any configuration commit. Use Headlamp when you need current workload status, events or logs to explain a failure.
Distinguish Management host and application diagnostics from the managed appliance’s retained logs. For Management startup or host failures, follow Collect diagnostics.
Inspect CLM and CARA Audits
-
In Grafana, open CLM Audit Log or CARA Audit Log.
-
Select the incident time range. The initial dashboard view covers the last 24 hours.
-
Use the dashboard’s Explore links to search and page through more results when required.
-
Retain original records and their source identity if an investigation requires signature verification.
Audit panels show up to 5,000 entries for the selected interval. A panel download contains that query result, not a complete audit archive. The viewer classifies records but does not verify signatures. CLM starts a new signature chain after each process restart, so preserve pod identity and process-start markers for verification.
Local audit payloads retain their original content. They bypass ordinary operational-log redaction. Treat them as sensitive records. Grafana folders and stream labels are not separate authorization boundaries.
Understand retained History
Local logs are configured for 180 days of retention. Limited storage or queue capacity, collection failures and destination rejection can leave gaps. Kubernetes Events are not Kubernetes API audit history; the local log pipeline does not collect the API server audit file in this release.
Appliance backups exclude telemetry history. Losing the appliance can also lose its local history. If records must survive appliance loss, store them externally and check that you can retrieve them for the required retention period. See customer monitoring and Syslog.
If logs or metrics stop, inspect Observability Health, delivery failures and available storage before assuming the producing application has stopped. Collect diagnostics and record the missing time interval for support.