Database credentials

Database monitoring connects as a monitoring user, so the agent needs that user’s password. You can keep the password on the host and out of KloudMate, or type it into the wizard. Monitoring from eBPF and application traces needs no credentials. For the general flow, see the Database monitoring overview.

Choose how to provide the password

The Password field in the wizard has two modes. MongoDB Atlas uses the same two modes for its Atlas private key.

Environment variable (default)

The agent reads the password from an environment variable on its host. KloudMate stores only the variable’s name, so the password never leaves the host. Use this mode in production.

The field shows the variable to create. The agent handles escaping, so passwords containing @, :, /, ?, #, or spaces work without encoding.

Enter value

You type the password into the wizard, and it’s written into the agent’s configuration in plain text. Use this only for testing.

When you edit a database with an entered password, the field shows it masked. Leave it empty to keep the stored password, or type a new one to replace it. A stored password can be replaced but not cleared, so switch to Environment variable to remove it.

How variable names are built

The variable name is KM_SECRET_, then the instance name or, without one, the engine, then the field name. It’s uppercased, and any character other than a letter, digit, or underscore becomes _.

Instance name	Engine	Variable
(none)	PostgreSQL	KM_SECRET_POSTGRESQL_PASSWORD
Orders DB	PostgreSQL	KM_SECRET_ORDERS_DB_PASSWORD
(none)	MongoDB Atlas	KM_SECRET_MONGODBATLAS_PRIVATE_KEY

Set the Instance name before you create the variable, because it changes the name. Once a database is saved, renaming it keeps the variable it already uses.

Caution

Two databases on one agent that produce the same variable name share one password, and the wizard warns you when that happens. This happens with two unnamed databases of the same engine, or names such as DB 1 and DB-1. Give each database a distinct instance name to keep their passwords separate.

Databases saved before this naming scheme may use an older variable such as KM_SECRET_postgresql. It keeps working.

Set the variable on a host

The agent must see the variable in its own environment, not only in your shell.

• Linux (systemd): add KM_SECRET_POSTGRESQL_PASSWORD=YOUR_PASSWORD to an EnvironmentFile referenced by the agent’s service, or to a drop-in with Environment=, then restart the agent. This also suits a password written by an external secret manager.
• Windows: set it as a system environment variable, then restart the KloudMate Agent service.
• Docker: pass it to the agent container with -e or an env file.
• Kubernetes: put it in a Kubernetes Secret and set dbMonitoring.secretName. See Database monitoring on Kubernetes.

Rotate a password

With Environment variable, change the password on the database, update the variable, and restart the agent, or the collector pod on Kubernetes. The configuration in KloudMate doesn’t change.

With Enter value, change the password on the database, then edit the database in the wizard and type the new password.

Passwords in Advanced overrides

The Advanced YAML override has no secret storage. Anything you type there, including a password, is written into the agent configuration in plain text. Keep credentials in the Password field.

Grants

Whichever mode you use, the monitoring user needs the grants for the coverages you turn on. The wizard shows them under Setup required, and each engine’s page lists them. The agent doesn’t test the password or grants when you save. A mistake shows up as errors in the agent log and empty tabs in the Databases module. See Engines and coverages.

Next steps

On a VM Set up monitoring on a host.

On Kubernetes Set up monitoring in a cluster.

Configuration model How integrations fit the managed config model.