Un TRMNL para las alertas del VPS, polling o webhook

Después de los push de ntfy, los avisos de Telegram que dispara el HIDS casero con AIDE y un bot de comandos que me responde por chat, las alertas de mi VPS funcionan razonablemente bien. Si algo pasa, me llega al móvil con la prioridad adecuada. El problema, si es que se le puede llamar problema, es que todo vive dentro del bolsillo. Para enterarme de cualquier cosa tengo que desbloquear el teléfono, y para chequear el estado general acabo abriendo la app y deslizando notificaciones viejas hasta encontrar la última. Es un patrón de "yo voy a buscar la información" disfrazado de "la información viene a mí".

Llevo unas semanas mirando el TRMNL. Es una pantalla de e-ink de 7,5" con WiFi, refresco cada quince minutos por defecto y un sistema de plugins privados que tiran de URLs propias y renderizan con plantillas Liquid. La idea de tener una postal silenciosa al lado del monitor, sin notificaciones que ignorar y sin app que abrir, encaja con cómo me gustaría consumir el estado de la infra. Si el panel se ve verde de un vistazo, no toco nada. Si se ve algo rojo, ya me acercaré.

El plugin "ad-hoc" que tendría que escribir es trivial en su esencia. Una rejilla de semáforos, un par de números (alertas de CrowdSec en 24 horas, espacio en disco, contenedores caídos) y una lista corta de las últimas alertas activas. Lo no-trivial, y por eso este post existe, es decidir cómo le llega esa información al TRMNL. Hay dos caminos limpios, los dos compatibles con cómo tengo montada hoy la red, y se diferencian sobre todo en qué superficie expongo y cuánto control tengo sobre lo que aparece en pantalla.

Camino A, polling con un endpoint JSON

El primer camino es el patrón más cercano a lo que TRMNL llama Private Plugin. La pantalla pregunta cada N minutos a una URL mía que devuelve JSON, y una plantilla Liquid lo pinta. Yo monto un endpoint en el VPS (o un Worker de Cloudflare delante, para no exponer nada del origen) que agrega el estado de los check-* que ya tengo corriendo. CrowdSec, AIDE, espacio en disco, token de Cloudflare, reboot pendiente, contenedores caídos. Todo lo que ya alimenta el bot de Telegram, leído del mismo sitio, devuelto en un payload de cien o doscientos bytes.

La ventaja del polling es que el control de qué hay en pantalla vive en el endpoint, no en el dispositivo. Si quiero cambiar las reglas de "qué cuenta como rojo" toco el script en el servidor y el siguiente refresco lo aplica. El TRMNL solo sabe pintar lo que recibe. La plantilla Liquid no necesita lógica fuerte, basta con un puñado de condicionales para colorear los semáforos según el campo status de cada bloque.

El precio es que tengo que abrir un endpoint hacia Internet, o al menos hacia los IPs de TRMNL. Hoy mi monitorización va por canal saliente, push a ntfy y a Telegram, no recibe nada desde fuera. Meter un endpoint nuevo significa una pieza más de superficie, aunque sea pequeña. La forma elegante de cerrar esa superficie, y casualmente la que ya uso para los paneles privados de Dokploy, es meterla detrás de Cloudflare Access con un Service Token. El TRMNL incluye el token en cada petición y CF Access decide si pasa antes de que la petición toque el origen. La autenticación deja de ser código mío y pasa a ser configuración de Cloudflare.

El otro coste del polling es que tiene latencia incorporada. Si pongo el refresco a cada diez minutos, en el peor caso una alerta tarda diez minutos en aparecer en la pantalla. Para el tipo de cosas que quiero ver ahí, estado agregado y no incidentes en vivo, eso me da igual. Los incidentes graves siguen llegando al ntfy y al Telegram con su prioridad cinco. Pero conviene tenerlo claro antes de comprometerse con este camino.

Camino B, webhook desde mis timers actuales

El segundo camino le da la vuelta al flujo. En vez de que TRMNL pregunte, son mis check-*.timer los que avisan a TRMNL cuando algo cambia. TRMNL admite un endpoint propio al que se le hace POST con un payload, y la pantalla se redibuja con esa información en el siguiente refresco. Yo no expongo nada. Las peticiones siguen siendo salientes desde el VPS, igual que las que ya hacen contra ntfy o contra la API de Telegram.

