log files con systemtd y journalctl

Cómo manejar los logs del sistema con journalctl


Para los que estamos acostumbrados al manejo de logs en linux (y llevamos unos añitos con esto), el cambio a systemd y el uso de journalctl nos puede venir un poco “grande” a estas alturas de la película.

Personalmente me debo estar volviendo algo “viejuno” porque, cada día que pasa, más me cuesta acostumbrarme a los cambios y journalctl, a pesar de que tiene indudables ventajas, ha llegado en un momento en el que hubiese preferido seguir consultando el contenido de /var/logs/messages como “toda la vida de Dios” 😅

Pero, como a la hora de ver qué está ocurriendo en nuestro sistema, no hay nada como consultar los logs pues aquí que dejo anotados los parámetros más importantes para el uso de journaltcl en el día a día con nuestro ordenador (si usas habitualmente alguno que no esté recogido, agradeceremos compartas tu conocimiento en los comentarios para poder enriquecernos y “ampliar horizontes” 👍)

Por unidad

Mostrar todo el contenido anotado en los logs puede llegar a ser agobiante así que, cuando estamos intentando localizar el origen del problema, nada mejor que filtrar por la unidad que nos interese comprobar. Así si queremos ver qué está ocurriendo con cronie (para la ejecución de tareas con anacron, por poner un ejemplo) podremos ejecutar un

journalctl -u cronie

donde, como habrás podido intuir el -u es de unit 😉

Para ver qué ocurre en varias unidades al mismo tiempo, sólo tendrás que ir añadiendo parámetros -u y las unidades que te interesen como en

journalctl -u cronie -u NetworkManager

Por tiempo

Otros parámetros interesantes son –since y –until que nos permite delimitar en qué intervalo de tiempo queremos “hurgar” en el contenido de los ficheros de log (junto al parámetro -u que acabamos de ver puede resultar realmente interesante)

Así un

journalctl –since “2019-01-15 00:00:00” –until “2019-01-23 15:10:00”

nos permitiría ver qué ha ocurrido desde el 15/ene/2019 hasta el 23/feb del mismo año.

Un detalle interesante es que, con –since, podemos permitirnos preguntar qué ha ocurrido hasta el momento en el que se lanza el comando (fecha y hora actuales) gracias a que entiende expresiones como

journalctl –since “10 minutes ago”

journalctl –since “2 days ago”

journalctl –since “3 hours ago”

¿Interesante verdad? 😉

“Espiar” los logs

Para aquellos a los que nos gustaba utilizar un tail -f /var/log/messages para ver qué iba ocurriendo en “tiempo real” conforme fuese apareciendo información en los ficheros de log, siempre nos queda el parámetro -f de modo que un

journalctl -f

nos permitirá ir viendo qué ocurre en nuestro sistema continuamente.

Controlando la salida

Existe una serie de parámetros que nos ayudarán a la hora de determinar cuánta información queremos recuperar y cómo queremos que se nos muestre, así podemos:

  • invertir el orden (-r) de modo que aparezcan primero las anotaciones más recientes (y lo más antiguo al final) evitando tener que ir (si la información es grande puede llegar a tardar más de lo deseable) al final del fichero (Shift+G) para consultarla.
  • limitar el número de anotaciones (-n) que deseamos consultar

  • indicar el formato de salida (-o) desde json (json o json-pretty), con más (verbose) o menos nivel de detalle (cat) y alguno que otro más (para lo cual te recomiendo mirar la ayuda de journalctl)

Conclusión

Recopilación de los parámetros que más utilizo que espero os sirva de referencia rápida para las consultas más habituales que suelen hacerse contra los logs del sistema. Si echas de menos alguna o te animas a compartir aquellas que usas tú, no dudes en dejarnos tu comentario: seguro que más de uno (yo el primero) te lo agradeceremos 👍

Y tú…

  • ¿Sueles utilizar los logs?
  • ¿Echas de menos /var/log/messages?
  • ¿Cuál es el parámetro que más utilizas?

 

