Senticor · Código abierto · Prealfa
Vaktaro: comprobaciones de servicios y OpenTelemetry
Un proyecto de código abierto de Senticor conecta comprobaciones propias con la supervisión existente, con estados de resultado explícitos y un recorrido probado hasta el panel.
Situación: otra sonda debe justificar su función
Un servicio puede ser accesible desde una red y no desde otra. Recoger más mediciones solo ayuda si los operadores pueden interpretarlas, asociarlas con una ubicación y distinguir entre un fallo del servicio y la ausencia de resultados.
- Grafana Cloud Synthetic Monitoring ya ofrece sondas públicas y privadas con resultados en su plataforma gestionada.
- Uptime Kuma ofrece comprobaciones, notificaciones y páginas de estado en alojamiento propio.
- Prometheus con blackbox exporter incorpora sondas de servicios a un entorno gestionado por el operador.
Vaktaro estudia nodos independientes, resultados en sistemas de análisis existentes y cooperación futura entre participantes invitados. Es una hipótesis concreta dentro de un mercado establecido. El valor de la cooperación automática entre nodos sigue pendiente de demostración.
Tarea y mi contribución
Mi trabajo abarcó la implementación de las comprobaciones, el modelo de telemetría, la integración del colector y la validación del ejemplo de despliegue. La tarea inmediata era disponer de un nodo útil: comprobar servicios configurados, conservar resultados localmente y entregar información interpretable a un entorno operativo existente.
El diseño separa la comprobación del transporte, el análisis y la respuesta a incidentes. Así, un nuevo agente no asume todas las funciones operativas. La integración y sus posibles fallos siguen siendo responsabilidades explícitas.
Acciones: convertir mediciones en información operativa
Definir qué demuestra una comprobación
Las comprobaciones HTTP(S) registran estado de respuesta, duración y caducidad del certificado. Se verifica el certificado y se delimitan destinos permitidos, redirecciones y tiempos de espera. Una petición correcta aporta evidencia desde ese nodo; no demuestra que funcionen todos los recorridos de usuario ni todas las rutas de red.
Separar evidencia local y recogida remota
El nodo conserva resultados y emite eventos JSON estructurados. Grafana Alloy se encarga del envío. El ejemplo entrega registros a Loki para consultas de Grafana; una alternativa convierte eventos en registros OpenTelemetry para un destino configurable. Son rutas alternativas. El nodo no necesita panel propio, envío de alertas ni exportador nativo OpenTelemetry para aportar resultados útiles.
Diseñar estados y estructura de datos para el diagnóstico
Las comprobaciones pendientes, la ausencia de datos y los fallos registrados deben distinguirse. Las vistas muestran esos estados sin interpretar un resultado ausente como una caída confirmada. La identidad del punto de medición permite comparar. Las URL permanecen en el evento o en metadatos estructurados, sin crear un flujo de registros indexado por cada destino.
Probar el recorrido completo del resultado
El entorno de integración ejecuta un nodo real, colector, almacenamiento y consultas del panel. Comprueba la entrega, los campos OpenTelemetry y cada consulta del ejemplo, incluso al instalar en otro espacio de nombres de Kubernetes. Así detecta supuestos de configuración que un contenedor activo o una captura no muestran. Se prueban los datos que sostienen la vista.
Elegir el siguiente cambio con pruebas de capacidad
Las mediciones con recursos limitados comparan ejecución prevista y real. Identificaron la sobrecarga del modelo de un hilo por destino como límite de escalado, aportando razones para rediseñar la concurrencia. Las compilaciones de medición con límites elevados se distinguen del nodo soportado; sus cifras no prometen capacidad productiva.
Resultados: implementación y límites
Implementado
El repositorio proporciona comprobaciones HTTP(S), resultados locales, un flujo de eventos definido, configuración del colector y un ejemplo reproducible Loki/Grafana. Los puntos de medición independientes pueden compararse en una vista común. La integración OpenTelemetry transporta actualmente registros.
Evidencia disponible para revisión
El código, las especificaciones, las pruebas de integración y la metodología de capacidad son públicos. Explican tanto el comportamiento probado como los límites de las mediciones. Permiten revisar implementación y ejemplos sin depender únicamente de una demostración del producto.
Límite operativo
Vaktaro sigue en prealfa. La red entre pares, las evaluaciones conjuntas automáticas y las métricas y spans OpenTelemetry nativos están previstos. Las alertas existentes conservan la responsabilidad de notificar. El entorno de evaluación no tiene almacenamiento persistente ni autenticación; el despliegue exige responsables de retención, acceso, mantenimiento e incidentes. No se ha demostrado ahorro ni reducción de interrupciones.
Lecciones para decisiones de supervisión
- Modelar la incertidumbre antes de automatizar: Desconocido, retrasado y fallido son entradas diferentes para decidir sobre un incidente. Unificarlas genera confianza injustificada.
- Permitir revisar la integración: Significado de eventos, identidad del nodo, campos almacenados y consultas deben concordar. Un producto de supervisión incluye ese contrato operativo, además de la sonda.
- Medir el trabajo relevante: El servicio entregado son comprobaciones completas y puntuales. Los límites de CPU y memoria no prueban capacidad; las pruebas simplificadas y compilaciones modificadas necesitan límites explícitos.
- Adoptar gradualmente: Validar todo el recorrido en un entorno limitado, conservar las alertas existentes y asignar responsabilidades antes de depender de la nueva señal.
Proyecto y documentación
Arquitectura: nodos de comprobación y contrato de telemetría
El diagrama separa comprobaciones activas, evidencia local y entrega. Las dos salidas documentadas son alternativas; la cooperación prevista entre nodos queda fuera del flujo actual.
Descripción textual del diagrama
- El nodo envía peticiones HTTP(S) a los servicios configurados. El estado, tiempo de respuesta y certificado reflejan la perspectiva de ese punto de medición.
- Los resultados locales y eventos JSON estructurados forman la interfaz con la recopilación. La ausencia de datos, las comprobaciones pendientes y los fallos registrados son estados distintos.
- Grafana Alloy lee los eventos. En el ejemplo envía logs a Loki, consultados por Grafana. Como alternativa, convierte eventos en registros OpenTelemetry y los exporta por OTLP a un backend elegido.
- Los caminos son alternativos, no etapas consecutivas. No hay un flujo de Loki a OTLP ni exportación nativa de métricas o spans desde el nodo.
- El entorno de integración comprueba la llegada de resultados y las consultas del panel. El bloque futuro describe la cooperación prevista entre nodos invitados; la alarma existente permanece fuera del nodo.
Servicios y proyectos
Contacto
Envíe el proyecto, los requisitos y los plazos por correo electrónico.