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 | ✅ | ✅ |
|
|
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: Required
Para enviar datos OTLP a New Relic, debe configurar su fuente de telemetría para que se ajuste a los límites del atributo New Relic . No hacerlo puede resultar en el evento NrIntegrationError durante la validación de datos asincrónicos.
Los límites de los atributos son los siguientes:
- Longitud máxima del nombre del atributo: 255 caracteres
- Longitud máxima del valor del atributo: 4095 caracteres
- Tamaño máximo del valor de la matriz de atributos: 64 entradas
Consulte límites de atributo métrico y límites de atributo de evento para conocer otros límites.
El mecanismo para configurar los límites de atributos variará, pero los SDK del lenguaje OpenTelemetry generalmente admiten la configuración de las variables de entorno OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT=4095 y OTEL_ATTRIBUTE_COUNT_LIMIT=64 (consulte los documentosOpenTelemetry para obtener más información).
Al emplear el recolector, puede configurar el procesador de transformación para truncar el atributo según los límites New Relic .
Notas:
- Los atributos de recurso están sujetos a límites de atributos, pero no hay variables de entorno estándar que los limiten. Si un atributo de recurso supera el límite permitido, considere truncarlo usando el procesador de transformación del recolector o sobreescribir el atributo de recurso con otro valor.
- No existe un mecanismo estándar para limitar los nombres de atributos. Sin embargo, la instrumentación generalmente no produce nombres de atributos que excedan los límites New Relic . Si encuentra límites de longitud de nombre, elimine el atributo empleando el recolector.
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 mistogramas métricos
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 v0.18.0. Se admiten versiones posteriores, pero aún no se han implementado nuevas funciones. Las características experimentales que ya no están disponibles en 0.18.0 no son compatibles.
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.