feat(database): add mount point telemetry labels to database metrics

[vinanrra]

Description

AI usage disclosure: The code, tests, and this pull request description were generated with the assistance of an AI tool. All changes have been reviewed by me before submission, and the affected test suites build and pass.

Part of #32077.

What does this PR do?

Database secrets engine metrics are currently keyed only by the plugin type string (for example, PostgreSQL emits database.pgx.*). There is no way to break them down by the mount, the namespace, or the configured connection, so every connection of a given type across every mount and namespace collapses into a single time series. This makes it impossible to answer questions like "which mount is driving credential churn?" or "is connection orders-primary slower than reporting-replica?".

This PR adds opt-in namespace, mount_point, and connection_name labels to the database plugin metrics, gated behind a new telemetry configuration option. Labels (rather than metric-name segments) are used deliberately, so existing dashboards and queries keep working unchanged — the same approach and rationale as the existing add_mount_point_rollback_metrics option.

Summary of changes

• Add namespace, mount_point, and connection_name labels to database plugin metrics when the operator opts in via the new add_mount_point_database_metrics telemetry configuration.
• Introduce a metricsLabelsForConnection method on the backend to build telemetry labels from the mount context (returns no labels unless opted in).
• Thread labels through newDatabaseWrapperWithMetricsLabels (the existing newDatabaseWrapper signature is preserved as a thin wrapper for compatibility).
• Extend the databaseBackend struct with mountNamespace, mountPoint, and includeMountPointInMetrics fields, populated from logical.BackendConfig.
• Update the pluginInstances gauge collection to conditionally append namespace and mount_point labels, guarding against empty values.
• Update the plugin metrics middleware and plugin factory to propagate the labels (new additive PluginFactoryConfig + PluginFactoryWithConfig; PluginFactory/PluginFactoryVersion signatures unchanged).
• Add telemetry configuration plumbing (configutil.Telemetry → metricsutil.TelemetryConstConfig → Core → logical.BackendConfig) plus a config-parse test and fixture.
• Add test coverage in telemetry_labels_test.go that validates label emission against a real database backend and plugin process.

Operators can now correlate database plugin metrics across different mounts and namespaces for better observability.

Configuration

telemetry {
  add_mount_point_database_metrics = true
}

Behavior

Metric names are unchanged. Labels are added only when the option is enabled:

# default (option absent or false) — identical to today
database.pgx.Initialize

# with add_mount_point_database_metrics = true
database.pgx.Initialize;namespace=root;mount_point=db-prod/;connection_name=orders-primary

Affected series: the middleware operations (PluginVersion, Initialize, NewUser, UpdateUser, DeleteUser, Close) in both their database.<op> and database.<type>.<op> forms including the .error counters, plus the vault.secrets.database.backend.pluginInstances.count gauge.

Backward compatibility

• Off by default. When disabled, emission is byte-for-byte identical to previous behavior (IncrCounterWithLabels(key, val, nil) is defined as IncrCounter(key, val) in go-metrics).
• Public SDK function signatures (PluginFactory, PluginFactoryVersion) are unchanged; new inputs are added via an additive PluginFactoryConfig.
• New logical.BackendConfig fields (MountPath, MountNamespace, IncludeMountPointInMetrics) are additive and optional.

Testing

• Unit tests for the middleware verifying label presence, ordering (namespace, mount_point, connection_name), and that metric names are unchanged.
• A full-stack test that mounts the database secrets engine, registers a real postgresql-database-plugin process, creates a connection, and asserts the labels appear only when opted in and are absent by default.
• A telemetry config-parse test with fixture, an updated sanitized-config test, and a core mount-wiring test confirming the flag reaches BackendConfig.
• gofmt clean; both the root and sdk modules build; affected suites pass.

Known limitations / follow-ups

• The legacy v4 plugin path intentionally remains unlabeled (deprecated interface).
• Enterprise-only connection-creation files are not in this (CE) tree; they compile as-is but need the same one-line change to emit labels on Enterprise builds.
• The namespace label uses the telemetry-normalized value (root for the root namespace), consistent with other Vault per-mount metrics.

Related

• Part of database.{NAME}.* telemetry is keyed by plugin type, not by mount or connection name (docs inaccuracy + request for per-mount labels) #32077. This PR implements the feature-request portion — opt-in per-namespace / per-mount / per-connection telemetry labels for the database secrets engine.
• It intentionally does not Closes that issue: the documentation inaccuracy it also reports (the docs describe database.{NAME}.* as the named engine, when {NAME} is the plugin type — pgx for PostgreSQL) lives in hashicorp/web-unified-docs and needs a separate docs PR. Leaving the issue open tracks that remaining work.

TODO only if you're a HashiCorp employee

Not applicable — external/community contribution. Backport labeling and any Jira linkage are deferred to maintainers.

• Backport Labels: If this fix needs to be backported, use the appropriate backport/ label that matches the desired release branch.

  • LTS: If this fixes a critical security vulnerability or severity 1 bug, it will also need to be backported to the current LTS versions of Vault. To ensure this, use all available enterprise labels.

• Jira: If this change has an associated Jira, it's referenced either in the PR description, commit message, or branch name.

• RFC: If this change has an associated RFC, please link it in the description.

PCI review checklist

• I have documented a clear reason for, and description of, the change I am making.

• If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.

  Not applicable — the change is stateless (no storage, schema, or data migrations). Reverting the pull request fully reverts the behavior; with the option disabled, no metric output changes at all.

• If applicable, I've documented the impact of any changes to security controls.

  This change adds optional telemetry labels; it does not alter authentication, authorization, or any access-control path. When an operator explicitly enables add_mount_point_database_metrics, the mount path, namespace, and configured connection name become visible as metric labels wherever telemetry is already exposed (for example the sys/metrics endpoint or a configured sink). This is opt-in and off by default, metric names are unchanged, and time-series cardinality remains under operator control since it scales with the number of configured connections.

[vercel]

Deployment failed for project vault-ui with the following error:

The `vercel.json` schema validation failed with the following message: should NOT have additional property `public`

Learn More: https://vercel.com/docs/concepts/projects/project-configuration

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

---

vfernandezg seems not to be a GitHub user.
You need a GitHub account to be able to sign the CLA.
If you have already a GitHub account, please add the email address used for this commit to your account.

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

---

vfernandezg seems not to be a GitHub user.
You need a GitHub account to be able to sign the CLA.
If you have already a GitHub account, please add the email address used for this commit to your account.

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[vercel]

Deployment failed for project vault-ui with the following error:

The `vercel.json` schema validation failed with the following message: should NOT have additional property `public`

Learn More: https://vercel.com/docs/concepts/projects/project-configuration

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
vault-ui	Error		Aug 10, 2026 3:25pm

[vercel]

Deployment failed for project vault-ui with the following error:

The `vercel.json` schema validation failed with the following message: should NOT have additional property `public`

Learn More: https://vercel.com/docs/concepts/projects/project-configuration

[vercel]

Deployment failed for project vault-ui with the following error:

The `vercel.json` schema validation failed with the following message: should NOT have additional property `public`

Learn More: https://vercel.com/docs/concepts/projects/project-configuration