Navigate the dashboard.

1. Open it

$ clio_run start &

The runtime logs where the dashboard listens:

Viz: dashboard listening at http://127.0.0.1:8080

Open that address. The navigation bar has three tabs, Cluster, Pools and Config, and a connection indicator.

$ clio_run start --viz-port 9000 &

# On your laptop, then open http://127.0.0.1:8080 locally
$ ssh -L 8080:127.0.0.1:8080 user@node1

services:
  iowarp:
    image: iowarp/deploy-cpu:latest
    environment:
      - CLIO_VIZ_BIND=0.0.0.0
    ports:
      - "9413:9413"
      - "8080:8080"
    command: ["clio_run", "start"]

2. Cluster

The landing page shows one card per node, with its IP address, whether it is alive, and leader or this node badges. On a laptop there is a single card.

Below the cards, This node shows CPU and memory meters and a summary of worker tasks: how many are queued, blocked and processed. Click a node card to open its page. There you see utilization and a per-worker table with columns worker, active, queued, blocked, periodic, retry, processed, load and suspend µs.

• Tasks pile up in queued: the workers cannot keep up. Add worker threads in runtime settings.
• Many blocked tasks: work is waiting on I/O, often a slow tier.

3. Pools

Everything composed on this node, grouped by module. With the default configuration you see these groups:

• clio_admin, the runtime itself
• clio_bdev, the block devices: the default DRAM device and one per storage tier
• clio_cte_core, the storage engine
• clio_cte_cache, clio_cte_indexer and clio_cte_replication, the layers of the module chain
• clio_cte_stream, which keeps file sizes and orders appends
• clio_cae_core, for imports
• clio_cte_filesystem, which the FUSE mount drives

Click a card to open that pool's page:

The × in a card's corner destroys that pool, after you confirm. The admin pool cannot be destroyed, since it is the runtime itself.

4. Config

Key settings the daemon actually came up with, after the config file, environment variables and command-line flags were applied: ports, hostfile, worker counts, scheduler, dashboard address and loaded modules. It also lists every REST endpoint and which module registered it. Check here first when a setting seems to have no effect.

5. Watch real work

With the filesystem mounted, keep the dashboard open and copy something in:

$ cp -r ~/datasets/era5-sample ~/clio-mnt/

1. Cluster → This node: the processed count climbs and the worker meters move.

2. Pools → clio_cte_core: the RAM tier's free space drops, then the persistent disk tier's bytes written grows as replicas land.

3. Pools → clio_bdev: the block device's capacity meter fills.

6. Create a pool from the browser

1. On Pools, click Add Pool and choose clio_bdev.

2. Fill in the form: pool_name ram::scratch, keep the suggested pool_id, bdev_type ram, capacity 256MB.

3. Click Validate. Each field is checked, nothing is created, and errors come back per field.

4. Click Create. A new card appears under clio_bdev. Click it to watch the device.

Modules with a form (block devices, safe block devices, the CTE core) get typed fields. Other modules get a compose editor: identity fields plus a YAML box. Anything you could put in clio.yaml's compose section works there. S3 and GCS block devices are left out of the form, because they need credentials. Compose those from a file (see cloud storage).

Scripting the same data

Each page reads a small REST API that you can call yourself:

$ curl -s http://127.0.0.1:8080/api/health
$ curl -s http://127.0.0.1:8080/api/pools | python -m json.tool
$ curl -s http://127.0.0.1:8080/api/topology     # node ids for /api/nodes/{node}/...

Other routes include /api/config, /api/nodes/{node}/bdevs, /api/nodes/{node}/workers and /api/nodes/{node}/system_stats. To turn the dashboard off, use clio_run start --no-viz.