New Relic entity tags are a surprisingly flexible way to imbue your observability data with rich, contextual metadata that directly maps to your business and operational concerns.
Let’s see them in action. Imagine you have a Kubernetes cluster and you want to tag all entities within a specific namespace (prod-us-east-1) with ownership information and the primary service they belong to.
{
"name": "Kubernetes Integration",
"config": {
"prefix": "k8s",
"clusters": [
{
"name": "my-prod-cluster",
"region": "us-east-1",
"env": "production",
"namespaces": [
{
"name": "prod-us-east-1",
"tags": {
"owner": "backend-team-alpha",
"service": "user-auth",
"environment": "production",
"region": "us-east-1"
}
}
]
}
]
}
}
In this snippet, the tags object within the prod-us-east-1 namespace configuration is where the magic happens. When New Relic’s Kubernetes integration collects data from this namespace, it automatically applies these key-value pairs to every entity it discovers there – pods, deployments, services, and so on. This means your Kubernetes pods running in prod-us-east-1 will appear in New Relic with tags like owner: backend-team-alpha and service: user-auth.
This capability directly addresses the fundamental problem of identifying and attributing resources in complex, dynamic environments. Without tags, correlating a specific pod experiencing high latency back to the owning team or the business service it supports can be a manual, time-consuming investigative process. Tags make this immediate. You can then leverage these tags in New Relic to:
- Filter and Search: Quickly find all entities belonging to
backend-team-alphaor all components of theuser-authservice across different environments. - Create Dashboards: Build dashboards that aggregate metrics for a specific service or team, regardless of the underlying infrastructure.
- Set Up Alerts: Configure alerts that trigger only for entities tagged with
environment: productionandcriticality: high. - Attribute Costs: While not a direct New Relic feature for billing, this metadata can be exported and correlated with cloud provider billing data to understand cost allocation by service or team.
- Automate Workflows: Use tags as triggers for automated remediation or notification systems.
Internally, New Relic treats these tags as first-class attributes of your entities. They are indexed and made searchable across all your observability data – APM, Infrastructure, Browser, Mobile, and Synthetics. The integration agents and collectors are responsible for reading the tags from the source (like Kubernetes labels, AWS tags, or custom attributes) and sending them along with the telemetry data.
The actual implementation of tagging can vary. For Kubernetes, you can apply tags at the namespace level (as shown), or more granularly at the pod or deployment level using labels. For AWS, you can leverage CloudFormation or Terraform to define tags on your cloud resources, which the New Relic AWS integration then picks up. You can also apply custom tags directly within your APM agent configuration or through the New Relic API.
The real power comes from a consistent tagging strategy. Think about what metadata is most important for your organization to slice and dice observability data. Is it the team that owns the service? The business criticality? The compliance scope? The deployment environment? Establishing a convention for these tags and enforcing it across your infrastructure is key. For example, always using environment with values like development, staging, production, and never dev, stage, prod makes filtering reliable.
A common pitfall is the temptation to tag everything with arbitrary, ad-hoc values. While flexible, this can lead to tag sprawl and make querying difficult. Instead, define a controlled vocabulary for your most critical attributes. For instance, instead of allowing owner to be Alice, Bob, Charlie, establish team names like frontend-team, backend-team, data-engineering. This ensures that when you query for owner: frontend-team, you capture all relevant entities.
The service tag is particularly potent because it allows you to draw a direct line from infrastructure metrics to the business capabilities your systems provide. When a critical service like payment-processing shows degraded performance, you can instantly filter down to all its constituent parts, regardless of whether they are running on EC2 instances, in Kubernetes, or as Lambda functions, and see their individual health and resource utilization.
Once you’ve established your tagging strategy and applied it, the next step is often to explore how these tags integrate with alerting policies to proactively notify the right people.