Los equipos implementan continuamente canales de telemetría programables en producción sin acceder al modo de prueba. Al mismo tiempo, la mayoría de las organizaciones carecen de entornos de puesta en escena similares a los de producción, especialmente cuando se trata de observabilidad y otros servicios a nivel de plataforma. A pesar de conocer los riesgos potenciales debido a la falta de arneses adecuados, la mayoría de los equipos no tienen otra forma segura de determinar qué datos de telemetría pueden realmente cortar para mejorar la relación señal-ruido sin correr el riesgo de perder información importante.
Entonces el equipo recurrió a experimentar con tráfico instantáneo.
Lo que comenzó como un problema de almacenamiento rápidamente se convirtió en un problema de costos debido al gran volumen de datos que se almacenaban. No es una pregunta de «probablemente deberíamos investigar eso», sino de «esta línea de pedido compite con nuestro gasto en computación».
La infraestructura programable a menudo viene con una forma de obtener una vista previa de los cambios. Terraform tiene planes. La base de datos tiene EXPLICAR. El compilador tiene una advertencia. Desafortunadamente, OpenTelemetry Collector no tiene esto. El ingeniero de software edita el YAML, recarga el proceso y reza para que no hayan eliminado simplemente lo que se necesitaba en el momento del incidente. Existen algunas soluciones patentadas que pueden ayudar a reducir el ruido y el análisis de costos, pero no en el mundo del código abierto.
Esta brecha me impulsó a crear estudio de señal.
Signal Studio agrega una nueva capa de diagnóstico a OpenTelemetry Collectors, similar a un modo de «ejecución de prueba» o «planificación» para canalizaciones de telemetría. Para ello, combina el análisis de configuración estática con métricas en tiempo real y el Protocolo de telemetría abierta ocasional (OTLP) para evaluar el comportamiento del filtro en función del tráfico observado.
Problema «Solo agrega más filtros»
Si ha operado OpenTelemetry Collectors a cualquier escala significativa, probablemente haya tenido una conversación como esta:
«Nuestros costes de telemetría son demasiado altos».
«Está bien, agreguemos algunos filtros».
“¿A qué métricas estamos renunciando?”
«…¿los que no necesitamos?»
El problema no es que los equipos no quieran reducir el desperdicio de telemetría. Carecen de visibilidad de lo que realmente fluye a través del proceso, qué métricas son grandes, qué propiedades impulsan la cardinalidad y qué hace realmente una determinada expresión de filtro. Por supuesto, podrían descubrirlo mediante experimentación, pero sería arriesgado. Si se equivocan, corren el riesgo de perder los datos necesarios durante el evento o de no perder suficientes datos para mejorar significativamente la relación señal-ruido.
Tres niveles de conocimiento
Signal Studio funciona en tres niveles. Cada capa agrega más contexto y proporciona recomendaciones cada vez más específicas.
Capa 1: Análisis estático
Lo primero que hace Signal Studio es analizar su Collector YAML y visualizar la estructura de la canalización (receptor, procesador, exportador) agrupada por tipo de señal. Además, ejecuta un conjunto de reglas estáticas para detectar errores de configuración comunes, como limitadores de memoria faltantes, elementos indefinidos y receptores ilimitados.
Para cada hallazgo, la herramienta muestra la gravedad, una explicación de su importancia y un pequeño fragmento de YAML que sugiere posibles soluciones. En este punto, no se requieren conexiones de recopilador ni cambios en la configuración en vivo, por lo que el riesgo es muy bajo en comparación con los experimentos de tráfico en vivo.
Capa 2: Indicadores en tiempo real
Si bien el análisis estático de la herramienta puede indicarle qué está configurado, no puede responder a lo que realmente está sucediendo en el proceso. Conectar Signal Studio al punto final de métricas del recopilador agrega una dimensión instantánea.
El gráfico de canalización muestra el rendimiento, el porcentaje de caída y la utilización de la cola del exportador para cada señal. Esto permite reglas adicionales para detectar altas tasas de abandono, dominio del volumen de registros, saturación de colas y discrepancias en las tasas de receptor-exportador. Estos son problemas de tiempo de ejecución que el análisis YAML no puede revelar.
Si bien esto requiere establecer una conexión con el recolector, sigue siendo de solo lectura para garantizar que el radio de explosión se mantenga al mínimo y no cause ningún daño a su despliegue instantáneo. Signal Studio sondea el punto final métrico a intervalos configurables y calcula la tasa del lado del servidor. Si se pierde la conexión, el linting estático y cualquier resultado descubierto hasta el momento permanecerán sin cambios hasta que la conexión vuelva a estar disponible.
Capa 3: grifos de muestreo OTLP
Aquí es donde se pone interesante.
Signal Studio puede lanzar receptores OTLP livianos que admiten gRPC y HTTP, lo que le permite aprovechar los datos de telemetría utilizando el exportador de distribución en la configuración de Collector. Una vez que la telemetría comienza a fluir, Signal Studio cataloga el nombre del indicador, el tipo, los puntos y, lo más importante, los metadatos de los atributos. Vale la pena repetir en este punto que nada persiste, el directorio solo se almacena en la memoria.
Antecedentes de la consulta
«¿Por qué no simplemente consultar el backend?» Quizás te estés preguntando. Ésta es una pregunta legítima y, si bien es ciertamente posible, el enfoque tiene un grave defecto. El backend puede ver métricas de todas las fuentes, no solo de este recopilador.
Como puede imaginar, la atribución se vuelve muy complicada en el backend a menos que enriquezca los puntos de datos con metadatos adicionales. Este método es intrusivo y deja rastros de atribución en el backend. También aleja el análisis del proceso donde realmente es necesario cambiar.
previsibilidad de la memoria
El rastreador de atributos está limitado por diseño: almacena un máximo de 25 valores de muestra por clave de atributo por indicador y luego cambia al modo de solo recuento. Esto mantiene la memoria predecible y al mismo tiempo proporciona datos suficientes para realizar recomendaciones significativas.
Si la expresión del filtro hace referencia a un valor de propiedad que no se observa dentro de la ventana gráfica delimitada, el resultado se vuelve «desconocido» en lugar de inferirse. La herramienta no intenta adivinar valores invisibles ni predecir el comportamiento de cola larga. Esta es una simulación acotada del tráfico observado, no un estimador probabilístico.
Análisis de filtros de tuberías.
Al descubrir nombres y propiedades de métricas, Signal Studio puede hacer lo que el análisis estático por sí solo no puede: predecir qué hará un procesador de filtro antes de aplicarlo.
Analiza la sintaxis tradicional de inclusión/exclusión y expresiones modernas del lenguaje abierto de transformación de telemetría (OTTL), como name == "...", IsMatch(name, "...")igualdad de atributos, patrones de expresión regular y HasAttrKeyOnDatapoint.
Para cada métrica descubierta, la herramienta predice si el filtro la mantendrá o la descartará, o si no puede saberlo porque la cardinalidad del atributo es demasiado alta y la ventana gráfica de muestra no captura los valores relevantes.
Los resultados aparecen como una pastilla en la tarjeta de la tubería: algo así como -34%, lo que significa «Según nuestras observaciones, este filtro reducirá la cantidad de puntos de datos en aproximadamente un 34%». Pase el cursor sobre él y obtendrá instantáneamente la imagen completa: la ventana de observación, los puntos de datos totales evaluados y el nivel de confianza basado en el tamaño de la muestra.
El cálculo de confianza es simple y bien pensado: menos de 5000 puntos de datos observados se consideran «bajos», entre 5k y 50k se consideran «medios» y más de 50k se consideran «altos». Sin falsas precisiones. El umbral es intencionalmente heurístico y visible; el objetivo es transmitir el tamaño de la ventana gráfica, no la certeza estadística.
Si se hubiera aplicado un filtro aguas arriba en la tubería, estos puntos de datos nunca habrían llegado al grifo y no se podría evaluar su impacto.
Recomendaciones para comprender sus datos
La tercera capa de reglas (reglas de catálogo) es una combinación de análisis estático y descubrimiento sobre la marcha. Estas reglas solo se activan cuando hay datos de métricas reales disponibles, lo que permite hallazgos como el riesgo de cardinalidad debido a un alto recuento de atributos, ciertas métricas que dominan los datos o la conservación de la telemetría interna del recopilador.
Estas reglas cambian la conversación de «probablemente debería agregar un nuevo filtro» a «la métrica X tiene un atributo http.route de alta cardinalidad y es un fuerte candidato para la reducción de atributos». En varias implementaciones de producción que probé, una sola métrica representó aproximadamente el 60 % de la telemetría total del recopilador. Es difícil deducir esto con sólo leer YAML.
Recomendación precisa
Los consejos sólo son útiles si los lectores pueden comprenderlos y evaluarlos rápidamente. Deben ser concisos, precisos y coherentes.
Signal Studio utiliza un modelo simple: Evidencia → Implicación → Recomendación, envuelto en un indicador de confianza y etiquetas de rango.
El objetivo es facilitar que las personas decidan si tomar medidas o retrasarlas.
objetivo general
En la primera versión de Signal Studio, tomé algunas decisiones que dieron forma a la herramienta:
Sólo lectura a propósito.
Signal Studio nunca le escribirá a su cobrador. OTLP Tap es opcional y requiere que modifiques tu configuración. Esta fue una decisión bien pensada: la herramienta debería poder apuntar de forma segura a un entorno de producción sin causarle a nadie noches de insomnio.
Del mismo modo, no hay un botón «Aplicar», ni integración de GitOps ni proceso de implementación. El usuario mantiene el control. Esto puede parecer una característica faltante, pero es un límite de alcance intencional: las herramientas diagnostican, los humanos deciden. Aunque cada descubrimiento procesable contiene un fragmento de YAML que puede copiar directamente en la configuración del recopilador, usted es quien decide si incluirlo en su canalización y cuándo hacerlo.
Binario único, sin persistencia
Todo vive en la memoria. No hay base de datos ni archivos de estado. Esto hace que el despliegue sea trivial y mantiene pequeño el radio de la explosión. En este punto, no quiero preocuparme por los problemas de seguridad de administrar un almacén de telemetría en la sombra y todas las implicaciones de PII y las complejidades asociadas que conlleva, y es casi seguro que tampoco quiero hacerlo.
Sea honesto acerca de la incertidumbre
Por ejemplo: cuando el rastreador de atributos alcanza el límite superior de 25 valores de muestra, el análisis del filtro devuelve «desconocido» en lugar de una suposición. Se muestran los niveles de confianza para las píldoras previstas. Los hallazgos incluyen advertencias cuando las recomendaciones dependen del contexto (por ejemplo, la red de contenedores requiere el enlace 0.0.0.0).
Prometer demasiado erosiona la confianza más rápido que no cumplir lo suficiente, y cuando se trata de observables, normalmente sólo tienes una oportunidad de hacer una promesa, y eso es un hecho.
¿Qué hacer a continuación?
La herramienta ya ha estado a la altura de mi visión original y sólo obtendrá nuevas funciones si se considera lo suficientemente útil. Hay algunas preguntas abiertas sobre la validación de alertas, la detección de PII y la estimación de cardinalidad. Los exploraré por separado. La infraestructura programable sin una capa de diagnóstico parece incompleta y, aunque creo que los resultados de este experimento son sorprendentemente positivos,
Tengo curiosidad por saber cómo otros han verificado el impacto de los cambios de filtro antes de implementarlos en un recopilador OpenTelemetry de producción.
Puede contactarnos a través de los siguientes métodos Repositorio de proyectoso en Ubuntu Community Matrix.
