Pharos

Las páginas de estado tienen un rasgo feo: casi todas mienten a su favor. Cuando una sonda deja de consultar un servicio, porque la propia monitorización se cayó o se acabó el periodo de retención, la mayoría de las herramientas simplemente no cuentan ese hueco en las estadísticas. El resultado es un gráfico que muestra un 100 por ciento de disponibilidad durante una ventana en la que nadie midió nada. A esto se suman las ventanas de mantenimiento que mágicamente nunca mellan la barra, y de repente tienes un panel que se ve estupendo y no significa nada.

Pharos lo construimos al revés. Es una herramienta que levantas con un solo comando, mantienes en tu propio servidor y en la que realmente se puede confiar, porque cuando no sabe, lo dice. No es otro panel en la nube con suscripción y retención ajena, sino un único archivo que copias junto al resto de tus servicios y ejecutas. Todo el resto de este caso práctico cuenta cómo una sola decisión en la fórmula de cálculo de la disponibilidad cambia el carácter de todo el producto.

La monitorización clásica conoce dos estados: el servicio funciona o no funciona. Es cómodo hasta que preguntas qué pasa cuando la monitorización no mira en absoluto. Porque entonces la herramienta tiene que hacer algo con ese tiempo, y la opción por defecto cae casi siempre en la misma trampa: trata el silencio como un éxito y lo suma en silencio a la barra "up". Así surgen esos absurdos 100 por ciento de un mes en el que en realidad la mitad de los datos no existe.

En nuestro caso cada tramo de vida de un servicio tiene tres estados, no dos. Disponible, caída y sin observación. El tercero es el quid de todo: es el tiempo en el que no recogimos datos, así que no tenemos derecho a afirmar que todo iba bien. En lugar de sumarlo hacia arriba, lo mostramos directamente como una parte aparte de la ventana. Las ventanas de mantenimiento se marcan, pero no borran las caídas del historial, solo separan lo planificado de lo inesperado.

La división en tres estados suena menor hasta que la ves en una ventana concreta. Toma un día en el que un servicio estuvo disponible la mayor parte del tiempo, se cayó por un momento, y durante un tramo nadie lo sondeó porque la máquina de monitorización se reinició sola. Un contador ingenuo suma el tiempo disponible con el no observado y escupe un porcentaje alto y vistoso. Un contador honesto muestra menos y añade que durante un rato no supo nada.

El mismo día, pasado por dos fórmulas distintas, da dos números completamente diferentes. Y esto no es cosmética: es la diferencia entre un informe en el que un cliente puede confiar y un informe que solo se ve bien en una reunión. Elegimos el menos vistoso, porque es el único que significa algo.

El mayor problema práctico de las herramientas de estado es cuánto hay que levantar a su alrededor antes de que muestren algo. Una base de datos aparte, una cola, un worker, un panel, un reverse proxy. Pharos va en la dirección contraria: toda la monitorización, el historial, la página de estado y la gestión de incidentes caben en un único ejecutable Go estático, y los datos los guarda un SQLite incorporado. No hay una base de datos separada que levantar y vigilar, ningún runtime que instalar. Copias el binario, lo ejecutas, y trabajas.

Esa simplicidad no es un ahorro en funciones, sino un recorte deliberado de la superficie de mantenimiento. Cuantas menos piezas móviles, menos cosas que pueden romperse a las tres de la madrugada. Un despliegue, un puerto, un log que repasar cuando algo sale mal.

Bajo un número honesto tiene que haber una fuente de datos honesta. Pharos consulta tus servicios a intervalo fijo por HTTP y TCP, y registra cada resultado individual junto con su tiempo de respuesta y una marca de tiempo. No promediamos nada al vuelo y no sobrescribimos el historial, porque es precisamente de ese flujo crudo de muestras del que luego se construyen los tres estados. Si no hay muestra para algún intervalo, ese intervalo está sin observación por definición, no por defecto.

Fíjate en dos cosas en este fragmento. El tiempo sin observación se omite en el denominador, no se suma hacia arriba. Y cuando no hubo observación alguna, la función devuelve NaN en lugar de un falso 100 por ciento, porque la ausencia de datos es ausencia de datos, no un éxito.

El escenario clásico de una caída es así: algo se cae, alguien lo ve, y empieza el salto entre el panel de monitorización, el chat y la página de estado. Tres ventanas, tres versiones de la verdad, y muchas probabilidades de que el estado público se aleje de lo que el equipo sabe de verdad. Pharos lo reduce a un solo lugar. Un incidente lo abres y lo llevas desde Discord, y la página de estado pública es solo un reflejo de lo que el equipo escribe de todos modos.

No hay una segunda herramienta que aprender ni riesgo de que el estado vaya por su cuenta, porque es la misma realidad vista desde dos lados. La apertura, las actualizaciones y el cierre los resuelves donde ya estáis, y la página se refresca sola.

Lo que salió es una herramienta que puedes poner en una máquina pequeña junto al resto de tus servicios y de la que luego puedes dejar de preocuparte. Un archivo, una base de datos incorporada, un puerto. El número en la página de estado significa exactamente lo que dice, y cuando la monitorización no sabe algo, no finge saberlo. Para el cliente que mira esa página, es la diferencia entre la confianza y una valla publicitaria.

El código es abierto, así que puedes leer toda esa fórmula por ti mismo en lugar de creernos bajo palabra. Es probablemente lo más honesto que una herramienta para contar honestamente la disponibilidad puede decir de sí misma.