Todos los que conocen mi trabajo en administración de sistemas saben que soy un obseso de los logs (ficheros de bitácora, o ficheros de registro). Hoy empiezo un blog y lo haré hablando de ellos.

Aquellos que ignoran los logs suelen terminar poniendo cara de «¿cómo ha pasado esto?». Todo los servicios que corren en nuestros servidores pueden tener la necesidad de comunicarnos un problema, una incidencia o una información trivial. A falta de teléfono, oficina postal  o presencia de un servidor de correo correctamente configurado, la forma en la que la mayoría de estos servicios se comunican con «sus amos» es a través de los ficheros de log.

Su contenido no es siempre fácil de entender, entretenido o interesante. Pero ello no debe echarnos atrás. Tenemos que estar pendientes de ellos. Siempre cuento la anécdota de un amigo que se sentaba por la mañana con su café a leer los logs del día anterior. Es una  manera de hacerlo, aunque un tanto dura para mi gusto… 🙂

Para evitar esta tortura existen multitud de herramientas, más activas o más pasivas ante los eventos, más simples o más complejas de configurar, etc. Y en esto de la administración de sistemas cada maestrillo tiene su librillo. Posiblemente la solución ideal es la combinación de herramientas (logwatch, swatch, fwlogwatch, logstash, …), pero hoy sólo hablaré de mi preferida: logcheck.

Su funcionamiento es sencillo, algo clave en casi toda buena herramienta. Logcheck lee los logs que le indiques con cierta periodicidad, normalemente cada hora. Coge las líneas que no le hayas indicado anteriormente que son normales (en el próximo post daré los detalles) y te las manda en un correo. De esta forma «sólo» recibirás las entradas en los logs que tú no hayas «aceptado como normales».

Usar logcheck lleva un periodo de aprendidaze, para el propio logcheck. Nada más lo instales (en menos de una hora) enviará su primer «informe». Todas las líneas de log que no le hayas enseñado, un buen «pedazo de correo». Así que tendrás que empezar a decirle que líneas no quieres que te envíe. Para ayudarte en la tarea, en las distribuciones basadas en Debian encontrarás un paquete llamado logcheck-database que ya enseña a logcheck sobre las líneas más inofensivas de los servicios más comunes, ahorrándose un montón de trabajo. En las distribuciones basadas en RedHat/Fedora, el paquete de logcheck lleva ya incorporado las reglas de logcheck-database.

En cualquier caso los primeros correos de logcheck serán enormes y tus «lecciones» los irán reduciendo de tamaño. Con el paso del tiempo logcheck se limitará a enviarte esas líneas que nunca ha(s) visto y que bien deberás enseñarle o, y esto es la clave de logcheck, representan problemas o situaciones de las que debes estar informado. El mensaje que avisa de un fallo en la controladora de disco, de un intento de acceso a la máquina, de un error en la configuración de Apache, de un problema en el MySQL, etc…

En la práctica logcheck lee los logs como lo harías tú, ignorando los mensajes que no tienen importancia y dando importancia (al enviarlas por correo) a aquellos que no esperas. Con esta herramienta se cubre una parte muy importante de la vigilancia de logs, y por tanto de la administración de sistemas.

Como comentaba anteriormente, lo ideal es combinar herramientas. Hay un área importante que logcheck no cubre, el abuso. Yo puedo enseñar a logcheck que en mi servidor de correo son normales los mensajes que indican la entrada y salida de correo, y él ignorará dichos mensajes. Pero cuando un servidor de correo que mueve 3.000 mensajes al día, pasa a mover 3 millones, algo raro pasa y no será logcheck quien te avise, pues para él todo serán líneas que decidí debía ignorar. Otro tipo de herramientas, de resumen de logs, de gráficas de tráfico, de monitorización de actividad, deben cubrir ese hueco.

En mi siguiente post hablaré de su instalación y configuración, así como de algunos consejos de uso.

$ exit