OpenBao

Auto-Detection

Built-in Metrics

OpenBao is an open-source fork of HashiCorp Vault for secrets management. Its metrics are exposed through the same telemetry subsystem as Vault. If you run HashiCorp Vault instead, see the Vault page.

Auto-Detection

Glouton detects OpenBao by its process and listening port (default: 8200).

First, enable the Prometheus telemetry in your OpenBao configuration file (HCL format):

telemetry {
  prometheus_retention_time = "30s"
  disable_hostname = true
}

Restart OpenBao for the change to take effect. The metrics endpoint (/v1/sys/metrics) requires authentication, so you must provide a token that is allowed to read sys/metrics. Set it through the service configuration:

Linux

sudo tee /etc/glouton/conf.d/99-openbao.conf > /dev/null << 'EOF'
service:
  - type: "openbao"
    address: "127.0.0.1"
    port: 8200
    password: "<YOUR_OPENBAO_TOKEN>"
EOF

Windows

Create or edit C:\ProgramData\glouton\conf.d\99-openbao.conf:

service:
  - type: "openbao"
    address: "127.0.0.1"
    port: 8200
    password: "<YOUR_OPENBAO_TOKEN>"

To scrape a non-standard endpoint (for example when OpenBao is served over HTTPS or behind a different path), set stats_url to the full metrics URL instead of address and port.

Glouton automatically detects configuration changes.

Built-in Metrics

Metric	Description
service_status	Status of OpenBao
bao_core_unsealed	Whether the OpenBao node is unsealed (1) or sealed (0)
bao_core_active	Whether the OpenBao node is the active node in the cluster
bao_core_in_flight_requests	Number of requests currently being processed
bao_core_handle_requests	Rate of requests handled by the core
bao_core_handle_login_requests	Rate of login requests handled by the core
bao_core_check_tokens	Rate of token checks performed by the core
bao_core_leadership_losses	Number of times this node lost cluster leadership
bao_expire_num_leases	Number of currently active leases

Monitoring Troubleshooting

See Troubleshoot a Service Check or Missing Metrics for what applies to every service: finding the address and port Glouton really uses, what each check message means, and how to read the collection error — which does not appear in the agent logs at the default level.

The Service Check is not OK

The check only opens the TCP port — it sends no command — so it fails when the port is wrong (Connection refused), when a firewall drops the packets (connection timed out after 10 seconds), or when the configured address cannot be parsed (Invalid TCP address). A green check proves the port is open, and nothing more.

Metrics are Missing

A passing check says nothing about the metrics: they are collected separately.

Glouton reads the Prometheus telemetry endpoint /v1/sys/metrics, using the password from the service configuration as a token.

Reproduce what Glouton does, from the machine where the agent runs:

curl -i -H "X-Vault-Token: TOKEN" "http://127.0.0.1:8200/v1/sys/metrics?format=prometheus"

What you see	Cause	Fix
404	Telemetry is not enabled	Add the telemetry block with prometheus_retention_time and restart
403 permission denied	No token, or an expired one	Set password to a valid token
403 permission denied	The token’s policy does not allow sys/metrics	Grant read on sys/metrics to that policy
a TLS error	The API is served over HTTPS	Glouton builds an http:// URL from the detected address; set stats_url to the https:// URL
503	The server is sealed	Unseal it