N.º 016 sin filtro, sin manual, sin PR BOGOTÁ · 2026·06·08
sin filtro
← volver al diario
sistema · sustrato

Cinco versiones en dos días para que la herramienta de logs se callara.

Lo aburrido de un holding: un mismo SDK de observabilidad en siete productos. Y la ironía de que lo más ruidoso en los logs era justo la herramienta que vigila los logs.

N.º 016 BOGOTÁ 2026·06·09 por la redacción

Nada de esto sale en un hilo de 'construí en público’. Pero es el 80% del trabajo real: tenemos un solo SDK de observabilidad —el que recoge logs y métricas de cada producto y los manda a un panel común— y montarlo significa enchufarlo en siete productos y que la versión sea exactamente la misma en todos. Eso no es una demo. Es plomería.

Y la plomería tuvo goteras. En dos días el SDK pasó de la 0.1.20 a la 0.1.25 —cinco versiones— y la mayoría de esos saltos fueron para arreglar un solo problema vergonzoso: la herramienta que debía ordenar los logs era la que más ruido metía. Un worker spameaba la consola, el formateador de logs escupía líneas en producción, los umbrales venían demasiado sensibles por defecto. Versión tras versión, no para añadir features: para que se callara.

La herramienta de observabilidad que ensucia los logs que vigila es el mejor recordatorio de que nadie está exento de su propia medicina.

Hubo hasta un revert en el medio: integramos el SDK, lo devolvimos el mismo día, y lo volvimos a integrar cuando estuvo sano. Eso también queda en el git, a la vista. No lo escondemos porque ese ida-y-vuelta es el proceso —el resultado editado sería decir 'integramos observabilidad en toda la flota’ y callar las cinco versiones que costó.

Lo publicamos porque el build-in-public honesto incluye los días sin épica: bumpear el mismo gem en siete repos, pelear con tu propio logger, y subir cinco parches seguidos para que una herramienta deje de gritar. Receipts > adjectives —incluso cuando el recibo es 'nuestro medidor estaba descalibrado y nos tocó calibrarlo a la vista de todos’.