El atractivo de este modelo es que es coherente con el resto de mi monitorización. Cada timer que ya alimenta una alerta de Telegram pasa a alimentar también, en la misma ejecución, el panel del TRMNL. No hay un endpoint nuevo, no hay CF Access que configurar, no hay otra superficie que vigilar. Y la latencia desaparece, porque el panel se actualiza en el momento exacto en que se detecta el cambio, no en el siguiente tick del polling.

El problema es que pierdo agregación. Cada webhook que envío sustituye lo que había en pantalla, así que si quiero un panel completo (CrowdSec, AIDE, disco, token de Cloudflare, reboot) tengo que orquestar un payload que combine todos los estados. Eso significa que cada timer tiene que conocer el estado de los demás antes de mandar el webhook, o que monto un script "agregador" que lee los demás scripts y compone el JSON final. En la práctica es casi lo mismo que el endpoint del camino A, solo que en vez de servirlo bajo demanda lo empujo cada vez que cambia algo.

También pierdo el "fallback" que da el polling. Si el TRMNL pierde una actualización del webhook (WiFi caído, dispositivo dormido fuera del intervalo) la pantalla se queda con el último estado que recibió hasta el siguiente push. Con polling, el siguiente refresco la pone al día sola. Para mitigarlo se puede mandar un webhook de heartbeat cada hora, pero entonces estás reinventando el polling con más pasos.

Por dónde me inclino

A mí me cuadra más el camino A. La superficie que añade es muy pequeña si entra detrás de Cloudflare Access, un Service Token y una regla, lo mismo que ya tengo para Dokploy o Umami. Y a cambio gano dos cosas que valoro. Una es que la lógica de "qué se ve en el panel" vive en un solo sitio, no repartida entre cinco timers. La otra es que el endpoint que escriba para TRMNL me sirve mañana para alimentar otra cosa. Una página de status interna, un widget en la pantalla del Mac, un comando del bot de Telegram que devuelva el mismo resumen. El webhook me cierra esa puerta porque ata el formato a lo que TRMNL espera.

Hay un caso en el que el camino B sigue siendo el más limpio, y es cuando solo me importa una señal y la quiero ver en tiempo real. Una pantalla "incident mode" que solo se enciende cuando hay un incidente activo y se apaga cuando se resuelve. Para eso, el webhook desde el timer que detecta el incidente es lo más directo. Pero ese no es el caso de uso que me interesa, lo mío es el panel "todo verde" que confirma que la infra está sana sin tener que ir a buscarlo.

Qué señales irían a la pantalla

Antes de decidir nada definitivo quiero acotar qué entra. La regla que sigo es la misma que apliqué con los digests de ntfy, solo cuento cosas que cambian de estado y no métricas de glosario. Una gráfica de carga de CPU en una e-ink no aporta gran cosa. Un semáforo "CrowdSec, doce alertas en las últimas 24 horas, dentro de umbral" sí.

El primer corte serían los mismos cinco eventos que ya me alimentan los timers. Token de Cloudflare vivo, AIDE sin cambios inesperados, disco por debajo del 85%, ningún reboot pendiente, todos los contenedores arriba. Cinco filas en negro con un punto verde, rojo o gris al lado. Debajo, un bloque pequeño con la última alerta activa si la hay, y la hora del último refresco para saber si la pantalla se quedó congelada.

Lo que no va a entrar, al menos en la primera versión, son las métricas que aún no me están avisando de nada. Latencia de respuesta del blog, número de búsquedas en el FTS, tráfico por subdominio. Es información que existe, pero meterla en un panel de alertas convierte el panel en un dashboard, y eso ya lo descarté en su día por la misma razón que descarté Grafana en su momento. Si no lo voy a mirar, no merece píxeles.

Cuando lo monte escribiré un segundo post con el endpoint, la plantilla Liquid y los detalles que se hayan complicado por el camino. Si alguien tiene un TRMNL en marcha y ha recorrido alguno de estos caminos, lo que más me interesa es saber con qué cadencia de refresco se queda al final, porque ahí es donde el e-ink suele pelearse con la realidad.