Volver al blog
Tecnología 9 min de lectura

Lo difícil no es avisar de lo que pasa: es avisar de lo que no pasa

Un error se ve. El silencio hay que ir a buscarlo. Durante meses, una función central de GarBotGPT falló en todas y cada una de sus llamadas sin que saltara una sola alarma, porque no hubo error: hubo ausencia. Esto es lo que hemos construido para que no vuelva a ocurrir, y por qué el vigilante corre desde dos relojes que no se conocen entre sí.

Un latido regular que de pronto se queda plano, con la leyenda: aquí no hay error, hay silencio

Hay una forma de fallar que no aparece en ningún registro de errores, que no dispara ninguna alarma y que puede durar meses. No es que algo se rompa. Es que algo deja de ocurrir.

Nos pasó. Y merece la pena contarlo entero, porque la lección no va de monitorización: va de qué tipo de problemas es capaz de ver un sistema, y cuáles le son invisibles por construcción.

Meses fallando, cero alarmas

GarBotGPT tiene una función interna que crea los avisos que ves en la campana: un trabajo que termina, un pago que no ha pasado, alguien que te menciona en un canal. Durante meses, esa función falló en todas y cada una de sus llamadas. Ni una sola notificación llegó a su destino.

No saltó nada. Y no saltó por dos motivos que se tapaban el uno al otro:

  • La librería que habla con nuestra base de datos no lanza una excepción cuando la base rechaza algo: devuelve el error como un valor, dentro de la respuesta. Un bloque que capture excepciones alrededor no captura nada, porque no hay nada que capturar.
  • Y ese valor no se miraba. Se llamaba a la función, se seguía adelante, y el error se iba a la basura sin que nadie lo leyera.

El resultado es la peor combinación posible: un fallo del 100 % que desde fuera se ve exactamente igual que "hoy no ha pasado nada digno de aviso".

Se descubrió de casualidad, montando otra cosa. Un trabajo largo terminaba bien, el aviso no aparecía por ningún lado, y tirando de ese hilo apareció todo lo demás.

El patrón, que se repite

Cuando fuimos a mirar, no era un caso aislado. Era el mismo patrón otras dos veces:

  • El sistema que construye y publica la aplicación se quedó atascado. Los despliegues seguían diciendo que sí, y lo que se publicaba era la versión anterior. Nadie vio un error: vieron cambios que no aparecían.
  • Los certificados de seguridad de uno de los servidores se renovaron correctamente y no llegaron a aplicarse al puerto que los usa. La renovación funcionó. La aplicación no. Entre las dos cosas, silencio.

Tres incidentes distintos, la misma forma: algo dejó de pasar y no había nadie escuchando el silencio.

Por qué la monitorización normal no lo ve

Casi todas las alarmas que existen en cualquier aplicación son reactivas. Se disparan cuando ocurre algo: una excepción, un código de error, una respuesta lenta. Son buenísimas para lo que se rompe con ruido.

El problema es que la ausencia no hace ruido. Si el proceso que debía ejecutarse a las tres de la mañana no se ejecuta, no hay excepción que capturar ni petición que registrar. Hay un hueco. Y un hueco solo se ve si alguien está contando los huecos.

Para eso hace falta cambiar la pregunta. En vez de "¿ha fallado algo?", hay que preguntar "¿cuánto hace que no sé nada de esto?".

Latidos: la parte fácil

La mitad de la solución es sencilla. Cada proceso periódico deja constancia de que ha pasado por ahí. Una fila, una hora, nada más. Es un latido.

Con eso, la pregunta se vuelve contestable. El motor de trabajos en segundo plano se anuncia cada cinco segundos: si lleva quince minutos callado, está muerto. El programador de recordatorios pasa cada cinco minutos: si lleva media hora sin aparecer, los recordatorios de la gente no están saltando, aunque nadie se haya quejado todavía.

Y esa última distinción es la que importa. Sin latido, un programador muerto y un programador ocioso se ven exactamente igual desde fuera: en los dos casos no pasa nada. El latido es lo único que los separa.

El vigilante y su propio punto ciego

La otra mitad es más interesante, porque tiene una trampa lógica.

Si escribes un vigilante que comprueba que todo sigue vivo, te queda una pregunta incómoda: ¿quién vigila al vigilante? Un proceso no puede avisar de su propia muerte. Si se cae, se cae también su capacidad de contarlo.

La respuesta que hemos dado es tener dos relojes que no comparten nada:

  • Uno es un contenedor que corre en nuestro propio servidor y dispara el motor de trabajos cada pocos segundos.
  • El otro es un programador externo que llama a la aplicación cada cinco minutos desde fuera.

Los dos pasan revista. Si se cae el externo, lo nota el de casa. Si se cae el de casa, lo nota el externo. Para que el fallo pase desapercibido tendrían que caerse los dos a la vez, y son dos infraestructuras distintas.

Aun así, ese caso existe. Y ahí hemos preferido decir la verdad antes que fingir una cobertura que no tenemos: si se para todo, no hay aviso, porque no queda nadie para mandarlo. Lo que sí queda es la hora del último latido, visible en el panel de administración sin depender de que nada esté corriendo. Si la fila dice "hace tres días", el problema está a la vista en cuanto alguien abre la pantalla.

Detectar la caída total desde dentro es imposible. Lo honesto es decirlo, no dibujar un punto verde que no significa nada.

Avisar solo cuando algo cambia

Un vigilante que avisa cada cinco minutos no es un vigilante: es ruido con uniforme. A la tercera vez se ignora, y la cuarta era la de verdad.

Así que el sistema guarda el estado de cada comprobación y solo habla en los cambios:

  • Cuando algo se rompe, avisa.
  • Cuando vuelve a funcionar, también avisa. Saber que ya va es tan útil como saber que se ha caído, y ahorra ir a comprobarlo.
  • Y mientras siga roto, lo recuerda una vez al día. Ni se olvida ni cansa.

Y el aviso no puede viajar por el sistema averiado

Este detalle parece pequeño y es el que lo sostiene todo.

Los avisos de GarBotGPT van por una cola: se encolan, y un proceso los reparte. Es lo correcto — permite respetar tus preferencias, tus horas de silencio y juntar varios en uno.

Pero una de las cosas que el vigilante comprueba es si esa cola está parada. Y si lo está, encolar el aviso de "la cola está parada" es escribir la nota dentro de la caja cerrada.

Por eso los avisos de infraestructura salen por entrega directa, saltándose la cola a propósito. Es la excepción que justifica que el camino antiguo siga existiendo.

Qué cambia para ti

Si usas GarBotGPT, esto se nota poco, y ese es el objetivo. Lo que sí cambia:

  • Si un recordatorio tuyo vence y no salta, alguien se entera. Antes, ni tú ni nosotros.
  • Si un trabajo en segundo plano se queda colgado, deja de quedarse colgado para siempre.
  • Y si el sistema que reparte los avisos se para, el aviso de que se ha parado llega igual.

La idea que nos llevamos

Un sistema solo puede detectar los fallos que ha decidido buscar. El nuestro sabía buscar errores y no sabía buscar silencios, así que durante meses tuvimos un fallo del 100 % que parecía tranquilidad.

Ahora también contamos los huecos. Y si algún día vuelve a haber un silencio largo, la diferencia es que tendrá quien lo escuche.

Prueba todo esto en GarBotGPT.

500 créditos gratis, sin tarjeta. Modelos top, herramientas en vivo y RAG sobre tus propios documentos.