Cómo monitorizar un Pi 4 en un sitio remoto cuando se cae la red

Un Pi 4 que corre Grafana, un broker MQTT y un pequeño registrador de datos lleva ocho meses funcionando sin incidencias en una ubicación remota. El mes pasado hubo un corte de luz y, cuando volvió la corriente, el equipo seguía respondiendo, pero dos de los servicios no arrancaron. Desde fuera parecía sano; por dentro estaba medio roto y nadie se enteró.

Lo que busca su dueño no es monitorización al uso, sino monitorización que sobreviva a la caída de la red. La conexión de ese sitio se corta a menudo, así que cualquier alerta que viaje por ella está ciega justo en el momento en que hace falta. Un monitor instalado en el propio Pi tampoco arregla nada: si la máquina no ha arrancado, no hay nadie que mande el aviso. Y herramientas como el monitor de Tailscale siguen dando por supuesto que el dispositivo está en línea, que es exactamente lo que se quiere comprobar.

Lo que propone la gente que se ha peleado con esto

La respuesta más repetida es sacar el aviso fuera de banda: un módem LTE con HAT, una SIM capaz de mandar un SMS al arrancar, LoRa hasta un vecino o un segundo enlace. Es la única salida cuando la conexión está completamente caída, porque todo lo que viaje por el enlace muerto es ciego por definición.

La segunda vía es sondear desde fuera. Algo al estilo de healthchecks.io, Uptime Kuma o Zabbix corriendo en una máquina con su propia salida a internet, que consulta al Pi periódicamente. Detecta la caída cuando ya ha ocurrido, pero no sirve mientras el enlace está abajo.

La tercera ataca la parte que se rompe en local. systemd con Restart=on-failure y After=network-online.target para que los servicios vuelvan solos después de un reinicio, más algo tipo monit para relanzar procesos caídos sin necesitar internet para nada.

La cuarta cambia el criterio de alerta: vigilar el progreso en lugar del ping. Una marca de tiempo de última escritura o un contador que solo avanza cuando hay trabajo real detecta al servicio que responde 200 pero no está haciendo nada, que es el fallo que se le coló al autor del hilo.

Su plan es combinar systemd, un latido y un enlace LTE barato de respaldo, y contar qué tal le ha ido.

La disponibilidad de un equipo remoto se juega en dos planos distintos: el del enlace y el de la máquina. Una sonda HTTP solo cubre el primero, y solo mientras el primero funcione. Saber si el Pi sigue encendido y ha llegado a arrancar exige un camino que no dependa del enlace que se está vigilando.