---
title: Enhanced tags for New Relic database entities
source: https://docs.newrelic.com/docs/infrastructure/host-integrations/db-entity-tags
---

New Relic now provides richer, more customizable tags for your database entities monitored via on-host integrations for MySQL and Microsoft SQL Server. This enhancement allows you to gain deeper insights, improve filtering, and better organize your monitored database instances based on your specific operational needs.

Previously, database entities monitored through on-host integrations typically displayed only basic tags like `account`, `accountId`, and `trustedAccountId`. Now, you can add valuable context-rich tags such as `environment`, `owning_team`, `region`, `cell`, and any other custom metadata relevant to your setup, directly from your integration configurations.

## How tags are applied to database entities [#db-entity-tags]

Tags on your database entities are automatically generated from specific attributes found in your telemetry. You can directly influence these tags through your configuration files:

### From database integration configuration [#db-integration-config]

Any attribute defined within the labels section of your database integration's configuration file (for example, `mysql-config.yml` and `mssql-config.yml`) will automatically become a tag on the corresponding database entity.

Changes to these configuration files are automatically picked up and do not require a service restart of the New Relic infrastructure agent or the database service.

Example snippet for a database integration config file (for example, `mysql-config.yml`):

```yaml
# /etc/newrelic-infra/integrations.d/mysql-config.yml
integrations:
  - name: nri-mysql
    config:
      # ... other configuration ...
      labels:
        environment: production
        owning_team: database-admins
        cell: us-east-1a
        app_version: v2.5.0
```

### From infrastructure agent custom attributes [#infra-agent-custom-attrs]

Custom attributes defined in the `custom_attributes` section of your `newrelic-infra.yml` file can also become tags on all entities monitored by that specific infrastructure agent, including your database instances.

For an Infrastructure agent custom attribute to be converted into a tag on a database entity, its key must start with the prefix `label.`.

Changes to `newrelic-infra.yml` require a restart of the infrastructure agent to take effect.

Example `newrelic-infra.yml` snippet:

```yaml
# /etc/newrelic-infra.yml
# ... other configuration ...
custom_attributes:
  region: 'APAC'
  host_type: 'production-server'
  label.data_center: 'Mumbai-DR'
  label.deployment_tier: 'backend'
```

In this example, `data_center` and `deployment_tier` would appear as tags on your database entities, while `region` and `host_type` would remain as custom attributes on the host itself.

## Understanding tag behavior in New Relic [#tag-behavior]

It's important to understand how these telemetry-based tags behave in the New Relic UI:

-   **Tag latency:** Tags are not real-time telemetry. Due to caching in the ingest pipeline, it might take up to **5 minutes** for a newly added tag to appear in the UI.
-   **Updating tag values:** If you modify the value of an existing tag (for example, changing `environment: staging` to `environment: production`), the new tag value will be added. The old tag value will persist for a while until its Time To Live (TTL) of **4 hours** expires. This can temporarily create the appearance of duplicate tags in the UI until the old one is removed. However, at the telemetry level (for example, in NRQL queries), the updated tag value will overwrite the previous one, meaning there will only be one active value for that tag.
-   **Deleting tags:** If you remove a tag from your configuration, it will continue to show in the UI for up to **4 hours** due to its TTL.

> #### 💡 TIP
>
> If your APM Service map displays an uninstrumented database, it may be due to your application connecting via an intermediate endpoint such as load balancer or proxy rather than directly to the instrumented database instances. To address this, manually map the `endpoint` to your instrumented instances. Add an `endpoint` tag to each instrumented database instance, using the uninstrumented endpoint's address as the tag value.
>
> For example, if the uninstrumented entity is a load balancer at `db-lb.internal.example.com`, add the following tag to each backing database instance: `endpoint:db-lb.internal.example.com`

## Impact on your existing setup [#impact-on-existing-setup]

-   **No change to billing:** This update has no impact on your billing.
-   **No change to existing telemetry:** There is no difference to any other behavior, and no change to the existing telemetry you are already collecting. The primary effect is enriching the metadata associated with your entities in the UI.

By understanding these points, you can effectively customize and leverage enhanced tags to create a more organized and insightful monitoring experience for your database instances in New Relic.