For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

Configure the Solo UI for improved availability and telemetry data persistence.

The Solo UI is your primary interface for monitoring the health of your Istio environment. When components in the data plane or control plane degrade or fail, the UI surfaces the signals you need to diagnose and respond quickly. Planning for UI availability means ensuring that window stays open during incidents, not just during steady-state operations.

The Istio service mesh operates independently of the Solo UI. If the UI becomes unavailable, the mesh continues to route traffic and enforce policies, but you lose visibility into its state. The following sections describe how to protect telemetry data and maintain UI availability even during an incident.

The Solo UI consists of stateless components, including the UI server, OTel collectors, and tunnel server, and one stateful component, ClickHouse. Because the stateless components recover automatically on pod restart, ClickHouse is the primary production concern for high availability, as it is the only component that can lose telemetry data in the event of an outage.

ClickHouse data persistence

By default, the bundled ClickHouse deployment uses a non-persistent EmptyDir volume. If the ClickHouse pod restarts, all telemetry history is lost and the UI repopulates from the time the pod comes back online. To protect telemetry data, choose one of the following options.

Option 1: Enable PVC-backed storage

Enable a PersistentVolumeClaim for the bundled ClickHouse instance. The PVC is backed by your cluster’s default StorageClass and persists data across pod restarts.

1. Get the current Helm values for the management release.

   helm get values solo-management -n solo-enterprise -o yaml > management.yaml
   open management.yaml

2. In your management chart values file, set clickhouse.persistentVolume.enabled to true. The PVC is created automatically using your cluster’s default StorageClass with a 20Gi request. To change the size or use a specific StorageClass, set clickhouse.persistentVolume.size and clickhouse.persistentVolume.storageClass.

   clickhouse:
     persistentVolume:
       enabled: true
       size: 20Gi                 # optional: override default size
       storageClass: ""           # optional: override default StorageClass

3. Apply the change by upgrading your chart release.

   helm upgrade solo-management \
     oci://us-docker.pkg.dev/solo-public/solo-enterprise-helm/charts/management \
     --namespace solo-enterprise \
     --version ${SOLO_UI_VERSION} \
     -f management.yaml

4. Verify that the PVC is bound before the ClickHouse pod restarts.

   kubectl get pvc -n solo-enterprise

   The PVC status must be Bound. If it remains Pending, check that your cluster has a default StorageClass or that the class you specified exists.

Option 2: Use an external ClickHouse instance

Replace the bundled ClickHouse instance with an external instance that you manage independently. An external instance gives you full control over storage, replication, backup schedules, and upgrades. For steps, see ClickHouse data store.

UI pod availability

The solo-enterprise-ui pod runs as a single replica. If the pod crashes or the node fails, Kubernetes restarts it automatically.

Because the Solo UI is an observability layer, the Istio service mesh control and data planes continue to operate normally regardless of whether the UI is available.

Telemetry resilience

For environments where continuous access to historical metrics is critical, configure your OTel collectors to export telemetry to your primary observability platform in addition to the Solo UI ClickHouse instance. If the UI cluster becomes unavailable, metrics remain accessible from your observability vendor. For configuration steps, see Metrics.