rqlite puts runtime counters in the interactive CLI

An interactive database session can answer a SQL question without explaining the process that served it. rqlite exposes both database status and Go runtime diagnostics, but those are different views of a node. Version 4.1.0, released on 3 September, adds .expvar to the CLI and includes previously missing store configuration in diagnostic output.

The tagged changelog identifies four changes. Alongside CLI expvar access and store parameters, the release makes consistency-level values case-insensitive and adds endpoint tests. The common practical benefit is a more accurate view of the request and node configuration around SQL execution.

I value this in rqlite because a compact service still needs operational explanations. A single executable can be easy to start while retaining several sources of state, including the local database, Raft and the Go process. Putting their existing diagnostics within reach of the interactive client reduces the need to leave the session to inspect the node.

Expvar is a separate endpoint

The release's diagnostics guide describes /debug/vars as exposing standard expvar information together with custom counters. Its example includes command-line arguments, database execution counters, HTTP request counters and Go memory statistics.

curl http://localhost:4001/debug/vars

The equivalent interactive command is .expvar. This is a client command that fetches the diagnostic endpoint, rather than SQL sent to SQLite. A successful data query and a successful diagnostic fetch therefore establish different things about a node.

The example counters include executions, execution errors, queries and transaction counts at the database layer. The HTTP section separately counts API operations. Those names identify different points in request processing. They should not be assumed to be interchangeable measurements simply because both sections concern queries and execution.

Memory statistics likewise describe the Go process, not a SQL table. Values such as heap storage and stack usage help characterize runtime allocation. They do not directly report the number of application rows or the durability of a committed command. The diagnostic object places these observations together while retaining their separate sections.

The client reuses its JSON printer

The released CLI implementation builds the expvar URL from the configured scheme, host and port, then calls the same JSON display helper used by .status. The helper performs a GET, decodes the object and recursively prints nested maps with indentation.

That reuse explains why the two commands have a similar presentation without implying that they retrieve the same information. .status addresses /status, while .expvar addresses /debug/vars. The server remains responsible for the contents of each response.

The helper can also select a top-level key from the entered command. For example, .expvar memstats chooses that section from the decoded response before printing it. The implementation performs this selection in the client after retrieving the JSON object. It is not a server-side query that asks expvar to calculate a different subset of metrics.

The recursive printer skips null values and prints scalar values directly. Its formatting makes nested information readable in a terminal, but it does not add aggregation or historical storage. Repeating the command obtains another response from the node. A monitoring history would require something to collect those responses over time.

Status reports more effective configuration

The store-diagnostics patch adds open_timeout, heartbeat_timeout and snapshot_threshold to the existing store status. The Apply timeout was already present. These fields expose settings that govern distinct store operations.

The open timeout concerns initial log application during startup. Heartbeat configuration concerns Raft timing. The snapshot threshold is the configured log-entry threshold for snapshotting. Returning them in status lets an operator inspect assigned values instead of inferring them from a launch command that may not describe the running process. These values accompany the node address, leader information and database configuration already present in the store response.

I find effective configuration especially useful when several timeout names exist. Seeing the Apply and open values together does not make them the same deadline. It makes their independent settings visible in the same diagnostic object, where a caller can compare them with the behavior being investigated.

Consistency names tolerate letter case

The consistency-parameter patch lowercases the trimmed level value before matching it. Inputs such as strong and STRONG therefore select the same recognized level. The change concerns parameter parsing, not a new consistency guarantee.

The release also adds unit-test coverage for status and expvar endpoints. That accompanies the larger diagnostic interface without changing the basic division between SQL results and node information. The CLI now offers both views, and the status object includes more of the configuration that controls the store supplying those results.