Cuando todo en tu panel de monitoreo luce verde, pero ningún dato llega a tu backend, sabes que algo no encaja. Eso fue exactamente lo que ocurrió al intentar autohospedar SigNoz para validar cómo una librería de instrumentación OpenTelemetry capturaba errores en herramientas del Model Context Protocol (MCP). El objetivo era sencillo: demostrar que un servidor MCP puede devolver un error lógico (isError: true) dentro de una respuesta JSON-RPC exitosa, y que la traza refleje correctamente ese fallo como un span ERROR con el atributo error.type=tool_error. La librería funcionaba, los spans se generaban con la forma esperada, pero la interfaz de SigNoz permanecía vacía. La causa no estaba en el código, sino en la infraestructura.
Autohospedar herramientas de observabilidad como SigNoz es una decisión que muchas empresas toman para mantener el control de sus datos y evitar costos recurrentes en la nube. Sin embargo, el camino no siempre está libre de obstáculos. La documentación reciente indica que SigNoz ha migrado su despliegue a Foundry, un enfoque que simplifica la configuración centralizada mediante archivos casting.yaml y el agente OpAMP. Esto permite gestionar flotas de recolectores sin redeploy, una funcionalidad potente que, cuando falla, puede dejar al operador sin pistas. En nuestro caso, el receptor OTLP en el puerto 4318 nunca se vinculó porque la configuración efectiva se descargaba vía OpAMP con un esquema incompatible, mientras el archivo local ingester.yaml, aunque correcto, era ignorado.
El problema se agrava cuando la máquina anfitriona tiene recursos justos. Con 7.28 GB de RAM total y Docker Desktop asignando 3.47 GB a la VM WSL2, el contenedor de SigNoz apenas cumplía el mínimo recomendado de 4 GB. Las migraciones de base de datos fallaban con 'unexpected EOF', y el bloqueo persistía porque el registro migration_lock sobrevivía a los reinicios. Fue necesario limpiar esa fila manualmente desde psql. Este tipo de fallos silenciosos son los más difíciles de diagnosticar, especialmente cuando cada indicador de salud responde con un HTTP 200.
Desde la perspectiva de una empresa de desarrollo de software como Q2BSTUDIO, especializada en aplicaciones a medida, este caso refuerza una lección clave: la observabilidad no solo depende de las herramientas, sino de cómo se integran con el resto del ecosistema. Cuando desarrollamos soluciones de IA, ciberseguridad o cloud AWS/Azure para nuestros clientes, la telemetría fiable es un requisito no negociable. Un sistema que aparenta estar saludable mientras ignora los errores reales puede llevar a decisiones equivocadas. Por eso, en los proyectos de BI / Power BI que abordamos, siempre priorizamos la validación de los pipelines de datos antes de confiar en los dashboards.
El incidente también evidenció un problema habitual en entornos multilingüe: la duplicación de dependencias. Al ejecutar npm install desde el directorio del ejemplo en lugar de la raíz del repositorio, se generaron dos copias de @opentelemetry/api y @modelcontextprotocol/sdk, lo que silenció completamente los spans. El resultado no fue un error, sino un vacío informativo, el peor escenario para cualquier tarea de depuración. La solución fue registrar el ejemplo como miembro del workspace, compartiendo una sola instancia de cada paquete.
Otro punto crítico apareció al final del proceso: el BatchSpanProcessor de OpenTelemetry utiliza un temporizador unref() que, en scripts de corta duración, permite que el proceso termine antes de que el lote sea exportado. Los spans se perdían sin llegar al backend. Una llamada explícita a flush() al cerrar stdin resolvió el problema. Esta sutileza es fácil de pasar por alto cuando se prueba una librería, pero en producción puede significar la diferencia entre un sistema observable y uno que oculta sus fallos.
El resultado final fue agridulce: la librería opentel-mcp efectivamente captura el error lógico en MCP y lo transforma en un span ERROR con el atributo tool_error. Sin embargo, nunca pudimos visualizarlo en la UI de SigNoz porque el ingestor no estaba escuchando. La lección más valiosa fue aprender a verificar el listener real (cat /proc/net/tcp dentro del contenedor) en lugar de confiar en archivos de configuración o paneles verdes. En un mundo donde cada vez más empresas adoptan agentes IA y sistemas basados en MCP, contar con herramientas de observabilidad que funcionen de extremo a extremo es fundamental. Y si decides autohospedarlas, recuerda: el color verde no siempre significa que todo está bien.
