One executable that serves, and prints information.
The executable is vaas-server; in the container image it is installed as vaas, and the image's default command is serve. Settings come from environment variables and an optional file, never from command flags. The informational commands work on any machine, so run them in the running container to see the deployed build.
openapi prints the API description as JSON. legal lists the third-party components in the binary, and --full adds their notice texts. There is no command that acts as a relay peer, and no administrative command for data: the session list is the administration interface.
Reachability first, then a credential.
Health needs no credentials and shows only that the process runs and its TLS port answers. It does not test credentials, the account-access setting or the database, so follow it with the session list.
| Observation | What it establishes |
|---|---|
200 with "status":"ok" | The process runs and the TLS port answers |
version and commit | The running release and build, or unknown |
| TLS failure | Check hostname, port, path prefix, trust file and identity file |
| Connection refused or timeout | The relay is down, or a firewall or route blocks the port |
503 on protected requests only | The account-access setting is missing or unreachable |
With a path prefix, health answers at <prefix>/health.
Capacity and failure trends from metrics, single events from logs.
The metrics listener runs on VAAS_METRICS_PORT (9090). Keep the metrics listener on a private network and never expose it to peers. Publish it only to a private address, for example -p 127.0.0.1:9090:9090.
| Metric | What to watch |
|---|---|
vaas_sessions_active by state | Sessions in the waiting and active states |
vaas_connect_attempts_total by outcome | success, and refusals such as limit_reached_cn, limit_reached_total, invalid_token, join_error, join_timeout, timeout, cancelled |
vaas_auth_failures_total by reason | Connections refused by the credential or feature check |
vaas_session_duration_seconds | How long relays last |
audit_row_count, audit_row_age_seconds | Size and age of the session record; the age should stay below VAAS_RETENTION_DAYS |
audit_retention_purge_failures_total | Failed purges; should stay at 0 |
session_events_daily and related series | Session totals for the latest completed UTC day, without account identifiers; daily_aggregate_snapshot_initialized is 0 until the first refresh after start |
vaas_request_latency_latest_recorded_day_* | Response-time distribution of the latest completed UTC day for the session and mesh API, by route, method and status class; vaas_request_latency_snapshot_refresh_success 0 means the previous day's figures are shown |
vaas_latency_metric_write_failures_total | Response times that could not be recorded; should stay at 0 |
Rising limit_reached_* outcomes mean waiting capacity is full. Rising timeout outcomes mean first applications wait without a partner. Logs go to the container log: docker logs --tail 100 vaas-server or kubectl -n vaas logs deploy/vaas-server --tail 100. Set MAIT_LOG_FORMAT=json for log collectors. The daily figures cover completed days only, so a new relay shows none until its first full UTC day has passed. Logs identify the account and never contain payloads; treat them as private.
Seven days by default, purged automatically.
The relay deletes session records older than VAAS_RETENTION_DAYS every hour; on Kubernetes the chart also schedules a daily clean-up. Keep VAAS_RETENTION_DAYS above 2 so daily totals can be completed. Tokens and payloads are never stored. Deleting the data directory removes the history.
What an interruption costs, what to keep, what to delete.
Every restart or upgrade ends all relays; see Upgrade or move the relay. A rollback to an earlier release can start on a database that a newer version has upgraded. The only state worth backing up is the data directory, which holds the session record; copy it while the relay is stopped. Copy the identity file separately, and keep it readable only by the service user.
To remove a container installation, run docker rm -f vaas-server, then delete /srv/vaas/data, and delete the identity file and environment file if nothing else uses them. On Kubernetes, run helm uninstall vaas-server -n vaas, then delete the volume claim and the vaas-server-tls secret. Uninstalling stops the relay but keeps the volume and the secret until you delete them.
Find the last stage that worked.
| Symptom | Action |
|---|---|
| Exits at startup naming the identity file | Mount the complete identity file at /etc/vaas/tls/tls.crt; on Kubernetes check the secret has the key tls.crt |
| Exits naming the database | Make the data directory writable by the service user and check free space |
Health works, everything else answers 503 | Check the account-access setting and its reachability, including DNS and network policies |
Docker reports unhealthy | Start the container with --no-healthcheck as in Install and check health from a client machine |
| Applications never pair | Same account, same fresh token, this relay; see Troubleshooting |
When you report a problem, record the time, hostname, operation, status, relay version and the last stage that worked. Leave out credentials files, tokens and payloads.