Me tendrás que disculpar, pero no he podido resistirme a ponerle este título a este episodio del podcast. Me hacía gracia hacer este juego de palabras con log y lobo, aunque en su versión original es wolf. Si no sabes de que te estoy hablando me refiero a un famoso personaje de la película Pulp Fiction. La cuestión es que el señor Log, también está aquí para solucionar problemas, y esto es de lo que te voy a hablar hoy, de algunas herramientas que tienes al alcance de tus dedos, y que en un momento determinado, te pueden ayudar a resolver un problema, o al menos a tener una idea de cual puede ser el problema. Otra cuestión es si el problema en cuestión se puede resolver, o es fácilmente resoluble.

El Log o los logs, son una auténtica maravilla, una verdadera fuente de información. Y no creas que necesitas ser un experto para trabajar con un Log, nada de eso. Simplemente necesitas leer y probablemente paciencia, para dar con lo que andas buscando.

En otros episodios del podcast, los que van dedicados a realizar copias de seguridad, backup, te he dicho aquello de que si no estás realizando una copia de seguridad, dejes de escuchar el podcast y lo hagas de inmediato… Pues bien, en el caso de los logs, te digo exactamente lo mismo. Si tienes un proceso de backup, o un servicio, o una aplicación, sobre todo si trabaja en segundo plano, y no te está generando logs, deja de escuchar ahora mismo el podcast, y configura los logs.

La cuestión es que si tienes un proceso en segundo plano o un servicio configurado con un cron, o mediante Systemd, o como quieras, y no tienes un log estás completamente ciego. No sabes lo que está ocurriendo. No sabes si esa copia de seguridad se está realizando o en el caso de que se esté realizando si está acabando correctamente… En fin, no sabes nada.

Soy el señor Log, soluciono problemas

¿Logs?¿Porque hoy?

Desde luego, y a pesar del título del episodio de hoy, log no te va a solucionar un problema. Pero, sin lugar a dudas, es un buen punto de partida. Seguro que te va a dar mas de una pista para encontrar una posible solución a ese problema.

Habilitar los logs en tus herramientas

Y no solo te sirve para solucionar problemas, sino para como he comentado anteriormente, darte información de lo que está sucediendo entre bambalinas. Así, por ejemplo, cuando en el episodio 173 te hablé sobre borg, no te comenté que tengo configurado un log para este servicio, de forma que todos los días puedo ver si se ha realizado la copia de seguridad, cuanto tiempo le ha llevado, el número de archivos que tiene esa copia de seguridad y si todo ha terminado correctamente.

Añadir logs a tus scripts

De la misma forma, en el episodio 219 del podcast, te hablé sobre empaquetar Telegram o pon un script en tu vida. En este episodio, te comenté que actualmente estoy empaquetando Telegram para el escritorio, por una cuestión de tradición. Me refiero a que empecé a hacerlo hace años, y aunque lo puedes instalar de forma manual, de forma relativamente sencilla, a lo mejor prefieres, instalarlo desde repositorio.

Como te decía en ese episodio del podcast, lo cierto, es que mantener el paquete de Telegram actualizado, es algo pesado. Los chicos de Telegram no paran de trabajar en su aplicación, y es necesario actualizar el paquete, cada vez con mayor frecuencia.

Hace tiempo que quería automatizar el empaquetado, para quitarme el trabajo, y esto es lo que hice en aquel episodio. Sin embargo, me dejé algo importante, un log. Así, en las recientes actualizaciones de Telegram, solo creaba versión para Focal, pero no actualizaba para otras versiones.

Grave error por mi parte, porque en este caso no había implementado un log para este servicio y no sabía que era lo que estaba sucediendo. Iba completamente a ciegas. Sin embargo, gracias al titánico trabajo de los desarrolladores de Telegram, y que cada sacan actualizaciones día si, día también, he podido comprobar que el log que he implementado funciona perfectamente, y no solo esto sino donde estaba el error y como solucionarlo.

Para el caso, de que quieras implementar un log para tus scripts en Bash, te recomiendo el capítulo sobre log en Bash del tutorial del mismo nombre.

¿Y donde están esos logs?

Un log al fin y al cabo, lo puedes guardar donde tu quieras, pero en tu equipo, existen dos fuentes interesantes de logs. Los que te proporciona rsyslog y los que te proporciona journald. Sin embargo, todo va a depende de como tengas configurado ambos servicios, porque es posible que los mensajes aparezcan en un servicio, en otro servicio o en ambos servicios.

Pero como te digo, si creas una aplicación o servicio, tienes la potestad de decidir donde guardar ese log. Y no solo se trata de donde guardar el log, sino también de gestionarlo y mantenerlo. Me refiero, por ejemplo, al rotado de logs.

Syslog

En el caso de rsyslog, puedes encontrar el log en /var/log/syslog. Además de ese archivo encontrarás otros con el mismo nombre, pero seguidos por un número, y también de la extensión gz.

