Diagnóstico local para sistemas POS
Detalles del proyecto
Por qué fue creado
El soporte veía un síntoma genérico —«la plataforma POS está caída»— mientras la causa real podía estar en decenas de procesos, puertos, patrones de log, bases de datos, interfaces HTTP o una dirección de nodo incorrecta. El diagnóstico manual dependía de la memoria de especialistas.
Lo que construí
Mapeé las dependencias de la plataforma a partir de incidentes en producción, diseñé el modelo de salud e implementé el agente en Rust, los recopiladores, la consola local, las acciones permitidas, el instalador y la documentación operativa.
Cómo está estructurado
- 01Recopilar
Recopiladores configurados mediante TOML inspeccionan procesos, puertos TCP, identidad de red, logs, integridad de bases de datos, verificaciones HTTP y recursos del host Windows sin fijar reglas específicas de cada unidad en el código.
- 02Correlacionar
El estado persistente correlaciona cambios de PID, posiciones de lectura de logs y avance del secuenciador fiscal para detectar ciclos de fallas y regresiones entre ciclos de recopilación.
- 03Actuar
Una API HTTP local sirve la consola web, endpoints JSON y métricas de Prometheus; una lista auditada de acciones permitidas habilita la recuperación sin ejecución arbitraria de comandos.
Restricciones y compromisos
+
Restricciones que dieron forma al sistema
- 01El agente debía ejecutarse en hosts Windows con pocas dependencias y sobrevivir a reinicios sin intervención.
- 02El diagnóstico debía seguir siendo útil cuando la ruta de red central no estuviera disponible.
- 03Los controles de recuperación no podían convertirse en un shell remoto genérico dentro de la tienda.
Compromisos de diseño
- 01Un binario Rust compacto y un conjunto reducido de dependencias priorizaron un despliegue predecible frente a un framework de observabilidad mayor.
- 02La operación local redujo inicialmente la visibilidad central, pero mantuvo el diagnóstico disponible durante incidentes de conectividad.
- 03Las acciones configuradas limitan la flexibilidad de forma deliberada; la seguridad y la auditoría importan más que el control arbitrario.
Otras decisiones de arquitectura
- Se priorizó un binario Rust compacto frente a un framework de observabilidad mayor para mantener el despliegue en Windows predecible y con pocas dependencias.
- La operación local preservó el diagnóstico durante fallas de conectividad central, aceptando inicialmente una menor visibilidad agregada de la flota.
Valor para la operación
Una indisponibilidad genérica pasó a indicar el componente, la causa probable y la siguiente acción permitida en un ciclo de diagnóstico de cinco segundos.
Principio de ingeniería
“Una buena observabilidad no produce más logs; conserva el estado y explica qué dependencia cambió antes de que apareciera el síntoma.”