OpenTelemetry Protocol, u OTLP para abreviar, 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 lo recomienda como el método preferido para enviar datos de OpenTelemetry a la plataforma New Relic. Este documento profundiza en el soporte OTLP de New Relic, incluidos los requisitos y recomendaciones de configuración.
Antes de que empieces
- Si aún no lo ha hecho, regístrese para obtener una cuenta gratuita de New Relic.
- Obtenga la clave de licencia para la cuenta New Relic a la que desea reportar datos. Esta clave de licencia se empleará para 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).
Si se emplea el recolector, el procesador de transformación se puede configurar para truncar el atributo hasta los límites New Relic .
Notas:
- Los atributos de recursos están sujetos a límites de atributos, pero no existen variables de entorno estándar para limitarlos. Si un atributo de recurso supera el límite permitido, considere truncarlo usando el procesador de transformación recolector o sobreescribir el atributo de recurso a 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 de New Relic . Si encuentra límites de longitud de nombre, elimine el atributo usando el selector.
Configuración: procesamiento por lotes de carga útil, 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 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 emplea el recolector, gzip
es la compresión predeterminada, pero zstd
se puede configurar opcionalmente.
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 emplea el recolector, otlphttpexporter
y otlpexporter
lo reintentan 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 instrumentados que se asignan a tipos de medidores New 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.
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.message
oStatus.details
.