Server logs describe the operation of the Stronghold process itself: startup, unsealing, Raft leader elections, plugin and connection errors. They do not replace audit logs, which record client requests.

Log levels

The level is set with the log_level parameter in the configuration file or the VAULT_LOG_LEVEL environment variable. Both are described in Configuration. Supported values in increasing verbosity:

LevelWhen to use
errorErrors only
warnErrors and warnings
infoDefault. Normal operation, including production
debugTroubleshooting, short-term
traceDetailed troubleshooting, short-term. Produces a large volume of records

In DP, log_level is not set in the module configuration, so the default level (info) is used. To raise it temporarily, use the /sys/loggers endpoint.

Do not keep debug and trace enabled for long: they increase log volume and disk load.

Log format

The log_format parameter accepts standard (default) and json. Use json to ship logs to a centralized logging system:

log_level  = "info"
log_format = "json"

A JSON record example:

{"@level":"info","@message":"attempting to join possible raft leader node","@module":"core","@timestamp":"2025-10-20T10:54:02.578963Z","leader_addr":"https://stronghold-0.stronghold-internal:8300"}

In DP, log_format = "json" is hard-coded in the module configuration.

To write logs to a file, set log_file and the rotation parameters log_rotate_duration, log_rotate_bytes, log_rotate_max_files.

Viewing logs

  • Stronghold in Linux
  • Stronghold in DP

When running as the stronghold.service systemd unit, logs go to journald:

journalctl -u stronghold.service -f

Logs for a specific period:

journalctl -u stronghold.service --since "1 hour ago"

Stronghold runs in the d8-stronghold namespace. To list the pods, run the following command:

d8 k -n d8-stronghold get pods -o wide

The stronghold-N pod has the stronghold container, the kube-rbac-proxy sidecar (metrics) and, if the plugins module parameter is set, the plugin-fetcher init container that downloads plugins. Specify the main container with -c:

d8 k -n d8-stronghold logs stronghold-0 -c stronghold -f

Logs of the previous container instance after a restart:

d8 k -n d8-stronghold logs stronghold-0 -c stronghold --previous

To get logs of the active node (for example, when diagnosing automatic snapshot failures), use the stronghold-active service:

d8 k -n d8-stronghold logs svc/stronghold-active -c stronghold

Changing the log level

Via the configuration file

  1. Change the log_level value in the configuration file.

  2. Send SIGHUP to the process:

    systemctl reload stronghold

    The command uses ExecReload=/bin/kill -HUP $MAINPID from the systemd unit. On SIGHUP, the log level is updated and CLI flags and environment variables are ignored. Not all subsystems (for example, plugins) support changing the level dynamically.

Via the API without a restart

The /sys/loggers endpoint changes the log level on a running node. The request applies to the node it is sent to.

Raise the level for all subsystems:

curl --header "X-Vault-Token: ${STRONGHOLD_TOKEN}" --request POST --data '{"level": "debug"}' "${STRONGHOLD_ADDR}/v1/sys/loggers"

Raise the level for a single subsystem (for example, core):

curl --header "X-Vault-Token: ${STRONGHOLD_TOKEN}" --request POST --data '{"level": "trace"}' "${STRONGHOLD_ADDR}/v1/sys/loggers/core"

Revert to the level from the configuration:

curl --header "X-Vault-Token: ${STRONGHOLD_TOKEN}" --request DELETE "${STRONGHOLD_ADDR}/v1/sys/loggers"

Subsystem names match the logger names in log lines (for example, core, expiration, raft, audit). GET /v1/sys/loggers returns the current list for a node.

Streaming logs

The d8 stronghold monitor command connects to the /sys/monitor endpoint and streams node logs in real time at the given level without changing the configuration:

d8 stronghold monitor -log-level=debug
←
Operations / Metrics catalog
Operations / Troubleshooting
→