Esto es consecuencia de la política de rotado de logs, y que te comentaré en otro episodio del podcast.

¿Como reviso el log?

Existen diferentes herramientas que te van a permitir leer y estudiar que sucede en el log. Algunas de estas herramientas, te permiten acceder al log de forma estática, y otras de forma dinámica.

Me refiero a forma dinámica en el sentido de que te permiten ver que es lo que está sucediendo en el mismo conforme este se va actualizando. Se trata de una herramienta muy poderosa para capturar un bug.

Sea como fuere tienes diferentes herramientas para ver estos logs. Algunas de estas herramientas las puedes ver en el capítulo visores y editores para el terminal, del tutorial sobre el terminal.

tail

Para el caso de que quieras ver lo último que ha sucedido en el log, puedes utilizar tail, como en,

tail /var/log/syslog

Si lo que quieres es hacerlo de forma dinámica, tienes que utilizar la opción -f, como en la siguiente instrucción,

tail -f /var/log/systlog

Pero, no solo te permite ver lo que sucede en un log, también puedes ver lo que está sucediendo en varios de forma simultánea utilizando por ejemplo tail -f *.log. De esta forma cuando se produce un cambio, te muestra primero el nombre del archivo en cuestión, seguido por el cambio que se ha producido.

less

Otra opción muy interesante para ver lo que está sucediendo en tus logs es mediante less. A esta herramienta le dediqué un artículo titulado menos es mas con less, no pude resistirme al juego de palabras.

Esta herramienta te permite visualizar el contenido de un archivo tanto de forma estática, como de forma dinámica. Sin embargo, para un solo archivo presenta algunas ventajas respecto a tail.

En cualquier momento, puedes pasar al modo normal, utilizando Ctrl+c y realizar una búsqueda conforme te explico en el artículo anterior, moverte a lo largo y ancho del logo incluso realizar marcas en el mismo, para moverte con mas agilidad a lo largo del mismo.

Para analizar un log de forma dinámica, tienes que utilizar less +F /var/log/syslog. Recuerda, que en cualquier momento puedes pasar al modo normal utilizando Ctrl+c o reanudar el seguimiento en tiempo real con Mayúsculas+f.

Sin embargo, en el caso de que quieras analizar varios logs de forma simultánea utilizando less +F /var/log/*.log, no es tan cómodo como con el caso de tail. Y no es tan cómodo, porque less solo te muestra un archivo de forma simultánea. Para pasar a otro archivo tienes que utilizar :n, que te habilita la opción de pasar al siguiente buffer.

Comentarte que además de less tienes zless que te permite ver el contenido de archivos comprimidos.

lnav

Otra interesante herramienta que tienes a tu disposición para estudiar lo que sucede en tus logs es lnav. Esta herramienta, The Log File Navigator, es un avanzado visor de logs, al que sin lugar a dudas le debo un artículo mas en profundidad.

Una de las grandes ventajas de esta herramientas, es que está pensada explícitamente para el visionado de logs, pero, no necesitas ni configurar ni instalar nada mas que esta herramienta.

Pero no solo esto, sino que con solo apuntar al directorio en el que se encuentran los logs, lnav es capaz de comenzar a trabajar, mostrándote todos los cambios que se producen conforme se van produciendo.

Otra interesante característica de lnav es el resaltado de sintaxis, así como la navegación entre los diferentes tipos de mensaje de aviso, error, etc. Por supuesto, en función del tipo de mensaje el resaltado será de color distinto.

Journald

Para el caso de revisar el journal la herramienta que tienes al alcance de tus dedos, aunque también encontrarás interfaz gráfico, es journalctl. Si quieres conocer como trabajar con esta herramienta te recomiendo el capítulo journalctl y logs en systemd, del tutorial trabajando con Systemd.

De cualquier forma tampoco te tienes que preocupar de aprender a trabajar con journalctl, porque es less, sobre la que ya te he comentado anteriormente.

Eso si, esta herramienta te permite filtrar por unidad, por ejemplo,

journalctl -u bluettoth.service

Pero son solo puedes filtrar por unidad, también puedes filtrar por fecha, por proceso, usuario o grupo, por ejecutable.

Y por supuesto, puedes filtrar por prioridad, warning, info, notice, debug, err.

Y también formatear la salida, por ejemplo, con formato json o incluso con formato json avanzado.

Para concluir, ya que si quieres profundizar en esta herramienta puedes revisar el capítulo del tutorial antes mencionado, tienes la posibilidad de monitorizar la salida tal y como has podido hacer con las anteriores herramientas que te he comentado. Para ello, tan solo tienes que ejecutar esta herramienta con la opción -f.

Conclusión

Así que cuando tengas un problema, acuérdate del señor Log, que no te va a solucionar tu problema, pero sin lugar a dudas te va a dar las pistas suficientes para que descubras donde puede estar la solución del mismo.

---

Imagen de portada de Emma Watson