Enrich database metrics with tags

Expose Redis Enterprise database tags as metric labels so you can filter dashboards and alerts by attributes such as environment, team, or application.

Database tags are key-value attributes that you attach to your databases. You can expose selected tag keys as metric labels. Your monitoring stack can then filter and group metrics by those attributes. For example, you can build dashboards scoped to a team or environment and route alerts with context already attached.

Tag-derived metrics are controlled in two places:

• Cluster (REC): An administrator uses spec.metricsConfig on the Redis Enterprise cluster (REC) to turn tag-derived metrics on or off and choose which tag keys are eligible.
• Database (REDB / REAADB): Application teams set tag values on individual databases with spec.tags (REDB) or spec.globalConfigurations.tags (REAADB).

A tag becomes a metric label only when both of these are true:

• The tag key is in the cluster's allowlist.
• The tag is set with a value on the database.

Keys that aren't in the allowlist never appear as labels, even if they're set on a database.

How it works

1. On the REC, set metricsConfig.exposeDatabaseTags to true. In metricsConfig.metricsTagKeysExposed, list the tag keys you want available for metrics.
2. On each database, set the tag values with spec.tags (REDB) or spec.globalConfigurations.tags (REAADB).
3. The operator syncs the cluster configuration and the database tags to Redis Enterprise. Only keys in the allowlist that are present on a database appear as metric labels.

The REC defines the metrics configuration. The operator overwrites any changes made directly through the Redis Enterprise REST API.

Configure the cluster

Add metricsConfig to the REC spec to turn tag-derived metrics on and choose which tag keys are eligible:

apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseCluster
metadata:
  name: rec
spec:
  nodes: 3
  metricsConfig:
    exposeDatabaseTags: true
    metricsTagKeysExposed:
      - env
      - team

In this example, only the env and team tag keys can appear as metric labels. A tag such as app is not exposed even if it is set on a database, because it is not in the allowlist.

metricsConfig supports the following fields. All fields are optional. The operator applies the listed default when a field is unset.

Tag key allowlist entries (metricsTagKeysExposed) must follow these rules:

• Keys are lowercased on the cluster.
• Each key must be 1–64 characters and cannot be whitespace only.
• Keys may contain ASCII letters, digits, spaces, and the characters -, _, ., +, @, and :.
• Duplicate keys are rejected. The operator rejects the resource if the same key appears more than once, ignoring case.
• A maximum of 50 keys is allowed.

Tag a database

Set tags on a Redis Enterprise database (REDB) with spec.tags, a set of key-value pairs:

apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseDatabase
metadata:
  name: orders-cache
spec:
  memorySize: 1GB
  tags:
    env: prod
    team: payments
    app: orders-service

The operator merges these tags into the database's tags on the cluster. With the cluster configuration shown above, only env and team can appear as metric labels. The app tag is stored on the database but not exposed in metrics.

spec.tags is optional. For details on how tags are merged, updated, and removed, see Managed tags and deletion behavior.

Tag an Active-Active database

For an Active-Active database (REAADB), set tags under spec.globalConfigurations.tags, also a set of key-value pairs:

apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseActiveActiveDatabase
metadata:
  name: orders-aa
spec:
  globalConfigurations:
    tags:
      env: prod
      team: payments

The operator applies these tags to the Active-Active database's default configuration and to every participating cluster's instance. The cluster-level allowlist still applies. Configure metricsConfig on each participating REC to add the tag keys you want exposed to the allowlist.

Managed tags and deletion behavior

The operator tracks the tag keys it manages for each database. This lets it apply changes, including deletions, without disturbing tags set outside Kubernetes.

• External tags are preserved. Tags that exist on the database but were never declared in spec.tags (or spec.globalConfigurations.tags) are left in place.
• The custom resource wins on collision. If a key exists both on the database and in the custom resource, the operator applies the value from the custom resource.
• status.managedTags records what the operator owns. After a successful sync, the operator records the tag keys it applied in status.managedTags. This record lets it tell a key you removed apart from a key it never managed.
• Removing a key deletes it. If you remove a key that was recorded in status.managedTags, the operator removes that tag from the database on the next reconciliation. Keys that were never in status.managedTags, such as tags set only through the Redis Enterprise REST API, aren't deleted.
• Reserved keys are rejected. Keys the operator reserves for its own internal use cannot be set in the spec. For REDB, these are managed_by, redb_name, redb_namespace, db_service_port, and oss_cluster_access. For REAADB, they also include redb_resource, redb_resource_name, global_configurations_spec, replication_endpoint_port, rerc_name, and the operator's internal secret-tracking keys (redis.io/db-sec-name, redis.io/db-sec-latest, redis.io/certs-latest, redis.io/bu-sec-name, and redis.io/bu-sec-latest). The admission controller rejects a custom resource that uses one.

View tagged metrics in Prometheus

For instructions on connecting Prometheus to Redis Enterprise for Kubernetes, see Export metrics to Prometheus.

Limitations

• Allowlist size. The cluster allows at most 50 tag keys in metricsTagKeysExposed. The operator doesn't cap the list itself; the cluster enforces the limit. Keep the allowlist small: each exposed key adds a label dimension to the affected metrics, which increases cardinality in your monitoring stack.
• When changes take effect. Changes to metricsConfig, spec.tags, and spec.globalConfigurations.tags apply on the operator's next reconciliation of the resource. No pod or cluster restart is required. Exposed tag labels appear in metrics on the next scrape after the cluster applies the change.