12 comentarios en “Cómo manejar los logs del sistema con journalctl

  1. Que le den a systemd y sus logs binarios por donde amargan los pepinos. En mi portátil nuevo he puesto Devuan (fork de Debian sin systemd) con openrc y va muy bien así que en el sobremesa haré lo mismo. La Debian de mi sobremesa quiere obligarme a instalar systemd y le tengo bloqueados los paquetes para que no lo haga. Poco después de empezar a hacerlo openrc ha empezado a dar problemas en Debian y he tenido que pasar al viejo sysinit porsiaca, aunque la verdad, no lo he mirado a fondo.

    Sólo usaré systemd en sistemas que no estén bajo mi poder de decisión. Su modelo de desarrollo incluye añadir novedades antes que corregir bugs, y eso en una pieza tan importante del sistema me parece un despropósito. Cuando el desarrollo se estabilice pues igual, aunque no me gusta que meta sus raices en tantas partes del sistema, ni los logs binarios, ni no recuerdo que más… En su día se cargaba mi RAID10 cada pocos apagados y luego me obligaba a esperar horas de reconstrucción completa antes de seguir la secuencia de arranque al encenderlo después (que es cuando me daba cuenta).

    1. Estoy contigo amigo Malki que todo era más sencillo y fiable sin systemd… quizás por eso necesito dejar por escrito en esta chuleta los comandos más habituales.

      A mí no me está dando tanto problemas como los que comentas pero sigo sin estar cómodo con él.

      Al principio me daba coraje tener que usarlo y que se incluyese en la mayoría de distribuciones, a día de hoy… bueno, a día de hoy creo que me he resignado 😅

  2. Devuan (y alguna otra: https://en.wikipedia.org/wiki/Category:Linux_distributions_without_systemd ) te quieren… Un gran problema es que se mete en tantas cosas que en las distros que integran Systemd no puedes usar otras opciones o tienes problemas. No esperaba que Debian admitiera algo así y de hecho hubo polémica en ello por Debian y desarrolladores de Debian de toda la vida se marcharon del proyecto con la decisión de adoptar Systemd.

  3. Desde que nos pasamos al cloud todos los logs van a un servidor de logs ya sea CloudWatch o Logstash.
    Así que en realidad poco he trabajado journalctl…
    Un saludo

    1. ¿Incluso en tu equipo personal optas por subir a la nube los logs?

      Al final, el que está en las “nubes” soy yo 😅

      He de reconocer que si miro los logs es para resolver algún problema concreto y puntual; si el equipo pega un “castañazo” me limito a reinstalar para arreglar el estropicio (el maldecir va en el mismo lote 😉)

      Entiendo que en servidores no sería lo mismo

      1. Jajajaja
        Hace años que no miro los logs de mi equipo local!! simplemente funciona. También hace mucho que no hago experimentos con él 😛

    1. Kiaaa… de todos modos, el que esté libre de “pecados”. Todo software no actualizado es vulnerable a algún tipo de ataque. Aquí la gracia está en que es muy (pero que muy) utilizado y, está tan extendido, que merece la pena buscarle las “cosquillas” al software.

      Malki, me llama la atención que estés al tanto de listas de seguridad como la que has enlazado: ¿es por deformación profesional, interés o que lo has buscado expresamente para ver cómo andaba el proyecto o si había tenido algún “escándalo”?

      Gracias monstruo

      1. De proyectos equivalentes no salen fallos tan gordos ni tan a menudo, pero claro tienen modelos de desarrollo serios y filosofía KISS (Keep It Simple, Stupid). Es más difícil de controlar los problemas de un monstruo gigante con más de 1 millón de líneas de código a principios de 2018, frente a 14.000 de OpenRC.

        Lo han puesto en un grupo de Telegram en español sobre Devuan. Las actualizaciones de seguridad siempre pongo que se hagan automágicamente en mis servidores linux, pero aún así ante estos casos gordos, que me llegan por una u otra fuente sin estar apuntado expresamente a listas de seguridad, por si acaso reviso y actualizo manualmente.

        PD: Systemd caca de la vaca, tenía que decirlo xD

        1. Compro, compro… al final voy a tener que investigar un rato y cambiar mi sistema (para reinstalar completamente no tengo tiempo ni tengo el cuerpo para volver a una distro basada en Debían con sus PPAs 😅)

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.