El protocoloOpenTelemetry (OTLP) es un protocolo de entrega telemetry data de propósito general diseñado para el proyecto OpenTelemetry . Cada SDK de lenguaje OpenTelemetry proporciona exportadores OTLP, y el recolector OpenTelemetry tiene receptores y exportadores OTLP. Además, varias herramientas fuera del proyecto OpenTelemetry agregaron soporte para la exportación OTLP.
New Relic admite la ingesta OTLP nativa y la recomienda como el método preferido para enviar datos de OpenTelemetry a la plataforma New Relic. Esta página cubre el soporte OTLP de New Relic, incluida la configuración, los requisitos y las recomendaciones.
Antes de que empieces
Si aún no lo ha hecho, regístrese para obtener una cuenta gratuita de New Relic.
Obtén tu para la cuenta de New Relic a la que deseas informar datos. Esta clave de licencia se empleará al configurar el encabezado
api-key.
Configuración: extremo, puerto y protocolo de OTLP
Nivel de requisito: Required
Para configurar el envío de datos OTLP a New Relic, debe configurar su exportador OTLP para emplear el extremo y puerto relevantes de la siguiente tabla según su entorno.
El mecanismo para configurar el extremo variará, pero los SDK del lenguaje OpenTelemetry generalmente admiten la configuración de la variable de entorno OTEL_EXPORTER_OTLP_ENDPOINT=<INSERT_ENDPOINT> (consulte los documentosOpenTelemetry para obtener más información).
Además, debe configurar su exportador OTLP para emplear la versión protobuf binaria OTLP/HTTP del protocolo, si está disponible. Si bien New Relic admite todas las versiones de OTLP, el protobuf binario OTLP/HTTP demostró ser más robusto que gRPC sin ninguna reducción aparente en el rendimiento.
El mecanismo para configurar el extremo variará, pero los SDK del lenguaje OpenTelemetry generalmente admiten la configuración de la variable de entorno OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf (consulte los documentosOpenTelemetry para obtener más información).
Si está empleando un recolector, le recomendamos emplear otlphttpexporter.
Ambiente | gRPC | HTTP | Extremo | Puertos soportados |
|---|---|---|---|---|
OTLP de EE. UU. | ✅ | ✅ |
|
|
OTLP de la UE | ✅ | ✅ |
|
|
JP OTLP | ✅ | ✅ |
|
|
OTLP de la FedRAMP de EE. UU. | ✅ | ✅ |
|
|
rastreo infinito | ✅ | ✅ |
|
|
Configuración: cifrado TLS
Nivel de requisito: Required
Para enviar datos OTLP a New Relic, debe configurar su exportador OTLP para usar TLS 1.2 (consulte Cifrado TLS para obtener más información). Generalmente, los exportadores de SDK y recolectores cumplen con este requisito de forma predeterminada.
Si bien muchos exportadores de OTLP deducen la configuración de TLS del esquema extremo https , algunos exportadores de gRPC pueden requerir que habilites TLS explícitamente. El mecanismo para configurar gRPC TLS variará, pero los SDK del lenguaje OpenTelemetry generalmente admiten la configuración de la variable de entorno OTEL_EXPORTER_OTLP_INSECURE=false (consulte los documentos de OpenTelemetry para obtener más información).
Configuración: Configuración de la clave de API
Nivel de requisito: Required
Para enviar datos OTLP a New Relic, debe configurar su exportador OTLP para incluir un encabezado llamado api-key con el valor establecido en su clave de licencia. De lo contrario, se producirán errores de autenticación.
El mecanismo para configurar los encabezados variará, pero los SDK del lenguaje OpenTelemetry generalmente admiten la configuración de la variable de entorno OTEL_EXPORTER_OTLP_HEADERS=api-key=<INSERT_LICENSE_KEY> (consulte los documentos de OpenTelemetry para obtener más información).
Configuración: límites de atributos
Nivel de requisito: Recommended
New Relic impone una variedad de límites en los atributos de las cargas de OTLP. En general, tenemos una postura indulgente sobre la validación y podaremos, truncaremos o modificaremos los atributos en lugar de descartar los datos por completo. Cada vez que se modifica un atributo, creamos un NrIntegrationError para ayudar a rastrear y solucionar el problema en el origen.
Caso | Descripción | Configuración relevante |
Límite de longitud del valor de cadena | Los valores de atributo de tipo cadena tienen una longitud máxima de 4095 caracteres. Los valores que superan este límite se truncan. | Establezca
. Consulte la documentación de OpenTelemetry para obtener más información. |
Límite de longitud del valor principal | Las claves de atributo tienen una longitud máxima de 255 caracteres. Las claves que superan este límite se truncan. | |
Límite de recuento de atributos | Cada fuente de atributo está sujeta a un límite de recuento. Cuando se excede, los atributos sobrantes se eliminan, priorizando los atributos definidos en las convenciones semánticas de OpenTelemetry. Los límites son los siguientes:
| Mitigación parcial al configurar
. Consulte la documentación de OpenTelemetry para obtener más información. |
Tipos de valores | Los valores de los atributos están limitados a los tipos: cadena, entero, doble, booleano y matriz de bytes. Los valores de los atributos con tipos complejos se eliminan. Los atributos de log están excluidos de este límite. [1] | |
Valores no establecidos | Los valores de atributo deben establecerse (es decir,
). Los atributos con valores no establecidos se eliminan. Nota: los
s no se crean en este caso, ya que esto ocurre con la frecuencia suficiente como para que
oculte problemas de validación más procesables. | |
Límite de longitud de matriz | La matriz tiene una longitud máxima de 64 entradas. Los atributos que exceden este límite se recortan. | |
Homogeneidad de la matriz | Las entradas de las matrices deben ser todas del mismo tipo. Los atributos con entradas de matriz heterogéneas se eliminan. Los atributos de log están excluidos de este límite. [1] | |
Entradas de matriz no establecidas | Las entradas de matriz no deben estar sin establecer (es decir,
). Las entradas de matriz no establecidas se eliminan. | |
Tipos de valores de entrada de matriz | Las entradas de la matriz están limitadas a los tipos: cadena, entero, doble y booleano. Los valores de atributo de la matriz con tipos complejos se eliminan. Los atributos de log están excluidos de este límite. [1] | |
Límite de longitud de matriz de bytes | Las matrices de bytes tienen una longitud máxima de 128 000. Los atributos que exceden este límite se recortan. | |
Tipos de valores de atributos | Los valores de los atributos están limitados a los tipos: cadena, entero, doble, booleano y matriz de bytes. Los valores de los atributos con tipos complejos se eliminan. Los atributos de log están excluidos de este límite. [1] |
[1]: Consulte los tipos de atributos de OTLP.
Consulte límites de atributo métrico y límites de atributo de evento para conocer otros límites.
Configuración: procesamiento por lotes de carga útil, tiempo de espera, compresión y límites de velocidad
Nivel de requisito: Required
Para enviar datos OTLP a New Relic, su carga debe ser menor que el tamaño máximo de carga de 1 MB (10 ^ 6 bytes). Las cargas más grandes serán rechazadas con un código de estado de error. Es posible que una carga más grande tampoco pueda exportar con un tiempo de espera antes de que se devuelva un código de estado de error.
Además, New Relic impone límites de tarifas. Cuando se excede el límite de tarifa, las solicitudes se rechazarán con un código de estado de error.
Para evitar límites de tamaño de carga útil y límites de velocidad, debe configurar su exportador OTLP para emplear un tamaño de lote apropiado que haga que los datos se exporten en un intervalo apropiado.
El mecanismo para configurar el procesamiento por lotes variará. Los SDK de OpenTelemetry generalmente admiten la configuración de las siguientes variables de entorno (consulte los documentos de OpenTelemetry para obtener más información):
OTEL_BSP_*para tramosOTEL_METRIC_EXPORT_*para métricaOTEL_BLRP_*para logs
Si se emplea el recolector, el procesador por lotes controla el tamaño del lote.
Además, debe prestar atención a la configuración del tiempo de espera del exportador. Generalmente, las solicitudes de exportación tardan más cuando la carga es mayor y cuando las redes son más lentas (mayor latencia, menor ancho de banda). Si su aplicación produce una carga grande porque el volumen de telemetría es alto o el intervalo de exportación es alto, es posible que necesite aumentar la configuración de tiempo de espera predeterminada para evitar errores de exportación.
El mecanismo para configurar el tiempo de espera variará, pero los SDK del lenguaje OpenTelemetry generalmente admiten la configuración de la variable de entorno OTEL_EXPORTER_OTLP_TIMEOUT (consulte los documentos de OpenTelemetry para obtener más información).
Además, debe habilitar la compresión para reducir el tamaño de la carga útil y limitar la probabilidad de encontrar límites de tamaño de carga útil. New Relic admite la compresión gzip y zstd . La compresión zstd tiene un mayor rendimiento y se recomienda si su exportador la admite. Consulte comparación de compresión para obtener más detalles sobre la información del punto de referencia.
El mecanismo para configurar el extremo variará, pero los SDK del lenguaje OpenTelemetry generalmente admiten la configuración de la variable de entorno OTEL_EXPORTER_OTLP_COMPRESSION=gzip (consulte los documentosOpenTelemetry para obtener más información).
Si se emplea el recolector, gzip es la compresión predeterminada, pero opcionalmente puede configurar zstd.
Configuración: reintentar
Nivel de requisito: Recommended
Para enviar datos OTLP a New Relic, debe configurar su exportador OTLP para volver a intentarlo cuando se produzcan errores transitorios. Internet no es confiable y no volver a intentarlo aumenta la probabilidad de pérdida de datos.
El mecanismo para configurar el reintento variará. Algunos SDK de OpenTelemetry pueden tener variables de entorno específicas del idioma (por ejemplo, Java admite la configuración OTEL_EXPERIMENTAL_EXPORTER_OTLP_RETRY_ENABLED=true), pero no existe un mecanismo general. Es posible que se requiera configuración programática.
Si se emplea el recolector, otlphttpexporter y otlpexporter vuelven a intentarlo de forma predeterminada. Consulte exporterhelper para obtener más detalles.
Config: temporalidad de agregación métrica
Nivel de requisito: Recommended
Para enviar datos métricos OTLP a New Relic, debe configurar su exportador métrico OTLP para que prefiera la temporalidad de agregación delta. Si bien New Relic admite la temporalidad de agregación acumulativa, la arquitectura métrica New Relic es generalmente un sistema delta métrico. El uso de la configuración acumulativa predeterminada generalmente generará un mayor uso de memoria por parte de los SDK y dará como resultado una ingesta alta de datos.
El mecanismo para configurar el extremo variará, pero los SDK del lenguaje OpenTelemetry generalmente admiten la configuración de la variable de entorno OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=delta (consulte los documentosOpenTelemetry para obtener más información). Si configura la temporalidad manualmente, configúrelo por tipo de instrumento de la siguiente manera:
- Counter, Asynchronous Counter, Histogram: Delta
- UpDownCounter, Asynchronous UpDownCounter, Gauge, Asynchronous Gauge: Cumulative
La temporalidad acumulativa se emplea para los instrumentados que se asignan a los tipos de medidoresNew Relic y que generalmente se analizan empleando el valor acumulativo.
Configuración: agregación de histograma métrico
Nivel de requisito: Recommended
Para enviar datos métricos OTLP a New Relic, debe configurar su exportador métrico OTLP para agregar mediciones desde histograma instrumentado a histograma exponencial. A diferencia de los depósitos estáticos empleados con el histograma de depósito explícito predeterminado, el histograma exponencial ajusta automáticamente sus depósitos para reflejar el rango de mediciones registradas. Además, emplean una representación altamente comprimida para enviar por cable. Los histogramas exponenciales proporcionan datos de distribución más útiles en la plataforma New Relic .
El mecanismo para configurar el extremo variará, pero los SDK del lenguaje OpenTelemetry generalmente admiten la configuración de la variable de entorno OTEL_EXPORTER_OTLP_METRICS_DEFAULT_HISTOGRAM_AGGREGATION=base2_exponential_bucket_histogram (consulte los documentosOpenTelemetry para obtener más información).
Versión del protocolo OTLP
New Relic emplea la versión OTLP v1.4.0. Se admiten versiones anteriores y posteriores, pero aún no se implementaron nuevas funciones. Las características experimentales que se eliminaron luego de la versión 0.18.0 no son compatibles.
Consulte traza, métrica y logs para obtener detalles específicos sobre cómo se asignan los datos y qué características se implementan.
Tipos de atributos OTLP
Los atributos son un concepto recurrente en OpenTelemetry y OTLP. OpenTelemetry tiene una definición de atributo estándar , que establece que los valores de los atributos son primitivos (cadena, booleano, punto flotante doble, entero de 64 bits) o una matriz homogénea de primitivos. Sin embargo, en el nivel del protocolo OTLP, los atributos se representan empleando una definición AnyValue más amplia. Debido a esto, es posible que los clientes OTLP envíen atributos que no se ajusten a la definición estándar OpenTelemetry .
El extremo OTLP New Relic admite la definición de atributo estándar. No se admiten tipos complejos como mapas de mapas, matrices de objetos y matrices heterogéneas. Los SDK OpenTelemetry solo deben producir datos que se ajusten a la definición de atributo estándar.
Importante
Si bien generalmente se emplea la definición de atributo estándar, los atributos de log son excepcionales y admiten valores complejos (por ejemplo, el tipo de atributo de log es map<string, any>). A pesar de esto, New Relic actualmente solo admite atributos de registro log que se ajusten a la definición de atributo estándar.
Carga de respuesta OTLP
Tenga en cuenta los siguientes detalles sobre la carga de respuesta extrema New Relic OTLP:
- Las respuestas exitosas de New Relic no tienen cuerpo de respuesta, en lugar de una respuesta codificada en Protobuf según el tipo de datos.
- New Relic responde luego de la validación de la autenticación, el tamaño de la carga útil y la limitación de velocidad. La validación del contenido de la carga útil se produce de forma asincrónica. Por lo tanto, New Relic puede devolver códigos de estado de éxito a pesar de que la ingesta de datos finalmente falló y resultó en el evento
NrIntegrationError. - Las respuestas de error de New Relic no incluyen
Status.messageoStatus.details.