Cuando empecé a construir un sistema de inteligencia artificial que aprendía de las consultas repetitivas de los usuarios, pensé que la parte más compleja sería el algoritmo. Pero pronto descubrí que el verdadero desafío no era entrenar al modelo, sino entender qué estaba pasando dentro de la aplicación una vez que entraba en producción. Las trazas se perdían, los logs eran un caos y cualquier fallo requería horas de depuración con print statements. Fue entonces cuando decidí probar SigNoz, una plataforma de observabilidad basada en OpenTelemetry que prometía cambiar esa dinámica.
Mi proyecto consistía en un agente de IA que analizaba patrones en peticiones SQL, almacenaba la confianza en las reglas aprendidas y, tras suficientes ejemplos, comenzaba a aplicarlas automáticamente. Necesitaba respuestas a preguntas como: ¿Qué ocurrió durante esta petición? ¿Qué componente consumió más tiempo? ¿Se recuperó la regla correcta? ¿Cómo evolucionó la confianza? Con registros tradicionales era imposible. Así que instrumenté mi aplicación FastAPI con OpenTelemetry, creando spans para cada operación clave: recepción de la petición, evaluación SQL, recuperación de reglas, inyección de guía, creación de evidencias, actualización de confianza y cierre del ciclo de vida. Cada petición generaba un trace completo, y ver toda la línea temporal en lugar de scroll infinito de logs fue un alivio.
Además, empecé a exportar métricas personalizadas: número total de peticiones, nivel de confianza por regla, cantidad de evidencias, ratio de seguridad SQL. Estos datos aparecían automáticamente en los dashboards de SigNoz, pero lo que realmente me cautivó fue el explorador de trazas. Al pinchar en un trace podía ver cada span con sus atributos: clasificación, confianza, patrones SQL detectados, duración, nombre del servicio. En lugar de adivinar qué falló, podía inspeccionar la petición completa y reproducirla. Esto redujo drásticamente el tiempo de depuración.
Un hallazgo importante fue que no debería haber esperado a tener el proyecto terminado para añadir observabilidad. Integrar OpenTelemetry desde el primer día habría facilitado el desarrollo y evitado tener que revisar medio código después. Esta lección me llevó a replantear cómo enfocamos los proyectos en Q2BSTUDIO, donde ofrecemos desarrollo de software a medida, soluciones cloud en AWS y Azure, ciberseguridad, Business Intelligence con Power BI y automatización de procesos. La observabilidad no es un extra, es parte fundamental de cualquier sistema moderno, especialmente cuando trabajamos con agentes de IA que toman decisiones autónomas.
Por ejemplo, en un entorno cloud, desplegar SigNoz en Kubernetes con escalado automático nos permitió monitorizar aplicaciones con miles de peticiones por segundo. Los datos de trazas y métricas se integraron con nuestros dashboards de Power BI, ofreciendo una visión unificada del rendimiento y la seguridad. Además, la ciberseguridad se benefició de poder auditar cada petición y detectar anomalías en tiempo real. Si estás desarrollando aplicaciones a medida, te recomiendo que no esperes a que surja un problema: implementa observabilidad desde el inicio. Puedes empezar con herramientas como SigNoz y OpenTelemetry, pero el verdadero valor está en la cultura de entender qué pasa dentro de tu software. En Q2BSTUDIO te ayudamos a diseñar esa cultura, desde la instrumentación hasta la visualización.
Este proyecto cambió mi forma de depurar. Ya no pregunto '¿por qué falló mi código?', sino '¿qué ocurrió exactamente durante esta petición?'. Ese pequeño cambio hizo que la depuración dejara de ser frustrante. Si estás construyendo algo más complejo que una API simple, prueba la observabilidad mucho antes de lo que yo lo hice. Y si necesitas apoyo, no dudes en contactar con nosotros para integrar aplicaciones a medida con una base sólida de monitoreo y análisis.
