OpenTelemetry logs in New Relic

This documentation focuses on how New Relic processes OpenTelemetry logs received through its dedicated OTLP endpoint.

There are two typical workflows for sending OpenTelemetry logs to New Relic:

• Direct to Collector:

  • Applications can send logs directly to the New Relic OTLP endpoint.
  • Refer to the relevant OpenTelemetry language documentation for specific implementation details, and OpenTelemetry APM monitoring for details on monitoring services with New Relic.

• Via file or stdout:

  • This method involves scraping application logs written to files or standard output (stdout).
  • The OpenTelemetry Collector is typically used for this task. Scraped logs are then forwarded to the New Relic OTLP endpoint.
  • In-depth configuration information can be found in the following OpenTelemetry resources:
    • OpenTelemetry Collector
    • Filelog receiver with kubernetes
    • A practical example demonstrating this workflow for Java applications using Log4j2

Regardless of the chosen collection method, successful integration requires configuring your log source to export logs to this endpoint. Make sure to review the endpoint configuration requirements before proceeding.

OTLP log record mapping

New Relic maps OTLP log records to the Log data type. The table below describes how fields from the LogRecord proto message are mapped to New Relic Log:

Table footnotes

[1] In case of conflict in resource attributes, scope attributes, log record attributes, top level log record fields, and parsed attributes from the LogRecord.body [3], the order of precedent (highest to lowest) is: parsed attributes from LogRecord.body -> top level LogRecord.* fields > LogRecord.attributes > ScopeLogs.InstrumentationScope.attributes > ResourceLogs.Resource.attributes.

See OTLP attribute types for details on New Relic OTLP endpoint supported attribute types.

[2] If LogRecord.time_unix_nanos is not present, timestamp is set to the time New Relic received the data.

[3] Log parsing is applied to the LogRecord.body to attempt to extract attributes from plain log text. For example, if a JSON structured log format is used, the key / values become attributes on the resulting log. This is particularly useful when collecting logs from files or stdout. In this case, it's common to have no resource attributes associated with the log record (required for APM service correlation) and no value for LogRecord.trace_id / LogRecord.span_id (required for trace correlation). Correlation will function as intended if the required fields can be successfully parsed.

Correlation with OpenTelemetry APM service

Log are correlated with a service entity if they include the required attributes. Typically, these come from the log's resource attributes, such as ResourceLogs.Resource.attributes, but they can also be parsed from the LogRecord.body as described in footnote #3 of OTLP mapping.

To view a service's logs, navigate to the Logs page for that service.

Correlation with traces

Logs are correlated with a trace if trace.id and span.id attributes can be resolved. Typically, these come from LogRecord.trace_id and LogRecord.span_id fields, but can also be parsed from the LogRecord.body as described in footnote 3 of OTLP mapping.

To view logs recorded in the context of a particular trace, you have two options:

• Navigate to the Logs tab within the trace details page.
• Navigate to the Logs page for a service and click on a log to open log details. If it's associated with a trace, you'll be able to navigate from Log details to Trace details.