Troubleshooting overview

Use this page to triage a CubeCOS issue before you dig into a specific area. Start with the cluster-wide health checks below, then move to the guide for the affected workload.

Before you begin

Some checks in the following sections require SSH access to the CubeCOS cluster virtual IP (VIP) as the admin user, or access to the OpenStack CLI on a controller node. Ask your platform administrator for access if you don't have it.

Check the overall cluster health

Start with a cluster-wide health check. Many instance, network, and storage problems trace back to a service reported here.

• Web UI: Review the health indicator panel in the dashboard. If it reports an error, click Repair to run an automated recovery action.

• CLI: Log in to the VIP with SSH, then run cluster check_repair.

  Check cluster service health

  ssh admin@<cluster-vip>

  Run a service health check

  controller> cluster check_repair

  Each row lists a service (for example, Network, Compute, Storage) and a status of ok or FIXING. A FIXING row identifies the failing component in brackets, such as neutron(3) for a network issue or nova(8) for a compute issue.

  For the full command output and an explanation of each service, see Monitor and repair CubeCOS services using the web UI or CLI.

Review logs and events

If the cluster health check doesn't explain the issue, review the logs for the affected resource.

• Instance action logs: Navigate to Compute > Instances, select the instance, open the Action Logs tab, and click Analyze on the event you want to investigate.
• Cluster-wide log search: Navigate to http://<cluster-vip>:5601/opensearch-dashboards/app/data-explorer/discover to query logs across all CubeCOS services.

For more information, see Log analysis in CubeCOS.

Check for existing alerts

Navigate to Events > Triggers to see whether an existing trigger already caught the issue, and to review any notifications it sent. For more information, see Manage triggers.