El sábado pasado vino a verme mi amigo Ángel y pasamos hablando unas cuantas horas juntos. Muchos temas, variados, pero cuando surgió el informático surgieron unas cuantas ideas.
Bien pensado el tema informático nunca deja de estar presente de una manera u otra.
Uno de los temas que surgieron fue el de las notificaciones administrativas de los sistemas que mantenemos. Está muy bien recibir notificaciones de cuándo ocurren cosas. Cosas malas como fallos y cosas buenas como tareas completadas. El problema es que son tantas que llegan a formar muros de texto en los que te pierdes. Ya no encuentras el fallo a primera vista. Y son muchas las cosas que puedes estar perdiéndote.
Parte de la filosofía de los sistemas UNIX era no decir nada a menos que algo fallase. Y eso estaba genial hasta que te encontrabas con la propia definición de fallo. Porque que una tarea que no ha llegado a realizarse, por ejemplo porque un ejecutable ha desaparecido o porque un recurso de red no está disponible y el programa ni lo sabía (un montaje NFS que desconocía) ni estaba hecho con esa posibilidad en mente, ¿ ha llegado a fallar de verdad ? ¿ O ha sido un fallo suave ? :-)
La respuesta canónica de un informático es siempre: depende. Y son muchos dependes en algunos casos.
Tanto Ángel como yo utilizamos el programa nullmailer en los sistemas para que cualquier correo de este tipo se envíe a un buzón único y desde allí gestionamos. Emplear otro tipo de herramienta más simple está descartado porque si no puede enviar un correo en el momento, al no tener cola de mensajes, falla y se acabó. Así que podemos tener una tarea que falla y que no puede avisar del fallo a su vez. Mola, ¿ verdad ?
Otra opción es instalar el paquete ligero de exim4 con las opciones adecuadas pero en configuración tiende a ser más complejo. Y como tampoco queremos perder un brazo con este tipo de sistemas pues mejor lo simplificamos.
Pero luego está la otra cara. El que recibe los mensajes sigue encontrándose con un muro de texto en el que tiene que emplear tiempo y esfuerzos por saber qué es lo que ha fallado y qué no. Lo peor es que eso sucede pocas veces. En mi experiencia cada mes puedo recibir alguna alerta preocupante. No más. Todos los días son casi los mismos mensajes. Y ni sé si han llegado todos. Que lo mismo sí, pero activa mi lado paranoico. ¿ Y sí vuelvo a encontrarme con sorpresas tiempo más tarde por tareas que pensaba que sí pero resulta que no y … ? Un drama.
Pero lo que sí se puede hacer es trazar un perfil de mensajes de manera que por encima o por debajo de él las cosas se pueden estar torciendo. Todos los días hay tres copias de seguridad a diferentes destinos. Antes de eso una recolecta de datos en formatos planos para poder salvarlos mejor. También inspecciones del sistema en busca de cosas malvadas. Eso indica que en cualquiera de estos sistemas genera más o menos seis mensajes diarios. Sin descanso.
¿ Y si alguien está mirando eso y se encarga de avisarme por otra vía ? ¿ Una más directa y con más posibilidades de recibir atención como el teléfono móvil ? (algo de eso he encontrado), pero antes quiero comentar una de esas ideas: un resumidor (compilador más bien) de mensajes de correo.
Ángel comentó que él empleaba para eso listas de correo a las que sólo estaba subscrito él en modo digest con lo que esa parte ya la tenía cubierta. Ingenioso como siempre. Y es una idea atrayente y sencilla pero a mí me gustaría darle un toque más: que además de resumirme el correo comprobase el citado perfil y me dijese si había algo raro. Oye, incluso buscando textos en los mensajes, ¿ por qué no ?
Así que tengo varias cosas en las que pensar. Estaría bien encontrar algo así, de fácil instalación, para ponerlo en marcha lo antes posible; una de las cosas que odio es pegarme con la instalación de un programa antes de poder probarlo. Ahí sí que se ve mi lado oscuro. Pero oscuro de verdad.
Y para terminar comento un descubrimiento que acabo de realizar y que me ha parecido una gozada: un sistema central de notificaciones con un uso sencillísimo (lo básico es emplear peticiones POST de HTTP para enviar mensajes), sólido y con soporte para móviles Android e iOS. También puede usar varias pasarelas para reenviar las notificaciones a otros sistemas como Telegram o el correo electrónico, pero eso es secundario para mí.
El programa se llama ntfy y el autor es Philipp C. Heckel. Lo estoy probando y ya tengo el servicio levantado y muchas expectativas pero me falta afinarlo porque por defecto lo instala abierto a todo quisque y mira, eso no. Y no porque los tópicos a los que subscribirse son términos de uso corriente como backups o averias o cosas así, y si está abierto al público es muy sencillo que alguien se enganche y lea todo lo que me llega.
Y aquí estoy, preparando una entrada sobre ello y con ganas de verlo en uso.
He mirado el ntfy y está bien pensado. Pero tiene una pega: o vas a una web o instalas un cliente y, puf, qué pereza. Quizá sería mejor hacer algún mini-programa que añada una línea a un RSS y usar el cliente RSS que ya estamos utilizando para mil cosas más. El programita se ejecutaría desde cada máquina por ssh hasta el servidor que publica el RSS.
El RSS no es difícil de generar pero no es inmediato. Hay otro formato, el twtxt.txt, que es un fichero de texto en el que cada línea es un timestamp, un tab y un mensaje. No hay tantos clientes twtxt pero hacer un conversor a RSS es una memez (y seguro que ya hay algo hecho). Y que cada sistema notifique añadiendo una línea a un fichero parece lo más sencillo.
Muy buena idea. Pero yo añado, ¿ que tal si en lugar de conexiones SSH -que son más complicadas de configurar- se emplea una dirección de correo electrónico y ¡ tachán ! mi resumidor de correos ?
Jo, al final voy a tener que escribirlo. Y sí, la idea del RSS para aquello que no sea urgente tipo «incendio en el CPD» o «intruso robando los cables» puede ser la definitiva. A fin de cuentas todas la mañanas me despacho 100 entradas de tecnología y sólo entro a ver dos como mucho que me interesen.
Mola.