WhoDBDocs

Observe a CE instance

Monitor WhoDB's availability separately from the databases it connects to. This lets you distinguish a stopped workspace from a running workspace that cannot reach one source.

Check the process#

Request GET /health. A running WhoDB server returns the plain text ok. Use this for process availability; it does not open every configured database or verify application records.

For a database-path check, use a representative low-cost read from the backend's network. For a CLI connection, whodb doctor --connection <name> --format json provides redacted diagnostics.

Collect useful logs#

VariablePurpose
WHODB_LOG_LEVELChoose logging verbosity
WHODB_LOG_FORMAT=jsonProduce structured log output
WHODB_LOG_FILESet the non-HTTP application log destination
WHODB_ACCESS_LOG_FILESet the HTTP access log destination
WHODB_AUDIT_LOG_FILEWrite append-only NDJSON for supported audited actions

Choose file paths writable by the WhoDB process. Use your deployment's logging system to collect and rotate them. Restrict access to logs because errors and operational context can contain sensitive information.

Different logs answer different questions. HTTP access logs show requests, application logs help diagnose failures, and the audit destination covers supported audited actions. Do not treat one as proof of every action performed directly against the database.

Investigate an alert#

Record the failing action, its time, selected source, and visible error. Check process health, then the source route, then authentication and query behavior. Correlate the relevant logs before changing settings.

For a slow operation, record result size and compare a small request on the same connection. See Performance tuning. For a failed operation, follow Troubleshooting and server configuration.

Was this page helpful?