Web console
Clustron Zaris ships with a web console — a browser UI for operating a cluster without living in the terminal. It is the fastest way to see what your cluster is doing: which nodes hold which partitions, how each node is performing, and whether security is on.
The console is a service that answers on port 7810, alongside the manager's management API on 7801. In container setups you map it to whatever host port you like. It talks to the cluster through the same control-plane management API the CLI uses, so everything you see in the console has an equivalent cmdlet.
Connecting: workspaces
The console organizes access around a workspace — a named binding to a cluster's manager or managers. You connect to (or create) a workspace, and from then on every screen is scoped to that cluster. A manager belongs to one workspace, which keeps a single coherent identity for the cluster you are operating. In supervisor mode a workspace holds the roster of per-machine managers; scaling adds or removes managers from that roster.
The console reads the cluster's deployment model from the manager's /health endpoint and shows whether it is running in supervisor or attach mode, so mode-dependent behavior is never a surprise. In attach mode, actions that would reconfigure a running node are disabled, because an observer manager cannot push changes to nodes the orchestrator owns.
Once security is enabled, the console requires a sign-in: opening it in a fresh browser session presents a login page, and you enter the username and password of an identity created with New-ZrUser (or the bootstrap admin). Credentials authenticate operators to the control plane — the same session an admin cmdlet gets from Connect-ZrManager -Credential.
What you can see and do
Each area of the console maps to a management-API capability.
| Area | What it gives you |
|---|---|
| Stores | Create stores (supervisor mode) or adopt orchestrator-defined stores (attach mode), start and stop them, and edit configuration. |
| Nodes | Every node with its role and state, and — by code word — the partitions it owns as primary versus holds as replica. |
| Partition map | A snapshot of partition-to-node ownership across the cluster, with under-replicated partitions flagged. |
| Metrics | Windowed time-series for requests, latency, and memory, with a per-node breakdown so an uneven load or a slow node stands out. |
| Security | Enable authentication and TLS, and (in supervisor mode) apply security and TLS to the nodes. |
| Servers | The machines behind the cluster, their reachability, and how many nodes each runs, plus scale-out and scale-in. |
Reading a cluster at a glance
A few things the console makes obvious that are otherwise hard to see:
- Partition code words. Partitions appear as stable words (
Amber,Onyx, …), so you can follow one partition as it moves between nodes during failover or rebalance. - Per-node performance. Metrics are broken out per node, so a hot spot or a lagging node is visible without correlating separate dashboards.
- Security posture. The security area shows whether tokens and TLS are enforced, and in attach mode makes clear that node security is declared in configuration rather than pushed at runtime.
Each area above maps to a confirmed control-plane management-API capability — stores and their lifecycle (/admin/v1/stores, instance start/stop, definition edits), nodes and roles (.../nodes, /admin/v1/nodes/roles), the partition map (.../diagnostics/partition-map), metrics (/admin/v1/metrics), security and TLS (/security, /security/tls), and servers (workspace binding and membership diagnostics).
Load generation and benchmarking are not console screens — they run through the client cmdlets (for example Benchmark-ZrStore, Test-ZrThroughput, Test-ZrLatency), which drive synthetic read/write traffic against a store and report throughput, latency percentiles, and error rate.
Next steps
- If the console cannot apply security to nodes, confirm you are in attach mode and see Security and TLS for the declarative pattern.
- Watch ownership shift as you scale in Elastic scaling.
- Return to the Architecture and operations overview.