Registro OpenTelemetry en New Relic

Esta documentación se centra en cómo New Relic procesa el registro OpenTelemetry recibido a través de su extremo OTLP dedicado.

Hay dos flujos de trabajo típicos para enviar registros OpenTelemetry a New Relic:

• Directo al recolector:

  • La aplicación puede enviar el registro directamente al New Relic OTLP endpoint.
  • Consulte la documentación del lenguaje OpenTelemetry relevante para obtener detalles de implementación específicos y el monitoreo de OpenTelemetry APM para obtener detalles sobre los servicios de monitoreo con New Relic.

• A través de archivo o stdout:

  • Este método implica extraer el registro de aplicación escrito en archivos o salida estándar (stdout).

  • El recolector OpenTelemetry se emplea normalmente para esta tarea. Luego, los logs raspados se envían al extremo OTLP New Relic .

  • Puede encontrar información de configuración detallada en los siguientes recursos de OpenTelemetry:

    • Recolector OpenTelemetry
    • Receptor de registros de archivos con Kubernetes
    • Un ejemplo práctico que demuestra este flujo de trabajo para una aplicación Java usando Log4j2

Independientemente del método de recopilación elegido, una integración exitosa requiere configurar su fuente log para exportar registros a este extremo. Cerciorar de revisar los requisitos de configuración extrema antes de continuar.

Mapeo de registro log OTLP

New Relic asigna log de OTLP al tipo de datos Log. La siguiente tabla describe cómo los campos del mensaje protoLogRecord se asignan a New Relic Log:

Notas a pie de tabla

[1] En caso de conflicto en el atributo de recurso, el atributo de alcance, el atributo de registro log , los campos de registro log de nivel superior y el atributo analizado de LogRecord.body [3], el orden del precedente (de mayor a menor) es: atributo analizado de LogRecord.body -> campos de nivel superior LogRecord.* > LogRecord.attributes > ScopeLogs.InstrumentationScope.attributes > ResourceLogs.Resource.attributes.

Consulte Tipos de atributos OTLP para obtener detalles sobre los tipos de atributos compatibles con OTLP extremo New Relic y los límites de atributos OTLP para obtener detalles sobre la validación realizada en los atributos.

[2] Si LogRecord.time_unix_nanos no está presente, timestamp se establece en la hora en que New Relic recibió los datos.

[3] Se aplica un análisis de logs a LogRecord.body para intentar extraer el atributo de:

• Texto de log sin formato: el valor de la cadena se establecerá como el atributo message .
• JSON convertido en cadena: si un log tiene formato JSON pero se envía como una cadena de texto sin formato, los pares principales de valores se convertirán en atributos del log resultante. Para obtener más detalles, consulte la documentación de análisis de JSON . Esto es particularmente útil cuando se recopilan logs de archivos o stdout. En este caso, es común no tener ningún atributo de recurso asociado con el log (requerido para la correlación del servicioAPM ) y ningún valor para LogRecord.trace_id / LogRecord.span_id (requerido para la correlación de traza). Los logs en contexto funcionarán según lo previsto si los campos obligatorios se pueden analizar correctamente.
• Estructura del mapa: si los datos están formateados como un mapa de acuerdo con la especificación OTLP, se analizarán y aplanarán en atributos, de forma similar al análisis de JSON. Para obtener más detalles, consulte la documentación de análisis de JSON .

Correlación con el servicio OpenTelemetry APM

log se correlacionan con una entidad de servicio si incluyen el atributo requerido. Normalmente, estos provienen del atributo de recurso del log, como ResourceLogs.Resource.attributes, pero también se pueden analizar desde LogRecord.body como se describe en la nota al pie n.° 3 del mapeo de OTLP.

Para ver el registro de un servicio, navegue hasta la página de registro de ese servicio.

Correlación con trazas

Log se correlacionan con una traza si trace.id y span.id atributo se pueden resolver. Normalmente, estos provienen de los campos LogRecord.trace_id y LogRecord.span_id , pero también se pueden analizar desde LogRecord.body como se describe en la nota al pie 3 del mapeo OTLP.

Para ver el registro registrado en el contexto de una traza particular, tiene dos opciones:

• Navegue a la pestaña de Logs dentro de la página de detalles de la traza.
• Navegue a la página de registro de un servicio y haga clic en un log para abrir los detalles log. Si está asociado a una traza, podrás navegar desde los Log details hasta los Trace details.

Inicia sesión como evento personalizado New Relic

OpenTelemetry define un evento como un LogRecord con un EventName no vacío. evento personalizado son una señal central en la plataforma New Relic. Sin embargo, a pesar de emplear el mismo nombre, OpenTelemetry evento y New Relic evento personalizado no son conceptos idénticos:

• Los OpenTelemetry EventNameno comparten el mismo formato ni semántica que los tipos de eventos personalizados. Los nombres de eventos OpenTelemetry están completamente calificados con un namespace y siguen el formato de serpiente en minúscula, por ejemplo com.acme.my_event. Los tipos de evento personalizado son el caso Pascal, por ejemplo. MyEvent.
• OpenTelemetry evento puede considerar como un log estructurado mejorado. Al igual que los logs estructurados, sus datos están codificados en pares principales de valor en lugar de texto de formato libre. Además, el EventName actúa como una señal inequívoca de la clase/tipo de evento que ocurrió. Los eventos personalizados se tratan como un tipo de evento completamente nuevo, accesible a través de NRQL con SELECT * FROM MyEvent.

Debido a estas diferencias, los eventos OpenTelemetry se incorporan como New Relic Logs ya que la mayoría de las veces, los eventos de OpenTelemetry son más similares a New Relic Logs que a los eventos New Relic personalizados.

Sin embargo, puedes indicar explícitamente que un OpenTelemetry LogRecord debe ingerir como un evento personalizado agregando una entrada a LogRecord.attributes siguiendo el formato: newrelic.event.type=<EventType>.

Por ejemplo, un LogRecord con atributo newrelic.event.type=MyEvent se ingerirá como un evento personalizado con type=MyEvent y será accesible a través de NRQL con: SELECT * FROM MyEvent.