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 implicará un mayor uso de memoria de los SDK y dará como resultado una mayor ingesta de datos. La conversión de agregación acumulativa a agregación delta es una actividad con estado, ya que es necesario conservar el punto anterior de cada serial de tiempo 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 en el futuro.
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
En la siguiente tabla se enumeran diversas herramientas útiles para gestionar su canal 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 disponibles o que usted pueda escribir una lógica de extensión personalizada para los SDK de lenguaje 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 los documentos de idioma 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 de New Relic intervalo para alinearlos con los límites de atributo del extremo OTLP . | |
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 los para que se alineen con los New Relic límites de atributos del extremo OTLP . | |
SDK desactiva rastreador, medidores, registrador | SDK | El SDK OpenTelemetry define |
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 | |
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 OTLP métrica en delta, alinear con la New Relic preferencia de OTLP extremo. | |
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 los documentos de idiomas individuales para obtener más detalles. | |
Recolector | El procesador de filtro recolector se puede emplear para filtrar logs de intervalo, métricas y log de su canal de observabilidad. En el caso de tramos, puede funcionar como un simple muestreador de cola, actuando sobre tramos completados pero sin acceso a la traza completa (Nota: esto puede dar como resultado una traza rota). Para métricas, se puede emplear para descartar métricas o seriales que no tengan un valor alto. Para el log, se puede emplear para eliminar registros log que no tienen un valor alto (por ejemplo, log con severidad de grano fino o de logger ruidoso). | |
Recolector | La ejemplificación de cola del recolector le permite decidir si desea tomar muestras en función de las trazas completadas. Por ejemplo, puedes enfatizar la retención de trazas que tienen errores o que tocan áreas de alto interés del sistema. La desventaja es que el procesador de ejemplificación de cola agrega complejidad a su flujo de observación, 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 la traza se complete. Esto requiere una planeación cuidadosa cuando su flujo de trabajo de observabilidad alcanza una escala que no puede ser manejada por una única instancia de recolector. | |
Recolector | El procesador de recursos del recolector le permite escribir reglas simples para manipular atributos de recursos de spans, métrica y log. Por ejemplo, puedes 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 del recolector le permite transformar datos de observabilidad empleando condiciones para seleccionar datos y declaraciones para modificarlos. Por ejemplo, puede eliminar el atributo de recurso, truncar el atributo, cambiar los campos de nivel superior para intervalos, métricas y registros de log, y mucho más. | |
Recolector | El procesador recolector cumulativetodelta 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 agregación delta es un proceso con estado, que requiere que el recolector almacene el último punto de cada serial temporal en la memoria para calcular y emitir la diferencia. Esto requiere una planeación cuidadosa de los recursos de memoria del recolector y la estructuración de la cadena de observabilidad para garantizar que todos los puntos del mismo serial lleguen a la misma instancia del recolector. |