---
title: OpenTelemetry resources in New Relic
source: https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-best-practices-resources
---

All data from OpenTelemetry is associated with a [resource](https://opentelemetry.io/docs/concepts/resources).
A resource is a representation of the entity producing telemetry as resource
attributes. The resource attributes are used to adapt a resource to New Relic's
notion of an [entity](https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/core-concepts/what-entity-new-relic).

Data received is associated with an entity through a process called [entity synthesis](https://docs.newrelic.com/docs/entities/synthesis/)
whereby the resource attributes present are matched to rules which determine the type of entity the
data will be associated with. For data sourced from OpenTelemetry, the entity synthesis rules are
designed to respect the OpenTelemetry [resource semantic conventions](https://opentelemetry.io/docs/specs/semconv/resource).

The resource semantic conventions define different bodies of conventions for
describing different types of entities. For example, the
[service](https://opentelemetry.io/docs/specs/semconv/resource/#service) and
[host](https://opentelemetry.io/docs/specs/semconv/resource/host/)
conventions define the resource attributes which describe a service or host instance,
respectively.

## Supported entity types [#supported-entity-types]

Described here are the New Relic entity types which are supported when using
OpenTelemetry instrumentation. Included for each supported entity type are:

-   The resource attributes required for entity synthesis.
-   Recommended attributes that drive certain aspects of the New Relic UI.
-   Attributes which become [entity tags](https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/core-concepts/use-tags-help-organize-find-your-data/),
    when present.

### Services [#services]

A service entity is synthesized by adhering to the OpenTelemetry resource
semantic conventions describing a
[service instance](https://opentelemetry.io/docs/specs/semconv/resource/#service).

Refer to our
[documentation and examples](https://docs.newrelic.com/docs/opentelemetry/get-started/apm-monitoring/opentelemetry-apm-intro)
for monitoring service entities using OpenTelemetry.

#### Required attributes [#service-required-attributes]

-   [`service.name`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/service): The service name you see in the UI comes from this value.

#### Recommended attributes [#service-recommended-attributes]

-   [`service.instance.id`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/service): Enables faceting between multiple instances of the same service.
-   [`telemetry.sdk.language`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/telemetry): When present, this value drives the display of any runtime-specific UI, such as the JVM runtime page for Java applications.

#### Entity tags [#service-entity-tags]

-   [`service.namespace`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/service)
-   [`telemetry.sdk.language`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/telemetry) (added as language tag)
-   [`telemetry.sdk.version`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/telemetry)
-   [`k8s.cluster.name`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/k8s)
-   [`k8s.namespace.name`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/k8s)
-   [`k8s.deployment.name`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/k8s)

### Hosts [#hosts]

A host entity is synthesized by adhering to the OpenTelemetry resource semantic
conventions describing a [host](https://opentelemetry.io/docs/specs/semconv/resource/host).

Refer to the host monitoring example in [collector for infrastructure monitoring](https://docs.newrelic.com/docs/opentelemetry/get-started/collector-infra-monitoring/opentelemetry-collector-infra-intro/) for more details.

#### Required attributes [#host-required-attributes]

-   [`host.name`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/host): The host name you see in the UI comes from this value.
-   [`host.id`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/host)

#### Entity tags [#host-entity-tags]

-   [`cloud.provider`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/cloud)
-   [`cloud.account.id`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/cloud)
-   [`cloud.region`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/cloud)
-   [`cloud.availability_zone`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/cloud)
-   [`cloud.platform`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/cloud)
-   [`host.id`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/host)
-   [`host.name`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/host)
-   [`host.type`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/host)
-   [`host.arch`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/host)
-   [`host.image.name`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/host)
-   [`host.image.id`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/host)
-   [`host.image.version`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/host)

### Redis instances [#redis]

A redis instance is synthesized using data emitted from the Collector [Redis receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/redisreceiver). Unfortunately, there are currently no semantic conventions for Redis instances, or identifying attributes in the metrics the Redis receiver emits. Therefore, users are required to manually include the attributes described below.

Refer to the Redis example in [collector for infrastructure monitoring](https://docs.newrelic.com/docs/opentelemetry/get-started/collector-infra-monitoring/opentelemetry-collector-infra-intro/) for more details.

#### Required attributes [#redis-required-attributes]

-   [`server.address`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/server/): The redis instance name you see in the UI comes from this value.
-   [`server.port`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/server/)

#### Entity tags [#redis-entity-tags]

-   `redis.version`
-   `redis.role`
-   [`host.type`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/host)
-   [`cloud.provider`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/cloud)
-   [`cloud.account.id`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/cloud)
-   [`cloud.region`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/cloud)
-   `instrumenation.name`
-   [`server.address`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/server/)
-   [`server.port`](https://opentelemetry.io/docs/specs/semconv/attributes-registry/server/)

## Supported entity relationships [#supported-entity-relationships]

New Relic supports relationships between entities sourced from
OpenTelemetry instrumentation. These relationships are synthesized
automatically when the appropriate relationship criteria is met. Below are the
relationships that are currently supported and their required criteria.

### Service to infrastructure relationships using the OpenTelemetry Collector [#service-to-infra-otel-collector]

The OpenTelemetry Collector can be used to
[monitor your infrastructure](https://docs.newrelic.com/docs/opentelemetry/get-started/collector-infra-monitoring/opentelemetry-collector-infra-intro).
Entity relationships are supported between OpenTelemetry instrumented services
the infrastructure entities created from the OpenTelemetry Collector.

The following relationships to your services are supported:

-   [Hosts](#service-to-host)
-   [Containers](#service-to-container)

#### Hosts [#service-to-host]

Relationships between a service and host entity require that the service
includes the `host.id` resource attribute and that it matches the `host.id` of
the host it is running on.

#### Containers [#service-to-container]

Relationships between a service and container entity have different
requirements depending on whether your services are running in a Kubernetes
environment or not.

##### Kubernetes

In a Kubernetes environment the service must include the following resource
attributes in the telemetry it emits: `k8s.cluster.name`, `k8s.namespace.name`,
`k8s.pod.name`, and `k8s.container.name`. These attributes are commonly added
using the OpenTelemetry Collector configured with the
[Kubernetes Attributes Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/k8sattributesprocessor/README.md).

##### Non-Kubernetes environments

For non-Kubernetes environments the service must include the `container.id`
resource attribute and it must match the `container.id` of the container it is
running in.

### Service to infrastructure relationships using the New Relic infrastructure agent [#service-to-infra-nr-infra-agent]

The [New Relic infrastructure agent](https://docs.newrelic.com/docs/infrastructure/choose-infra-install-method)
can be used to monitor your infrastructure. Entity relationships are supported
between OpenTelemetry instrumented services and infrastructure entities created
from the New Relic infrastructure agent.

For these relationships to work, the telemetry emitted from your service must
be configured so that it can be correlated with the telemetry emitted by the
infrastructure agent. This requires the telemetry of your service to include
resource attributes that identify the host, container, etc that the service is
running on. This is usually as easy as configuring [resource detectors](https://opentelemetry.io/docs/concepts/resources/#resource-detectors)
provided by the OpenTelemetry SDK for your language or using the OpenTelemetry
Collector's [resource detection processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/README.md).

The following relationships to your services are supported:

-   [Hosts](#service-to-infra-nr-infra-agent-hosts)
-   [Containers](#service-to-infra-nr-infra-agent-containers)

#### Hosts monitored with the New Relic infrastructure agent [#service-to-infra-nr-infra-agent-hosts]

Host relationships between OpenTelemetry instrumented services and host
entities generated from the New Relic infrastructure agent require two things:

-   The `host.id` resource attribute must be present on the telemetry from the
    service.
-   The `host.id` must correlate with the [host's identity](#service-to-infra-nr-infra-derive-host-identity)
    derived by the infrastructure agent.

##### Deriving host identity [#service-to-infra-nr-infra-derive-host-identity]

> #### ⚠️ IMPORTANT
>
> The host identity derived by the New Relic infrastructure agent does not
> exactly match the semantics of OpenTelemetry's `host.id` resource attribute
> in all circumstances. This can cause difficulties in correlating services to
> hosts monitored with the infrastructure agent. Read this section carefully to
> understand potential challenges.

The host identity derived by the New Relic infrastructure agent depends on
hosting environment and agent configuration.

For services to be properly correlated to hosts monitored by the New Relic
infrastructure agent, the `host.id` resource attribute emitted by the service
must match the host identity computed by the agent. The following sections
describe, in priority order, how the infrastructure agent computes a host's
identity so that you can understand how to properly set the service's
`host.id`.

###### Infrastructure agent configured with a `display_name` [#service-to-infra-nr-infra-display-name]

If the infrastructure agent is configured to use a [`display_name`](https://docs.newrelic.com/docs/infrastructure/infrastructure-agent/configuration/infrastructure-agent-configuration-settings/#display-name)
then it will use that as the host's identity. Your OpenTelemetry instrumented
service must be configured to emit a `host.id` that is equal to the
`display_name`.

###### Host running in a cloud environment [#service-to-infra-nr-infra-cloud-environment]

If the host is running in a cloud environment (e.g., AWS or Azure) then the
agent will use the instance ID assigned by the cloud provider. Your
OpenTelemetry instrumented service should be configured to use a resource
detector appropriate for your cloud environment.

###### Host running in a non-cloud environment [#service-to-infra-nr-infra-non-cloud]

In non-containerized environments the infrastructure agent computes a
fully-qualified domain name (FQDN) of the host. How the agent determines the
FQDN differs based on a variety of factors such as the operating system.
Resource detectors cannot be relied on to compute the same value as the FQDN
resolved by the infrastructure agent. It is recommended that you explicitly
configure a `display_name` for the infrastructure agent and the `host.id` of
your service so that they match.

#### Service to containers monitored with the New Relic infrastructure agent [#service-to-infra-nr-infra-agent-containers]

Relationships between a service and container entity require that the service
be configured with an appropriate resource detector that includes the
`container.id` resource attribute.

### Amazon CloudWatch Metric Streams

Your infrastructure hosted in AWS can be monitored with New Relic's integration
with [Amazon CloudWatch Metric Streams](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integration-for-metrics/via-cloudformation-cwms/). This is not
an OpenTelemetry solution for monitoring your infrastructure. However, New
Relic supports a number of relationships between OpenTelemetry instrumented
services and infrastructure monitored using Amazon CloudWatch Metric Streams.
The supported relationships are listed below.

> #### ⚠️ IMPORTANT
>
> Some relationships are automatically supported by instrumentation. These relationships utilize OpenTelemetry semantic conventions to correlate telemetry from services instrumented with OpenTelemetry to AWS resources monitored by CloudWatch Metric Streams. However, be aware that many of these conventions are not yet stable and are still evolving.
> Instrumentation that produces telemetry for the frameworks below vary in
> their level of maturity and conformance to the semantic conventions. As
> such, the instrumentation you use may not emit the attributes required for
> these relationships to work. Please reach out to the maintainers of the
> instrumentation you're using with any questions about the instrumentation's
> maturity with respect to OpenTelemetry's semantic conventions.
>
> If a relationship is not automatically supported by instrumentation, or if the existing instrumentation does not follow standard conventions, you must manually transmit telemetry to New Relic to establish the relationship. Do this by transmitting a log or span with the attribute `newrelic.aws_metric_streams.arn` that includes the [ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) of the resource. Transmitting logs is recommended over spans because spans may be sampled. Keep in mind that these relationships have a 75-minute time-to-live (TTL), so you need to emit telemetry periodically to maintain the relationship.

| Supported by instrumentation | AWS product                                                                                                                                                       |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|                              | [DynamoDB](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-dynamodb-monitoring-integration)                           |
| ✅                            | [ElastiCache](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-elasticache-monitoring-integration)                     |
| ✅                            | [ElasticSearch](https://docs.newrelic.com/docs/infrastructure/host-integrations/host-integrations-list/elasticsearch/elasticsearch-integration)                   |
|                              | [Kinesis Data Firehose](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-kinesis-data-firehose-monitoring-integration) |
|                              | [Kinesis Data Streams](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-kinesis-data-streams-monitoring-integration)   |
|                              | [Lambda](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-lambda-monitoring-integration)                               |
| ✅                            | [MQ](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-mq-integration)                                                  |
| ✅                            | [MSK](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-managed-kafka-msk-integration)                                  |
|                              | [SQS](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/amazon-sqs-monitoring-integration)                                  |

## Adding custom tags to an entity [#tags]

You can use tags to organize and filter your entities in the UI.
[Tags](https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/core-concepts/use-tags-help-organize-find-your-data/)
are key-value pairs, for example `team: operations`, added to various sets of
data, like monitored apps and hosts. Certain important attributes are
automatically available as tags, such as account ID; you can also add your own
custom tags
[directly in the UI](https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/core-concepts/use-tags-help-organize-find-your-data/#add-tags),
or with one of the methods below.

Adding resource attributes prefixed with `tags` will result in a tag on your
entity in New Relic. For example, adding the attribute `tags.mytag=myvalue`
will result in the entity tag `mytag=myvalue`.