OpenTelemetry resources in New Relic

All data from OpenTelemetry is associated with a resource. 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.

Data received is associated with an entity through a process called entity 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.

The resource semantic conventions define different bodies of conventions for describing different types of entities. For example, the service and host conventions define the resource attributes which describe a service or host instance, respectively.

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, when present.

Services

A service entity is synthesized by adhering to the OpenTelemetry resource semantic conventions describing a service instance.

Refer to our documentation and examples for monitoring service entities using OpenTelemetry.

Required attributes

• service.name: The service name you see in the UI comes from this value.

Recommended attributes

• service.instance.id: Enables faceting between multiple instances of the same service.
• telemetry.sdk.language: When present, this value drives the display of any runtime-specific UI, such as the JVM runtime page for Java applications.

Entity tags

• service.namespace
• telemetry.sdk.language (added as language tag)
• telemetry.sdk.version
• k8s.cluster.name
• k8s.namespace.name
• k8s.deployment.name

Hosts

A host entity is synthesized by adhering to the OpenTelemetry resource semantic conventions describing a host.

Refer to the host monitoring example in collector for infrastructure monitoring for more details.

Required attributes

• host.name: The host name you see in the UI comes from this value.
• host.id

Entity tags

• cloud.provider
• cloud.account.id
• cloud.region
• cloud.availability_zone
• cloud.platform
• host.id
• host.name
• host.type
• host.arch
• host.image.name
• host.image.id
• host.image.version

Redis instances

A redis instance is synthesized using data emitted from the Collector Redis receiver. 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 for more details.

Required attributes

• server.address: The redis instance name you see in the UI comes from this value.
• server.port

Entity tags

• redis.version
• redis.role
• host.type
• cloud.provider
• cloud.account.id
• cloud.region
• instrumenation.name
• server.address
• server.port

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

The OpenTelemetry Collector can be used to monitor your infrastructure. 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
• Containers

Hosts

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

Relationships between a service and container entity require that the service includes the container.id resource attribute and that it matches the container.id of the container it is running in.

Service to infrastructure relationships using the New Relic infrastructure agent

The New Relic infrastructure agent 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 provided by the OpenTelemetry SDK for your language or using the OpenTelemetry Collector's resource detection processor.

The following relationships to your services are supported:

• Hosts
• Containers

Hosts monitored with the New Relic infrastructure agent

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 derived by the infrastructure agent.

Deriving host identity

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

If the infrastructure agent is configured to use a 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

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

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

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. 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.

ElastiCache (Memcached)

The Amazon CloudWatch Metric Streams integration for Elasticache generates ElastiCache entities in New Relic. These entities will have the following entity tags:

• aws.elasticache.configurationEndpointAddress or aws.elasticache.endpointAddress
• aws.elasticache.configurationEndpointPort or aws.elasticache.endpointPort

If your services use OpenTelemetry instrumentation for Memcached it must emit the following attributes for a relationship to be generated:

• db.system: This attribute must have the value memcached.
• net.peer.name: This attribute must match the corresponding endpoint tag of the ElastiCache entity.
• net.peer.port: This attribute must match the corresponding port tag of the ElastiCache entity.

Amazon MQ (ActiveMQ)

The Amazon CloudWatch Metric Streams integration for Amazon MQ generates Amazon MQ entities in New Relic. These entities will have the following entity tag:

• aws.mq.endpoint

If your services use OpenTelemetry instrumentation for ActiveMQ it must the following attributes for a relationship to be generated:

• messaging.system: This attribute must have the value activemq.
• server.address: This attribute must match the corresponding endpoint tag of the Amazon MQ entity.
• span.kind: This relationship is generated from span data where span.kind is producer or consumer.

Amazon Managed Kafka (MSK)

The Amazon CloudWatch Metric Streams integration for MSK generates MSK entities in New Relic. These entities will have the following entity tag:

• aws.clusterName or aws.kafka.ClusterName
• aws.awsRegion or aws.region
• aws.topic or aws.kafka.Topic

If your services use OpenTelemetry instrumentation for MSK it must have the following attributes for a relationship to be generated:

• messaging.destination.name: The MSK topic to which the service is either producing messages or consuming messages.
• server.address: This attribute must match the corresponding endpoint tag of the MSK entity.
• span.kind: This relationship is generated from span data where span.kind is producer or consumer.

Adding custom tags to an entity

You can use tags to organize and filter your entities in the UI. Tags 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, 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.