Vigilancia propia o servicio externo: cómo elegir

Un script de vigilancia son veinte líneas. Precisamente por eso la pregunta merece una respuesta honesta en lugar de un argumentario: para un sitio único y con poco en juego, escribir el tuyo suele ser la decisión correcta, y nadie tiene interés en decírtelo.

El comparativo, sobre los criterios que deciden

Solo una fila de esta tabla es eliminatoria, y es la cuarta. Todo lo demás se recupera con tiempo; una sonda que muere con la máquina que vigila, no. Esa fila se descarta al diseñar y se recuerda a las tres de la madrugada: el escenario para el que existe tu vigilancia es exactamente aquel en el que una sonda alojada en la misma máquina ya se ha detenido.

Escribirlo tú mismo: cuándo es la buena elección

Un sitio, un servidor, una persona. Una tarea cron que consulta tu portada y te envía un correo si el código no es 200 funciona. Cuesta una tarde y nada al mes.

Una necesidad particular. Comprobar algo dentro de tu aplicación, el tamaño de una cola, una cifra de negocio, el estado preciso de una base: ningún servicio externo puede hacerlo sin un acceso que no habría que darle.

El gusto de hacerlo. Una razón legítima, y a menudo la más fuerte. Un script que has escrito es un script que sabrás reparar.

Una condición, en los tres casos: la sonda debe ejecutarse en otro sitio que no sea la máquina vigilada. Una máquina de cinco euros al mes en otro proveedor, o una ejecución programada en un tercero, basta. Sin eso, has escrito una herramienta que calla justo cuando debería hablar.

Los tres muros con los que se acaba topando

La comprobación se ejecuta en la máquina vigilada. Si el servidor cae, el script cae con él. La avería que nadie detecta es justamente aquella en la que todo está en el suelo a la vez, y es para esa para la que lo habías escrito.

El historial desaparece. Saber que el sitio está caído ahora es la mitad fácil. Responder a «qué disponibilidad tuvo el mes pasado» supone guardar cada comprobación, gestionar la retención y saber recalcular una tasa cuando había una ventana de mantenimiento prevista. Ahí es donde un proyecto de fin de semana se convierte en una pequeña base de datos que mantener.

Escala mal. Un sitio, veinte líneas. Veinte sitios, una rotación de intervalos, falsas alarmas que ajustar, alertas que se paran sin que nadie se dé cuenta, y un cliente que reclama un informe mensual. Organizar un parque es un oficio en sí mismo, y no es aquel para el que se escribió el script. La transición rara vez es una decisión; ocurre poco a poco, un sitio tras otro, hasta que una tarde desaparece manteniendo algo que debía costar una velada.

Las cuatro trampas del script propio, en el orden en que aparecen

Ninguna es insuperable. Todas se descubren después, y ese es el problema.

El correo de alerta no llega. Un servidor que envía correo desde su propia dirección IP acaba en spam, o en ninguna parte. Uno se entera el día en que esperaba la alerta, es decir demasiado tarde. La corrección es sencilla, un servicio de envío transaccional, y añade una dependencia más que vigilar.

El script se para sin decirlo. Una actualización de lenguaje, una ruta que cambia, una cuota alcanzada: la tarea programada falla en silencio. Un script de vigilancia necesita ser vigilado, lo cual es lógicamente incómodo y prácticamente cierto. La defensa cabe en una línea: haz que envíe una señal de vida semanal, cuya ausencia te alerte.

Los falsos positivos acaban ganando. Sin confirmación ni memoria de estado, un script envía un correo a cada hipo de red. Al cabo de tres semanas nadie los abre, y la vigilancia sigue existiendo sin servir para nada.

Nadie más sabe repararlo. El día en que estás de vacaciones, el script es una caja negra escrita en un estilo personal, sin documentación. Es aceptable para un sitio personal, mucho menos en cuanto un cliente depende de la respuesta.

El coste real, en tiempo

Es el único argumento serio, y el que los comparativos evitan porque no cabe en una tabla de precios.

Escribirlo cuesta una tarde. El resto llega a rodajas: una hora cuando el proveedor de correo cambia sus reglas, dos horas el día en que caduca el certificado de tu propia sonda, media jornada para añadir el historial cuando un cliente lo pide, y una tarde la primera vez que descubres que el script llevaba seis semanas sin ejecutarse.

Cuenta uno o dos días al año, repartidos en el peor momento, siempre mientras hacías otra cosa. Compáralo con una suscripción, teniendo presente que tu jornada probablemente vale más de lo que cuesta un año de ella.

Lo que compra realmente un servicio externo

No la comprobación en sí: sabes escribirla. Compra el punto de vista exterior, el historial que no has tenido que almacenar, y el hecho de que la cosa siga funcionando cuando tu infraestructura ya no funciona.

Y la parte en la que nadie piensa al principio: alguien más la mantiene. Un script de vigilancia que dejó de funcionar hace tres meses es peor que ninguna vigilancia, porque sigues creyéndote cubierto. Es la avería silenciosa más frecuente del sector, y la única que su víctima no puede detectar por definición.

El montaje híbrido, que es lo que hacen la mayoría de los equipos serios

No es un compromiso blando, es la respuesta correcta en cuanto el sistema pasa de un sitio.

La vigilancia de infraestructura se queda contigo: disco, memoria, colas, cifras de negocio. Ve lo que un exterior no puede ver, y tiene derecho a caer con la máquina, puesto que es la máquina lo que describe.

La vigilancia de sitio viene de fuera: el código de respuesta, el tiempo de respuesta, el certificado, el contenido esperado en la página. Ve lo que ven tus visitantes, y es el único punto de vista que sigue siendo válido cuando todo lo demás está en el suelo. Es además la única que responde a la pregunta que tu alojamiento no responderá jamás.

Las dos no se sustituyen. Responden a dos preguntas distintas, y confundirlas es la causa más frecuente de una vigilancia que tranquiliza sin proteger.

Una regla de decisión honesta

Parte de lo que perderías durante tres horas de caída, y del número de sitios de los que te ocupas. La primera cifra se calcula en cinco minutos, la segunda ya la conoces.

• Un sitio, poco en juego → escríbelo tú mismo, ejecútalo en otra parte, y comprueba una vez por trimestre que sigue disparándose.
• Varios sitios, o un cliente de por medio → un servicio externo se amortiza en el tiempo que dejas de dedicar a mantenerlo.
• Necesidades profundas dentro de la aplicación → los dos, en puestos distintos.

El mismo arbitraje se repite, idéntico, sobre otro objeto: seguir tus backlinks en una hoja de cálculo llevada a mano aguanta mucho tiempo, y luego deja de aguantar por exactamente las mismas razones. La hoja, sus siete columnas y su fecha de caducidad cuentan la misma historia con otras filas.

Y sea cual sea tu elección, la cuestión del intervalo queda entera: se resuelve a partir del coste, no de la técnica. Lo primero que hay que hacer después, el día en que algo cae, es lo mismo en ambos casos: los primeros quince minutos no dependen de la herramienta.