Una de las principales fortalezas de OpenTelemetry es su rico conjunto de herramientas que brindan un control incomparable sobre su canal telemetry data . Este control complementa el modelo de precios basados en el consumo de New Relic.
Esta página habla sobre una variedad de conceptos que contribuyen al volumen de datos cuando se usa OpenTelemetry con New Relic y herramientas/patrones disponibles para gestionar su canal telemetry data. Está organizado en secciones que tratan sobre conceptos clave que contribuyen al volumen de datos para recursos, trazas, métricas y logs, seguidos de un catálogo de herramientas disponibles para ayudar a gestionar el volumen.
Conceptos clave: Recursos
OTLP define una estructura de mensajes jerárquica similar en todas las señales, lo que evita la repetición a nivel de protocolo al compartir información entre registros.
- Cada solicitud de exportación contiene muchos
Resource{SignalRecord}s - Cada
Resource{SignalRecord}contiene muchosScope{SignalRecord}s - Cada
Scope{SignalRecord}contiene muchos{SignalRecord}s {SignalRecord}esSpan,MetricyLogRecord
Esta estructura jerárquica se aplana cuando se envía al extremo de New Relic y cada atributo de recurso se desnormaliza en registros individuales Span, Metric y Log. Para obtener más información sobre cómo se manejan los datos de OpenTelemetry en New Relic, consulte las siguientes páginas:
La mayoría de las implementaciones del lenguaje OpenTelemetry proporcionan paquetes con detectores de recursos, que aportan atributos de recursos basados en la información detectada en el entorno. Estos atributos pueden ser extremadamente útiles, pero pueden incluir más información de la necesaria.
Para obtener más detalles, consulte lo siguiente:
Conceptos clave: traza
Muestreo
La ejemplificación es el proceso de controlar qué tramos se exportan a un backend de observabilidad. Los datos de traza pueden proporcionar información muy valiosa, pero si no se controlan pueden llenar rápidamente los discos duros (¡y las facturas!).
De forma predeterminada, los SDK de OpenTelemetry emplean la muestra ParentBased(root=AlwaysOn). El muestreador ParentBased delega a diferentes muestreadores configurables en función de si hay un principal de intervalo, si ese padre es local para el proceso actual o remoto, y si ese padre está muestreado. El muestreador predeterminado ParentBased(root=AlwaysOn) muestreará un intervalo si se cumple alguna de las siguientes condiciones:
- No hay un tramo principal (es decir, este tramo es la raíz)
- Se muestrea el padre, independientemente de si el padre es local o remoto
En otras palabras, muestreará el intervalo a menos que no se muestree el padre.
Este es un buen valor predeterminado para la comunidad OpenTelemetry ya que permite al usuario instalar instrumentación y ver datos de traza sin necesidad de conocer primero el concepto de ejemplificación. Sin embargo, se debe tener cuidado con el despliegue de producción de OpenTelemetry. Según esta política, se toman muestras de todos los tramos, a menos que haya algún componente ascendente o puerta de enlace que tome decisiones de ejemplificación inteligentes que los sistemas descendentes deban cumplir.
Para alternativas, consulte lo siguiente:
- Muestra ParentBased(root=TraceIdRatioBased)
- Procesador de filtro recolector
- Procesador de ejemplificación de cola recolector
Datos de extensión
Los intervalos OpenTelemetry se componen de una variedad de campos de nivel superior (nombre, tipo, etc.), atributo, evento de intervalo y enlaces de intervalo. La cantidad de datos adjuntos a los tramos corresponde directamente al volumen de datos en New Relic.
Instrumentación biblioteca toman decisiones sobre qué piezas de información anexar a los tramos, a menudo siguiendo las convenciones semánticas. Cuando se producen excepciones, la información suele anexar al intervalo en forma de evento de intervalo de excepción. Este evento incluye un atributo que representa el mensaje de excepción, el tipo y traza de stack, que, según el idioma y la aplicación, puede constar de miles de bytes. Si se producen excepciones con frecuencia, las trazas de stack pueden producir un gran volumen de datos en New Relic.
Para conocer estrategias para gestionar datos de intervalo, consulte lo siguiente:
Rastreador
Un alcance de instrumentación es una unidad lógica de código de aplicación con telemetría asociada. Cada biblioteca de instrumentación tiene uno (o más) alcances únicos y su correspondiente rastreador.
El rastreador que no produce datos de traza de alto valor se puede desactivar selectivamente sin romper la traza.
Para obtener más detalles, consulte SDK deshabilitar rastreador, medidor, registrador.
Conceptos clave: métrica
Intervalo de recogida
Métrica agrega medidas individuales y exporta el estado agregado fuera de proceso. Para protocolos basados en push como OTLP, la exportación se produce en un intervalo configurable predeterminado en 60s. Este intervalo corresponde directamente al volumen de datos en New Relic. Reduzca el intervalo a 30s y el volumen de datos debería aproximadamente duplicar. Aumente el intervalo a 120s y el volumen de datos debería reducir aproximadamente a la mitad.
El intervalo predeterminado 60s es un valor predeterminado razonable, ya que equilibra el equilibrio entre el volumen de datos y el retraso de observabilidad. Aumente el intervalo demasiado alto y los retrasos en las señales críticas que llegan al dashboard de control y las alertas New Relic pueden exacerbar los problemas.
Para obtener más detalles, consulte SDK de exportación periódica del Lector métrico exportIntervalMillis.
Cardinalidad
Las medidas que agrega métricamente están asociadas a un conjunto de atributos. El número de conjuntos distintos de atributos se llama cardinalidad. La cardinalidad es importante porque dicta cuánta memoria de la aplicación se requiere para mantener el estado agregado de las mediciones, cuántos datos se exportan en cada intervalo de recopilación y el volumen de datos en New Relic.
Si la cardinalidad es demasiado alta, considere omitir el atributo que contribuye a ella. Si controlas la instrumentación, esto podría significar registrar menos atributos con cada medición. Sin embargo, la instrumentación a menudo no es directamente configurable.
Para obtener detalles sobre cómo eliminar atributo de métrica, consulte lo siguiente:
Temporalidad de agregación
En OpenTelemetry métrica, el concepto de temporalidad de agregación define si el estado de las mediciones agregadas se restablece o no luego de cada colección. Cuando la temporalidad de agregación es acumulativa, el estado agregado no se restablece y la métrica representa los valores acumulados desde el inicio de la aplicación. Cuando la temporalidad de agregación es delta, el estado agregado se resetear luego de cada colección y la métrica representa la diferencia desde la colección anterior.
Mientras que el extremo OTLP de New Relic admite la temporalidad de agregación acumulativa, la arquitectura métrica New Relic es un sistema delta métrica. 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 alta ingesta de datos. La conversión de agregación acumulativa a delta es una actividad con estado, ya que es necesario retener el punto anterior de cada serial temporal para calcular la diferencia. Por este motivo, es mejor configurar la temporalidad de agregación en el SDK, lo que ahorra memoria de la aplicación y evita complejidad adicional posterior.
Para obtener más detalles, consulte lo siguiente:
Metros e instrumentado
Un alcance de instrumentación es una unidad lógica de código de aplicación con telemetría asociada. Cada biblioteca de instrumentación tiene uno (o más) alcances únicos y medidor(es) correspondiente(s), y cada medidor tiene uno o más instrumentados.
Los medidores o instrumentados que no proporcionen datos métricos valiosos pueden ser desactivados selectivamente.
Para obtener más detalles, consulte lo siguiente:
Conceptos clave: logs
Registro de datos
OpenTelemetry log Los registros se componen de una variedad de campos de nivel superior (timestamp, gravedad, cuerpo, etc.) y atributos. La cantidad de datos adjuntos a log registros corresponde directamente al volumen de datos en New Relic.
La instrumentación biblioteca (llamadas log agregadores en el OpenTelemetry log espacio ya que la del OpenTelemetry log puente API está diseñada para unir los logs do log API de a OpenTelemetry) toma decisiones sobre qué piezas de información anexar a log los registros , a menudo siguiendo las convenciones semánticas.
Para conocer estrategias sobre la gestión de datos log , consulte lo siguiente:
- Límites de registro de registro del SDK
- SDK configura adjuntos log
- Procesador de filtro recolector
- Procesador de transformación recolector
Registrador
Un alcance de instrumentación es una unidad lógica de código de aplicación con telemetría asociada. OpenTelemetry Para logger log el OpenTelemetry log registro , cada distinto (conectado por un agregador mediante la del puente API) tiene un alcance de instrumentación único.
Los registradores que no producen datos log de alto valor se pueden desactivar selectivamente.
Para obtener más detalles, consulte lo siguiente:
Catálogo de herramientas de gestión de tuberías
La siguiente tabla enumera una variedad de herramientas útiles para gestionar su canalización de datos de OpenTelemetry. Tenga en cuenta que OpenTelemetry es un ecosistema altamente extensible. Si estas herramientas no son suficientes, es posible que haya otras herramientas disponibles o que usted pueda escribir una lógica de extensión personalizada para los SDK de idiomas o el recolector para lograr sus objetivos.
Nombre | ¿Recolector o SDK? | Descripción |
|---|---|---|
SDK | Los SDK del lenguaje OpenTelemetry empaquetan detectores para proporcionar atributos de recursos según el entorno. Algunos conjuntos de estos suelen estar habilitados de forma predeterminada con opciones de instrumentación de código cero como el agente de Java OpenTelemetry. Consulte para obtener detalles sobre cómo habilitar/deshabilitar los detectores de recursos. | |
SDK | El sampler bash Configure el muestreador | |
SDK | El SDK de traza de OpenTelemetry permite configurar límites de tramo para especificar la longitud y cantidad máximas de atributos, el número máximo de eventos de tramo y el número máximo de enlaces de tramo. Los límites de amplitud se pueden configurar mediante programación en el SDK bash Establezca los límites del tramo para alinearlos con loslímites de atributos del extremo OTLP de New Relic. | |
SDK | El OpenTelemetry log SDK permite configurar límites de extensión para especificar la longitud máxima y la cantidad del atributo. Los límites de LogRecord se pueden configurar mediante programación en el SDK bash Establezca los log límites de para alinearlos con los límites de atributos del extremo OTLP de New Relic. | |
SDK desactiva , , | SDK | El SDK OpenTelemetry define
,
y
para configurar y deshabilitar el rastreador, los medidores y el registrador respectivamente. Este concepto está actualmente en desarrollo y no está disponible en todas las implementaciones de idiomas. Consulte individuales y comunicar con los mantenedores de idiomas para verificar el estado. |
SDK exportación periódica Lector métrica | SDK | El SDK de OpenTelemetry métrica permite configurar el intervalo de recogida del lector métrico exportador periódico. El intervalo se puede configurar mediante programación, pero es común usar variables env: bash Establezca el intervalo de recopilación en 60 s (60 000 ms). Este es el valor predeterminado, pero se puede ajustar para adaptarlo. |
SDK | El SDK OpenTelemetry métrica permite configurar
con vistas para especificar varias opciones, incluido el conjunto de claves de atributos que se deben retener, el tipo de agregación y la eliminación de la métrica. Generalmente, las vistas se configuran mediante programación. Consulte individuales para buscar alternativas en su idioma. Por ejemplo, OpenTelemetry Java tiene soporte experimental para configurar vistas en un . | |
SDK | El SDK OpenTelemetry métrica permite configurar la temporalidad de agregación para el exportador OTLP. Esta temporalidad se puede configurar mediante programación, pero es común usar env vars: bash Establezca la temporalidad de agregación del exportador métrico en delta, alinear con la preferencia del extremo OTLP de New Relic. | |
SDK | La de OpenTelemetry log puente API está diseñada para que la empleen los log agregadores , que unen el registro de log API a OpenTelemetry. Estos agregados log pueden instalar automáticamente con opciones de instrumentación de código cero como OpenTelemetry agente de Java, o pueden requerir pasos de instalación manual. A menudo tienen opciones de configuración para especificar qué registro y qué datos se conectan a OpenTelemetry. Además, a menudo es posible configurar la log API que se está conectando para especificar qué log (según la gravedad o el logger nombre ) se debe pasar al log agregador. Consulte individuales para obtener más detalles. | |
Recolector | El procesador de filtro recolector se puede emplear para filtrar registros de span, métricas y log de su canal de observabilidad. Para tramos, puede funcionar como un simple muestreador de cola, actuando sobre tramos completos pero sin acceso a la traza completa (Nota: esto puede resultar en traza rota). Para métrica, se puede emplear para soltar métricas o seriales que no sean de alto valor. Para el log, se puede emplear para log registros que no sean de alto valor (p. ej. logs con severidad de grano fino o de madereros ruidosos). | |
Recolector | La ejemplificación de cola del recolector le permite decidir si tomar muestras en función de la traza completa. Por ejemplo, se puede destacar retener trazas que tengan errores o que toquen áreas de alto interés del sistema. El inconveniente es que el procesador de ejemplificación de cola agrega complejidad a su canal de observabilidad, ya que requiere que todos los tramos de una traza se enruten a la misma instancia del recolector, y que el recolector mantenga los tramos en la memoria mientras espera que se complete la traza. Esto requiere una planeación cuidadosa cuando su canal de observabilidad alcanza una escala que no puede ser manejada por una sola instancia de recolector. | |
Recolector | El procesador de recursos recolector le permite escribir reglas simples para manipular atributos de recursos de tramos, métricas y log. Por ejemplo, puede eliminar atributos que no tengan un valor alto. | |
Recolector | El procesador de transformación recolector métrica le permite manipular datos métricos. Por ejemplo, puede eliminar seriales que no tengan un valor alto o fusionar seriales temporales para reducir la cardinalidad (a veces llamado reagregación espacial). | |
Recolector | El procesador de transformación recolector le permite transformar datos de observabilidad usando condiciones para seleccionar datos y declaraciones para modificarlos. Por ejemplo, puede eliminar atributos de recursos, truncar atributos, cambiar campos de nivel superior para registros de logs, métricos y de registro, y mucho más. | |
Recolector | El procesador recolector acumulativotodelta le permite transformar la temporalidad de agregación métrica de acumulativa a delta. Esto es útil para alinear su métrica con la temporalidad de agregación preferida del extremo OTLP de New Relic . Tenga en cuenta que la traducción de agregación acumulativa a delta es un proceso con estado, que requiere que el recolector almacene el último punto de cada serial temporal en la memoria para poder calcular y emitir la diferencia. Esto requiere una planeación cuidadosa de los recursos de la memoria del recolector y la estructuración del canal de observabilidad para garantizar que todos los puntos del mismo serial lleguen a la misma instancia del recolector. |