Logs may represent application logs, machine generated events, or system logs. OpenTelemetry has defined a log data model for representing log data.
You can send logs using OpenTelemetry tooling, correlate them with applications, and view them in New Relic.
As the OpenTelemetry Protocol matures and more components are declared stable, we intend to move the version supported by our OTLP endpoints from v0.10.0 to a more recent release, at least v0.16.0, before September 2022.
Additional communication will be forthcoming regarding the EOL timeline for v0.10.0 support and actions you can take to minimize disruption as the community moves toward a more stable release of OTLP.
- Receive logs from any of the log receivers. Some of the receiver options include Filelog Receiver, Fluent Forward Receiver, and Syslog Receiver.
- Process logs, potentially annotating them with resource information. Some of the processor options include Resource Detection Processor and Resource Processor.
- Export logs to New Relic via the OTLP exporter.
Application logs are more useful if they're correlated with other telemetry data produced by the application. The OpenTelemetry semantic convention for services specifies
service.name as a required field. All application metric, trace, and log data sent to New Relic with the same
service.name are associated with the same entity.
The specifics of how logs get annotated with the
service.name resource attribute depends on the application's environment:
- Applications may produce structured JSON logs, which you can configure to include
service.nameas another field.
- You can deploy applications alongside a dedicated Collector Agent instance, which you can configure with a Resource Processor to annotate logs with the
Optionally, additional application trace context (sometimes called execution context) can be propagated to log messages. The setup and availability of this depends on the language and logging framework used by the application. The general strategy is to set up the application to write structured JSON logs and to configure it to extract trace context into specified trace context fields on available log messages.
The Logs in Context with Log4j2 example in GitHub demonstrates an end-to-end working example for a simple Java application using Log4j2.
Here are two ways you can view logs:
- Look in the New Relic Logs UI.
- If your logs are correlated with an application, view them in the context of the application.
timeUnixNano field is optional according to the OpenTelemetry specification for log data. When
timeUnixNano is not present New Relic will use the time that the data was received for the New Relic log timestamp.