Quan tot al teu panell de monitoratge està verd però cap dada arriba al teu backend, saps que alguna cosa no encaixa. Això va ser exactament el que va passar en intentar autohostejar SigNoz per validar com una llibreria d'instrumentació OpenTelemetry capturava errors en eines del Model Context Protocol (MCP). L'objectiu era senzill: demostrar que un servidor MCP pot retornar un error lògic (isError: true) dins d'una resposta JSON-RPC exitosa, i que la traça reflecteixi correctament aquesta fallada com un span ERROR amb l'atribut error.type=tool_error. La llibreria funcionava; els spans es generaven amb la forma esperada, però la interfície de SigNoz romania buida. La causa no era al codi, sinó a la infraestructura.
Autohostejar eines d'observabilitat com SigNoz és una decisió que moltes empreses prenen per mantenir el control de les seves dades i evitar costos recurrents al núvol. No obstant, el camí no sempre està lliure d'obstacles. La documentació recent indica que SigNoz ha migrat el seu desplegament a Foundry, un enfocament que simplifica la configuració centralitzada mitjançant fitxers casting.yaml i l'agent OpAMP. Això permet gestionar flotes de recol·lectors sense redeploy, una funcionalitat potent que, quan falla, pot deixar l'operador sense pistes. En el nostre cas, el receptor OTLP al port 4318 mai es va vincular perquè la configuració efectiva es descarregava via OpAMP amb un esquema incompatible, mentre el fitxer local ingester.yaml, tot i ser correcte, era ignorat.
El problema s'agreuja quan la màquina amfitriona té recursos ajustats. Amb 7.28 GB de RAM total i Docker Desktop assignant 3.47 GB a la VM WSL2, el contenidor de SigNoz amb prou feines complia el mínim recomanat de 4 GB. Les migracions de base de dades fallaven amb 'unexpected EOF', i el bloqueig persistia perquè el registre migration_lock sobrevivia als reinicis. Va ser necessari netejar aquesta fila manualment des de psql. Aquests tipus de fallades silencioses són les més difícils de diagnosticar, especialment quan cada indicador de salut respon amb un HTTP 200.
Des de la perspectiva d'una empresa de desenvolupament de programari com Q2BSTUDIO, especialitzada en aplicacions a mida, aquest cas reforça una lliçó clau: l'observabilitat no només depèn de les eines, sinó de com s'integren amb la resta de l'ecosistema. Quan desenvolupem solucions d'IA, ciberseguretat o cloud AWS/Azure per als nostres clients, la telemetria fiable és un requisit no negociable. Un sistema que aparenta estar saludable mentre ignora els errors reals pot portar a decisions equivocades. Per això, en els projectes de BI / Power BI que abordem, sempre prioritzem la validació dels pipelines de dades abans de confiar en els dashboards.
L'incident també va evidenciar un problema habitual en entorns multillenguatge: la duplicació de dependències. En executar npm install des del directori de l'exemple en lloc de l'arrel del repositori, es van generar dues còpies de @opentelemetry/api i @modelcontextprotocol/sdk, cosa que va silenciar completament els spans. El resultat no va ser un error, sinó un buit informatiu, el pitjor escenari per a qualsevol tasca de depuració. La solució va ser registrar l'exemple com a membre del workspace, compartint una sola instància de cada paquet.
Un altre punt crític va aparèixer al final del procés: el BatchSpanProcessor d'OpenTelemetry utilitza un temporitzador unref() que, en scripts de curta durada, permet que el procés finalitzi abans que el lot sigui exportat. Els spans es perdien sense arribar al backend. Una crida explícita a flush() en tancar stdin va resoldre el problema. Aquesta subtilesa és fàcil de passar per alt quan es prova una llibreria, però en producció pot significar la diferència entre un sistema observable i un que oculta les seves fallades.
El resultat final va ser agredolç: la llibreria opentel-mcp efectivament captura l'error lògic a MCP i el transforma en un span ERROR amb l'atribut tool_error. Tanmateix, mai vam poder visualitzar-lo a la UI de SigNoz perquè l'ingestor no estava escoltant. La lliçó més valuosa va ser aprendre a verificar el listener real (cat /proc/net/tcp dins del contenidor) en lloc de confiar en fitxers de configuració o panells verds. En un món on cada cop més empreses adopten agents IA i sistemes basats en MCP, disposar d'eines d'observabilitat que funcionin de punta a punta és fonamental. I si decideixes autohostejar-les, recorda: el color verd no sempre significa que tot està bé.
