One place for hosting & domains

      registros

      Cómo usar Journalctl para ver y manipular los registros de Systemd


      Introducción

      Algunas de las ventajas más convincentes de systemd son las que se relacionan con el proceso y registro del sistema. Al usar otros sistemas, los registros suelen estar dispersos por todo el sistema, son manejados por diferentes demonios y herramientas, y puede ser bastante difícil de interpretar cuando abarcan varias aplicaciones. Systemd intenta resolver estos problemas al proporcionar una solución de administración centralizada para registrar todos los procesos del kernel y del usuario. El sistema que recopila y administra estos registros se conoce como diario.

      El diario se implementa con el demonio journald, que gestiona todos los mensajes producidos por el kernel, initrd, servicios, etc. En esta guía, veremos cómo usar la utilidad journalctl, que puede usarse para acceder y manipular los datos que se encuentran dentro del diario.

      Idea general

      Uno de los impulsos detrás del diario systemd es centralizar la administración de los registros, independientemente de dónde se originen los mensajes. Dado que el proceso systemd gestiona gran parte del proceso de arranque y administración de servicios, tiene sentido estandarizar la forma en que se recopila y acceden a estos registros. El demonio journald recopila datos de todas las fuentes disponibles y los almacena en un formato binario para una manipulación fácil y dinámica.

      Eso nos proporciona varias ventajas significativas. Al interactuar con los datos usando una sola utilidad, los administradores pueden mostrar datos de registro de forma dinámica según sus necesidades. Esto puede ser tan simple como ver los datos del arranque de hace tres arranques o combinar las entradas de registro de forma secuencial de dos servicios relacionados para depurar un problema de comunicación.

      Almacenar los datos de registro en formato binario también significa que los datos pueden mostrarse en formatos de salida arbitrarios dependiendo de lo que se necesite en el momento. Por ejemplo, para la gestión de los registros diarios puede que esté acostumbrado a ver los registros en el formato estándar de syslog, pero si decide graficar las interrupciones del servicio más adelante, puede mostrar cada entrada como un objeto JSON para que sea consumible en su servicio gráfico. Dado que los datos no se escriben en el disco en texto plano, no es necesario convertirlos cuando se necesita un distinto formato bajo demanda.

      El diario systemd puede usarse con una implementación de syslog existente o puede sustituir la funcionalidad syslog, según sus necesidades. Aunque el diario systemd cubrirá la mayoría de las necesidades de registro del administrador, también puede complementar los mecanismos de registro existentes. Por ejemplo, es posible que tenga un servidor syslog centralizado que utilice para compilar datos de varios servidores, pero también es posible que quiera interconectar los registros de varios servicios en un solo sistema con el diario systemd. Puede hacer ambas cosas combinando estas tecnologías.

      Configurar la hora del sistema

      Una de las ventajas de usar un diario binario para el registro es la posibilidad de ver los registros en hora UTC o local libremente. systemd mostrará los resultados en hora local de manera predeterminada.

      Debido a esto, antes de comenzar con el diario, nos aseguraremos de que la zona horaria esté configurada correctamente. El paquete de systemd realmente viene con una herramienta llamada timedatectl que puede ayudar con esto.

      Primero, consulte qué zonas horarias están disponibles con la opción list-timezones:

      timedatectl list-timezones
      

      Esto mostrará la lista de zonas horarias disponibles en su sistema. Cuando encuentre la que coincida con la ubicación de su servidor, puede configurarla usando la opción set-timezone:

      sudo timedatectl set-timezone zone
      

      Para asegurarse de que su máquina esté usando la hora correcta actual, utilice el comando timedatectl solo o con la opción status. En la pantalla, se mostrará lo mismo:

      timedatectl status
      
            Local time: Thu 2015-02-05 14:08:06 EST
        Universal time: Thu 2015-02-05 19:08:06 UTC
              RTC time: Thu 2015-02-05 19:08:06
             Time zone: America/New_York (EST, -0500)
           NTP enabled: no
      NTP synchronized: no
       RTC in local TZ: no
            DST active: n/a
      

      La primera línea debe mostrar la hora correcta.

      Visualización básica de registros

      Para ver los registros que el demonio journald ha recopila el comando journalctl.

      Cuando se utilice solo, cada entrada de diario que se encuentre en el sistema se mostrará dentro de un localizador (por lo general, less) para que pueda navegar en él Las entradas más antiguas estarán arriba:

      journalctl
      
      -- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
      Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules
      
      . . .
      

      Es probable que tenga que desplazarse por páginas y páginas de datos, que pueden ser decenas o cientos de miles de líneas si systemd ha estado en su sistema por mucho tiempo. Esto demuestra la cantidad de datos disponibles en la base de datos del diario.

      El formato será familiar para aquellos que se utilizan para el registro syslog estándar. Sin embargo, esto realmente recopila datos de más fuentes de las que las implementaciones syslog tradicionales son capaces de recopilar. Incluye registros del proceso de arranque inicial, el kernel, el initrd, el error de estándar de la aplicación y la salida. Todos ellos están disponibles en el diario.

      Es posible que observe que todas las marcas de tiempo que se muestran son de hora local. Esto está disponible para cada entrada de registro ahora que tenemos nuestro tiempo local correctamente configurado en el sistema. Todos los registros se muestran usando esta nueva información.

      Si desea mostrar las marcas de tiempo en hora UTC, puede usar el indicador --utc:

      journalctl --utc
      

      Filtrado del diario por hora

      A pesar de que tener acceso a una colección tan grande de datos es definitivamente útil, es difícil o imposible inspeccionar y procesar mentalmente tal gran cantidad de datos. Debido a esto, una de las características más importantes de journalctl son sus opciones de filtrado.

      Mostrar los registros del arranque actual

      La más básica de estas que puede usar diariamente, es el indicador -b. Este indicador mostrará todas las entradas del diario que se recopilaron desde el reinicio más reciente.

      journalctl -b
      

      Esto le ayudará a identificar y administrar la información que sea pertinente para su entorno actual.

      En los casos en que no se usa esta función y se muestran más de un día de arranques, verá que journalctl insertó una línea parecida a la siguiente cada vez que el sistema se cae:

      . . .
      
      -- Reboot --
      
      . . .
      

      Lo puede usar para separar la información de manera lógica en sesiones de arranque.

      Arranques anteriores

      Aunque por lo general querrá mostrar la información del arranque actual, hay ocasiones en que los arranques anteriores también son útiles. El diario puede guardar la información de varios arranques anteriores, por lo que journalctl puede usarse para mostrar la información más fácilmente.

      Algunas distribuciones permiten guardar la información de los arranques anteriores de manera predeterminada, mientras que otras deshabilitan esta función. Para habilitar la información de arranque persistente, puede crear el directorio para almacenar el diario escribiendo lo siguiente:

      • sudo mkdir -p /var/log/journal

      O puede editar el archivo de configuración del diario:

      • sudo nano /etc/systemd/journald.conf

      En la sección [Journal], establezca la opción Storage= en “persistent” (persistente) para habilitar el registro persistente:

      /etc/systemd/journald.conf

      . . .
      [Journal]
      Storage=persistent
      

      Cuando la opción de guardar los arranques anteriores está habilitada en su servidor, journalctl proporciona algunos comandos para ayudarlo a trabajar con los arranques como unidad de división. Para ver los arranques que journald conoce, utilice la opción --list-boots con journalctl:

      journalctl --list-boots
      
      -2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
      -1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
       0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC
      

      Esto mostrará una línea para cada arranque. La primera columna es la compensación del arranque que puede usarse para hacer referencia fácilmente al arranque con journalctl. Si necesita una referencia absoluta, el ID del arranque está en la segunda columna. Puede saber la hora a la que se refiere la sesión de arranque con las dos especificaciones de hora que aparecen al final.

      Para mostrar la información de estos arranques, puede usar la información de la primera o la segunda columna.

      Por ejemplo, para ver el diario del arranque anterior, utilice el puntero relativo -1 con el indicador -b:

      journalctl -b -1
      

      También puede usar el ID de arranque invocar los datos de un arranque:

      journalctl -b caf0524a1d394ce0bdbcff75b94444fe
      

      Ventanas de tiempo

      Aunque ver las entradas de registro por arranque es increíblemente útil, en ocasiones es posible que quiera solicitar ventanas de tiempo que no se alinean bien con el arranque del sistema. Este puede ser el caso especialmente cuando se trata de servidores de larga duración con un tiempo de actividad significativo.

      Puede filtrar por límites de tiempo arbitrarios usando las opciones --since y --until, que restringen las entradas mostradas a aquellas posteriores o anteriores al tiempo indicado, respectivamente.

      Los valores de tiempo pueden venir en varios formatos. Para los valores absolutos de tiempo, debe usar el siguiente formato:

      YYYY-MM-DD HH:MM:SS
      

      Por ejemplo, podemos ver todas las entradas desde el 10 de enero de 2015 a las 5:15 p. m. escribiendo:

      journalctl --since "2015-01-10 17:15:00"
      

      Si se omiten los componentes del formato anterior, se aplicarán algunos valores predeterminados. Por ejemplo, si se omite la fecha, se asumirá la fecha actual. Si falta el componente que hace referencia a la hora, se sustituirá por “00:00:00” (medianoche). El campo de los segundos también se puede omitir para que aparezca “00” de manera predeterminada:

      journalctl --since "2015-01-10" --until "2015-01-11 03:00"
      

      El diario también comprende algunos valores relativos y los accesos directos con nombre. Por ejemplo, puede usar las palabras “yesterday”, “today”, “tomorrow”, o “now”. Puede hacer referencia a tiempos relativos anteponiendo “-” o “+” a un valor numérico o utilizando palabras como “ago” en la construcción de las instrucciones.

      Para obtener los datos del día de ayer, puede escribir lo siguiente:

      journalctl --since yesterday
      

      Si recibió informes de una interrupción del servicio que comenzó a las 9:00 a.m. y continuó hasta hace una hora, puede escribir lo siguiente:

      journalctl --since 09:00 --until "1 hour ago"
      

      Como puede ver, es relativamente fácil definir ventanas de tiempo flexibles para filtrar las entradas que desea ver.

      Filtrado por interés de mensaje

      En la sección anterior hemos aprendido algunas formas de filtrar los datos del diario utilizando restricciones de tiempo. En esta sección, veremos cómo filtrar según el servicio o componente que le interese. El diario systemd proporciona varias formas de hacer esto.

      Por unidad

      Probablemente la forma más útil de filtrar es por la unidad que le interesa. Podemos usar la opción -u para filtrar de esta manera.

      Por ejemplo, para ver todos los registros de una unidad de Nginx en nuestro sistema, podemos escribir lo siguiente:

      journalctl -u nginx.service
      

      Por lo general, también querrá filtrar por tiempo para mostrar las líneas que le interesa. Por ejemplo, para comprobar cómo se está ejecutando el servicio hoy, puede escribir lo siguiente:

      journalctl -u nginx.service --since today
      

      Este tipo de enfoque resulta extremadamente útil cuando se aprovecha la capacidad del diario para intercalar registros de varias unidades. Por ejemplo, si su proceso de Nginx está conectado a una unidad PHP-FPM para procesar contenido dinámico, puede combinar las entradas de ambos en orden cronológico especificando ambas unidades:

      journalctl -u nginx.service -u php-fpm.service --since today
      

      Eso puede hacer que sea mucho más fácil detectar las interacciones entre diferentes programas y sistemas de depuración en vez de procesos individuales.

      Por proceso, usuario o ID de grupo

      Algunos servicios generan varios procesos secundarios para realizar el trabajo. Si ha localizado el PID exacto del proceso que le interesa, también se puede hacer un filtrado basándonos en eso.

      Para hacer esto, podemos filtrar especificando el campo _PID. Por ejemplo, si el PID que nos interesa es 8088, podemos escribir lo siguiente:

      journalctl _PID=8088
      

      En otras ocasiones, es posible que quiera mostrar todas las entradas registradas de un usuario o de un grupo específico. Esto puede hacerse con los filtros _UID o _GID. Por ejemplo, si su servidor web se ejecuta bajo el usuario www-data, puede encontrar el ID de usuario escribiendo lo siguiente:

      id -u www-data
      
      33
      

      Luego, puede usar el ID que salió en la búsqueda para filtrar los resultados del diario:

      journalctl _UID=33 --since today
      

      El diario systemd tiene muchos campos que pueden usarse para filtrar. Algunos de estos son pasados desde el proceso que se está registrando y otros son aplicados por journald usando la información que recopila del sistema en el momento del registro.

      El símbolo inicial de guion bajo indica que el campo _PID es de este último tipo. El diario registra e indexa automáticamente el PID del proceso que está registrando para filtrarlo después. Puede obtener información sobre todos los campos disponibles del diario escribiendo lo siguiente:

      man systemd.journal-fields
      

      En esta guía, veremos algunas de estas opciones. Por ahora, sin embargo, vamos a repasar una opción más útil que tiene que ver con el filtrado mediante estos campos. La opción -F puede usarse para mostrar todos los valores disponibles para un determinado campo del diario.

      Por ejemplo, para ver qué ID de grupo tiene entradas el diario systemd, puede escribir lo siguiente:

      journalctl -F _GID
      
      32
      99
      102
      133
      81
      84
      100
      0
      124
      87
      

      Esto mostrará todos los valores que el diario almacenó para el campo del ID de grupo. Esto puede ayudarlo a crear sus filtros.

      Por ruta de componente

      También podemos filtrar proporcionando una ubicación de ruta.

      Si la ruta conduce a un ejecutable, journalctl mostrará todas las entradas que implican el ejecutable en cuestión. Por ejemplo, para encontrar aquellas entradas que implican el ejecutable bash, puede escribir lo siguiente:

      journalctl /usr/bin/bash
      

      Por lo general, si una unidad está disponible para el ejecutable, ese método es más limpio y proporciona mejor información (entradas de procesos secundarios asociados, etc.). A veces, sin embargo, eso no es posible.

      Mostrar mensajes de kernel

      Los mensajes de kernel, que suelen encontrarse en el resultado de dmesg, también se pueden recuperar del diario.

      Para mostrar solo estos mensajes, podemos añadir los indicadores -k o --dmesg a nuestro comando:

      journalctl -k
      

      De manera predeterminada, esto mostrará los mensajes del kernel del arranque actual. Puede especificar un arranque alternativo usando los indicadores normales de selección de arranque que se mostraron anteriormente. Por ejemplo, para obtener los mensajes de hace cinco arranques, puede escribir lo siguiente:

      journalctl -k -b -5
      

      Por prioridad

      Un filtro que suele interesar a los administradores de sistemas es el de prioridad de mensaje. Aunque a menudo es útil registrar información a un nivel muy verboso, cuando realmente se asimila la información disponible, los registros de baja prioridad pueden distraer y confundir.

      Puede usar journalctl para mostrar solo mensajes de una prioridad especifica o superior usando la opción -p. Esto le permite filtrar mensajes de menor prioridad.

      Por ejemplo, para mostrar solo las entradas registradas en el nivel de error o superior, puede escribir lo siguiente:

      journalctl -p err -b
      

      Esto le mostrará todos los mensajes marcados como error, crítico, alerta o emergencia. El diario implementa los niveles de mensaje syslog estándar. Puede usar el nombre de prioridad o su valor numérico correspondiente. En orden de mayor a menor prioridad, estos son:

      • 0: emergencia
      • 1: alerta
      • 2: crítico
      • 3: error
      • 4: advertencia
      • 5: aviso
      • 6: información
      • 7: depuración

      Los números o nombres anteriores pueden usarse indistintamente con la opción -p. Al seleccionar una prioridad, se mostrarán los mensajes marcados en el nivel especificado y aquellos que se encuentran por encima.

      Modificar la pantalla del diario

      Anteriormente, hemos demostrado la selección de entradas mediante el filtrado. Sin embargo, hay otras formas de modificar el resultado. Podemos ajustar la pantalla journalctl para que se adapte a varias necesidades.

      Truncar o ampliar el resultado

      Podemos ajustar la forma en que journalctl muestra datos indicándole que reduzca o amplíe el resultado.

      Por defecto, journalctl mostrará toda la entrada en el localizador, permitiendo que las entradas se desplacen a la derecha de la pantalla. Se puede acceder a esta información presionando la tecla de flecha derecha.

      Si prefiere truncar el resultado, insertar un elipses donde se eliminó la información, puede usar la opción --no-full:

      journalctl --no-full
      
      . . .
      
      Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
      Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
      Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot
      

      También puede hacer lo opuesto e indicarle a journalctl que muestre toda la información, independientemente de si incluye caracteres no imprimibles. Podemos hacerlo con el indicador -a:

      journalctl -a
      

      Resultado a la salida estándar

      Por defecto, journalctl muestra el resultado en un localizador para un uso más sencillo. Sin embargo, si está planeando procesar los datos con herramientas de manipulación de texto, es probable que quiera poder mostrar un resultado estándar.

      Puede hacer esto con la opción --no-pager:

      journalctl --no-pager
      

      Se puede canalizar inmediatamente a una utilidad de procesamiento o redireccionar a un archivo en el disco, dependiendo de sus necesidades.

      Formatos de resultado

      Si está procesando las entradas del diario, como se mencionó anteriormente, es probable que le resulte más fácil analizar los datos si están en un formato más fácil de usar. Afortunadamente, el diario puede mostrarse en varios formatos según sea necesario. Puede hacerlo usando la opción -o con un especificador de formato.

      Por ejemplo, puede mostrar las entradas del diario en JSON escribiendo lo siguiente:

      journalctl -b -u nginx -o json
      
      { "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }
      
      . . .
      

      Eso es útil para el análisis sintáctico con utilidades. Puede usar el formato json-pretty para obtener un mejor manejo de la estructura de datos antes de transmitirla al consumidor JSON:

      journalctl -b -u nginx -o json-pretty
      
      {
          "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
          "__REALTIME_TIMESTAMP" : "1422990364739502",
          "__MONOTONIC_TIMESTAMP" : "27200938",
          "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
          "PRIORITY" : "6",
          "_UID" : "0",
          "_GID" : "0",
          "_CAP_EFFECTIVE" : "3fffffffff",
          "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
          "_HOSTNAME" : "desktop",
          "SYSLOG_FACILITY" : "3",
          "CODE_FILE" : "src/core/unit.c",
          "CODE_LINE" : "1402",
          "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
          "SYSLOG_IDENTIFIER" : "systemd",
          "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
          "_TRANSPORT" : "journal",
          "_PID" : "1",
          "_COMM" : "systemd",
          "_EXE" : "/usr/lib/systemd/systemd",
          "_CMDLINE" : "/usr/lib/systemd/systemd",
          "_SYSTEMD_CGROUP" : "/",
          "UNIT" : "nginx.service",
          "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
          "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
      }
      
      . . .
      

      Se pueden usar los siguientes formatos para la visualización:

      • cat: Muestra solo el campo de mensaje.
      • export: Formato binario adecuado para transferir o hacer copias de seguridad.
      • json: JSON estándar con una entrada por línea.
      • json-pretty: JSON formateado para una mejor legibilidad humana
      • json-sse: Resultado formateado JSON envuelto para hacer que el evento enviado por servidor sea compatible
      • short: El resultado de estilo syslog predeterminado
      • short-iso: El formato predeterminado aumentado para mostrar las marcas de tiempo del reloj de pared ISO 8601.
      • short-monotonic: El formato predeterminado con marcas de tiempo monotónicas.
      • short-precise: El formato predeterminado con precisión de microsegundos.
      • verbose: Muestra todos los campos del diario disponibles para la entrada, incluidos los que suelen estar ocultos internamente.

      Estas opciones le permiten mostrar las entradas del diario en el formato que mejor se adapte a sus necesidades actuales.

      Supervisión activa de procesos

      El comando journalctl imita la cantidad de administradores que utilizan tail para supervisar la actividad activa o reciente. Esta funcionalidad está incorporada en journalctl, lo que le permite acceder a estas funciones sin necesidad de recurrir a otra herramienta.

      Cómo mostrar los registros recientes

      Para mostrar una cantidad determinada de registros, puede usar la opción -n, que funciona exactamente igual que tail -n.

      Por defecto, se mostrarán las 10 entradas más recientes:

      journalctl -n
      

      Puede especificar el número de entradas que desea ver agregando un número después de -n:

      journalctl -n 20
      

      Cómo hacer un seguimiento de los registros

      Para seguir activamente los registros a medida que se escriben, puede usar el indicador -f. Una vez más, esto funciona de la manera prevista si tiene experiencia usando tail -f:

      journalctl -f
      

      Mantenimiento del diario

      Es posible que se esté preguntando sobre el costo de almacenar todos los datos que hemos visto hasta ahora. Además, puede que le interese limpiar algunos registros antiguos y liberar espacio.

      Cómo encontrar el uso actual de disco

      Puede averiguar la cantidad de espacio que el diario está ocupando actualmente en el disco usando la opción el indicador --disk-usage:

      journalctl --disk-usage
      
      Journals take up 8.0M on disk.
      

      Cómo eliminar registros antiguos

      Si desea reducir su diario, puede hacerlo de dos distintas formas (disponibles en la versión 218 y posterior de systemd).

      Si usa la opción --vacuum-size, puede reducir su diario indicando un tamaño. Esto eliminará las entradas antiguas hasta que el espacio total del diario ocupado en el disco sea del tamaño solicitado:

      sudo journalctl --vacuum-size=1G
      

      Otra forma de reducir el diario es proporcionar un tiempo límite con la opción --vacuum-time. Cualquier entrada que sobrepase ese límite de tiempo será eliminada. Esto le permite mantener las entradas que se han creado después de un tiempo específico.

      Por ejemplo, para guardar las entradas del último año, puede escribir lo siguiente:

      sudo journalctl --vacuum-time=1years
      

      Cómo limitar la expansión del diario

      Puede configurar su servidor para que ponga límites sobre cantidad de espacio que puede ocupar el diario. Puede hacer esto editando el archivo /etc/systemd/journald.conf

      Puede usar los siguientes elementos para limitar la expansión del diario:

      • SystemMaxUse=: especifica el espacio máximo de disco que puede usar el diario en el almacenamiento persistente.
      • SystemKeepFree=: especifica la cantidad de espacio que el diario debe dejar libre al añadir entradas del diario al almacenamiento persistente.
      • SystemMaxFileSize=: controla el tamaño que pueden alcanzar los archivos individuales del diario en el almacenamiento persistente antes de rotar.
      • RuntimeMaxUse=: especifica el espacio máximo de disco que puede usarse en el almacenamiento volátil (dentro del sistema de archivos /run).
      • RuntimeKeepFree=: especifica la cantidad de espacio que debe reservarse para otros usos al escribir datos en el almacenamiento volátil (dentro del sistema de archivos /run).
      • RuntimeMaxFileSize=: especifica la cantidad de espacio que puede ocupar un archivo de diario individual en el almacenamiento volátil (dentro del sistema de archivos /run) antes de rotar.

      Al establecer estos valores, puede controlar la forma en que journald utiliza y preserva el espacio en su servidor. Tenga en cuenta que SystemMaxFileSize y RuntimeMaxFileSize orientarán los archivos para llegar a los límites indicados. Es importante recordar esto al interpretar el recuento de archivos después de una operación vaciado.

      Conclusión

      Como puede ver, el diario systemd es increíblemente útil para recopilar y administrar los datos de su sistema y aplicación. Su flexibilidad proviene, en mayor parte, de los amplios metadatos registrados automáticamente y del carácter centralizado del registro. El comando journalctl hace que sea fácil aprovechar las funciones avanzadas del diario, realizar amplios análisis y depurar de forma relacional los diferentes componentes de la aplicación.



      Source link

      Como usar o Journalctl para visualizar e manipular registros do systemd


      Introdução

      Algumas das vantagens mais interessantes do systemd são aquelas envolvidas com o registro de processos e do sistema. Ao usar outros sistemas, os registros ficam geralmente dispersos, e são manuseados por daemons e processos diferentes. Isso torna a interpretação deles bastante difícil quando englobam vários aplicativos. O systemd tenta resolver esses problemas fornecendo uma solução de gerenciamento centralizada para registrar todos os processos do kernel e do userland. O sistema que coleta e gerencia esses registros é conhecido como journal (diário).

      O diário é implementado com o daemon journald, que manuseia todas as mensagens produzidas pelo kernel, initrd, serviços etc. Neste guia, vamos discutir como utilizar o utilitário journalctl, que pode ser usado para acessar e manipular os dados mantidos dentro do diário.

      Ideal geral

      Um dos motivos da existência do diário do systemd é o de centralizar o gerenciamento de registros independentemente de onde as mensagens estão sendo originadas. Como uma grande parte do processo de inicialização do sistema e gerenciamento de serviços é manuseada pelo processo systemd, faz sentido padronizar a maneira como os registros são coletados e acessados. O daemon journald coleta dados de todas as fontes disponíveis e os armazena em um formato binário para uma manipulação fácil e dinâmica.

      Isso nos dá várias vantagens significativas. Ao interagir com os dados usando um único utilitário, os administradores são capazes de exibir dinamicamente dados de registro de acordo com suas necessidades. Isso pode ser algo simples como visualizar os dados de inicialização de três inicializações de sistema atrás ou combinar as entradas de registro sequencialmente de dois serviços relacionados para consertar um problema de comunicação.

      Armazenar os dados de registro em um formato binário também faz com que eles possam ser exibidos em formatos de saída arbitrários, dependendo da sua necessidade naquele momento. Por exemplo, para o gerenciamento de registros diários, você pode estar acostumado a visualizar os registros no formato syslog padrão. No entanto, se você quiser representar interrupções de serviço em gráficos mais tarde, é possível gerar um objeto JSON para cada entrada para que seja consumível pelo seu serviço de criação de gráficos. Como os dados não são escritos no disco em texto simples, nenhuma conversão é necessária quando houver a demanda por um formato diferente.

      O diário do systemd pode ser usado com uma implementação do syslog existente, ou pode substituir a funcionalidade syslog, dependendo das suas necessidades. Embora o diário do systemd atenda a maioria das necessidades de registro de administrador, ele também pode complementar mecanismos de registro existentes. Por exemplo, pode ser que você tenha um servidor syslog centralizado que usa para compilar dados de vários servidores, mas também queira intercalar os registros de vários serviços em um único sistema com o diário do systemd. É possível fazer as duas coisas combinando essas tecnologias.

      Configurando o horário do sistema

      Um dos benefícios do uso de um diário binário para registro é a capacidade de visualizar registros em UTC ou em seu horário local à vontade. Por padrão, o systemd irá exibir resultados no horário local.

      Por conta disso, antes de começarmos com o diário, vamos garantir que o fuso horário esteja configurado corretamente. O pacote do systemd vem com uma ferramenta chamada timedatectl que pode ajudar com isso.

      Primeiramente, consulte quais fusos horários estão disponíveis com a opção list-timezones:

      timedatectl list-timezones
      

      Isso irá listar os fusos horários disponíveis no seu sistema. Depois de encontrar aquele que corresponde ao local do seu servidor, defina-o usando a opção set-timezone:

      sudo timedatectl set-timezone zone
      

      Para garantir que sua máquina esteja usando o horário correto neste momento, use o comando timedatectl sozinho, ou com a opção status. O resultado será o mesmo:

      timedatectl status
      
            Local time: Thu 2015-02-05 14:08:06 EST
        Universal time: Thu 2015-02-05 19:08:06 UTC
              RTC time: Thu 2015-02-05 19:08:06
             Time zone: America/New_York (EST, -0500)
           NTP enabled: no
      NTP synchronized: no
       RTC in local TZ: no
            DST active: n/a
      

      A primeira linha deve exibir o horário correto.

      Visualização básica de registros

      Para ver os registros que o daemon do journald coletou, use o comando journalctl.

      Quando usado sozinho, todas as entradas no diário que estão no sistema serão exibidas dentro de um pager (geralmente less (menos)) para você navegar. As entradas mais antigas estarão no topo:

      journalctl
      
      -- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
      Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules
      
      . . .
      

      É provável que você tenha páginas e páginas de dados para percorrer, que podem ser dezenas ou centenas de milhares de linhas se o systemd estiver em seu sistema há bastante tempo. Isso demonstra a quantidade de dados que está disponível no banco de dados do diário.

      O formato será conhecido por aqueles que estão acostumados com o registro padrão do syslog. No entanto, este processo coleta dados de mais fontes do que as implementações tradicionais do syslog são capazes de fazer. Ele inclui registros do processo de inicialização inicial, do kernel, do initrd e do erro padrão de aplicativo e mais. Todos eles estão disponíveis no diário.

      Note que todos os carimbos de data/hora estão sendo exibidos no horário local. Isso está disponível para toda entrada de registro agora que temos nosso horário local configurado corretamente em nosso sistema. Todos os registros são exibidos usando essas novas informações.

      Se quiser exibir os carimbos de data/hora em UTC, use o sinalizador --utc:

      journalctl --utc
      

      Filtrar o diário pela hora

      Embora ter acesso a uma grande coleção de dados seja definitivamente útil, essa grande quantidade de informações pode ser difícil ou impossível de ser inspecionada e processada mentalmente. Por conta disso, uma das características mais importantes do journalctl é suas opções de filtragem.

      Exibir registros da inicialização atual

      A opção mais básica existente que pode ser usada diariamente, é o sinalizador -b. Ele irá mostrar todas as entradas do diário que foram coletadas desde a reinicialização mais recente.

      journalctl -b
      

      Isso ajudará você a identificar e gerenciar informações pertinentes ao seu ambiente atual.

      Nos casos em que você não estiver usando esse recurso e estiver exibindo mais de um dia de inicializações, verá que o journalctl insere uma linha que se parece com esta, sempre que o sistema foi desligado:

      . . .
      
      -- Reboot --
      
      . . .
      

      Isso pode ser usado para ajudar a separar as informações em sessões de inicialização de maneira lógica.

      Inicializações passadas

      Embora seja comum querer exibir as informações da inicialização atual, certamente existem momentos em que as inicializações passadas também podem ser úteis. O diário pode salvar informações de várias inicializações anteriores, de modo que o journalctl pode ser usado para exibir essas informações facilmente.

      Algumas distribuições habilitam o salvamento de informações de inicializações anteriores por padrão, enquanto outras desativam esse recurso. Para habilitar as informações de inicialização persistentes, crie o diretório para armazenar o diário digitando:

      • sudo mkdir -p /var/log/journal

      Ou edite o arquivo de configuração do diário:

      • sudo nano /etc/systemd/journald.conf

      Na seção [Journal], defina a opção Storage= como “persistent” para habilitar o registro persistente:

      /etc/systemd/journald.conf

      . . .
      [Journal]
      Storage=persistent
      

      Quando o salvamento de inicializações anteriores está habilitado no seu servidor, o journalctl fornece alguns comandos para ajudar a trabalhar com as inicializações como uma unidade de divisão. Para ver as inicializações das quais o journald tem conhecimento, use a opção --list-boots com o journalctl:

      journalctl --list-boots
      
      -2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
      -1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
       0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC
      

      Isso irá exibir uma linha para cada inicialização. A primeira coluna é o deslocamento da inicialização em relação à atual que pode ser usado para identificá-la com facilidade com o journalctl. Se precisar de uma referência absoluta, o ID de inicialização está na segunda coluna. É possível identificar o tempo da sessão com as duas especificações de data/hora no final da linha.

      Para exibir informações dessas inicializações, use as informações da primeira ou segunda coluna.

      Por exemplo, para ver o diário da inicialização anterior, use o ponteiro relativo -1 com o sinalizador -b:

      journalctl -b -1
      

      Também é possível usar o ID de inicialização para retornar os dados de uma inicialização específica:

      journalctl -b caf0524a1d394ce0bdbcff75b94444fe
      

      Intervalos de tempo

      Embora a visualização de entradas de registro com base na inicialização seja incrivelmente útil, muitas vezes é desejável solicitar intervalos de tempo que não se alinham com as inicializações do sistema. Isso pode ser especialmente válido ao lidar com servidores de execução prolongada com um tempo de atividade significativo.

      É possível filtrar por limites arbitrários de data/hora usando as opções --since e --until, que restringem as entradas exibidas a aquelas que sucedem ou antecedem um determinado tempo, respectivamente.

      Os valores de data/hora podem ser usados em uma variedade de formatos. Para valores de data/hora absolutos, use o seguinte formato:

      YYYY-MM-DD HH:MM:SS
      

      Por exemplo, podemos ver todas as entradas desde 10 de janeiro de 2015 às 5:15 PM digitando:

      journalctl --since "2015-01-10 17:15:00"
      

      Se algum componente do formato acima for deixado de fora, o padrão será aplicado. Por exemplo, se a data for omitida, a data atual será empregada. Se o componente de hora estiver faltando, “00:00:00” (meia-noite) será utilizado. O campo de segundos também pode ser deixado de fora e o padrão “00” é empregado:

      journalctl --since "2015-01-10" --until "2015-01-11 03:00"
      

      O diário também compreende alguns valores relativos e seus atalhos nomeados. Por exemplo, é possível usar as palavras “yesterday” (ontem), “today” (hoje), “tomorrow” (amanhã) ou “now” (agora). É possível criar datas/horas relativas prefixando “-” ou “+” a um valor numerado ou usando palavras como “ago” (atrás) em uma construção de sentenças.

      Para obter os dados de ontem, pode-se digitar:

      journalctl --since yesterday
      

      Se tiver recebido relatórios de uma interrupção de serviço iniciada às 9:00 AM que durou até uma hora atrás, você pode digitar:

      journalctl --since 09:00 --until "1 hour ago"
      

      Como se vê, é relativamente fácil definir intervalos flexíveis de tempo para filtrar as entradas que você deseja visualizar.

      Filtrar por interesse de mensagens

      Aprendemos acima algumas maneiras de filtrar os dados do diário usando restrições de tempo. Nesta seção, vamos discutir como filtrar com base em qual serviço ou componente você está interessado. O diário do systemd oferece diversas maneiras de fazer isso.

      Por unidade

      Talvez a maneira mais útil de filtrar seja pela unidade na qual você está interessado. Podemos usar a opção -u para filtrar dessa maneira.

      Por exemplo, para ver todos os registros de uma unidade Nginx em nosso sistema, digitamos:

      journalctl -u nginx.service
      

      Normalmente, também seria interessante filtrar pela data/hora para exibir as linhas nas quais você está interessado. Por exemplo, para verificar como o serviço está funcionando hoje, digite:

      journalctl -u nginx.service --since today
      

      Esse tipo de foco torna-se extremamente útil quando se aproveita da capacidade do diário de intercalar os registros de várias unidades. Por exemplo, se seu processo Nginx estiver conectado a uma unidade PHP-FPM para processar conteúdo dinâmico, é possível fundir as entradas de ambos em ordem cronológica especificando ambas as unidades:

      journalctl -u nginx.service -u php-fpm.service --since today
      

      Isso pode facilitar a detecção de interações entre diferentes programas e sistemas de depuração, em vez de processos individuais.

      Por processo, usuário ou ID de grupo

      Alguns serviços geram uma variedade de processos filhos para funcionar. Se você tiver pesquisado o PID exato do processo em que está interessado, também é possível filtrar por ele.

      Para fazer isso, especificamos o campo _PID. Por exemplo, se o PID em que estivermos interessados for 8088, digitamos:

      journalctl _PID=8088
      

      Em outros momentos, pode ser desejável exibir todas as entradas registradas a partir de um usuário ou grupo específico. Isso pode ser feito com os filtros _UID ou _GID. Por exemplo, se seu servidor Web estiver sendo executado sob o usuário www-data, é possível encontrar o ID do usuário digitando:

      id -u www-data
      
      33
      

      Depois disso, use o ID retornado para filtrar os resultados do diário:

      journalctl _UID=33 --since today
      

      O diário do systemd possui muitos campos que podem ser usados para a filtragem. Alguns deles são passados do processo que está sendo registrado e alguns são aplicados pelo journald usando informações que ele coleta do sistema no momento do registro.

      O sublinhado inicial indica que o campo _PID pertence ao segundo tipo. O diário registra e classifica automaticamente o PID do processo que está sendo registrado para a filtragem posterior. É possível descobrir todos os campos de diário disponíveis digitando:

      man systemd.journal-fields
      

      Vamos discutir alguns deles neste guia. Por enquanto, vamos analisar mais uma opção útil relacionada com a filtragem por esses campos. A opção -F pode ser usada para mostrar todos os valores disponíveis para um campo de diário específico.

      Por exemplo, para ver quais entradas para IDs de grupo o diário do systemd possui, digite:

      journalctl -F _GID
      
      32
      99
      102
      133
      81
      84
      100
      0
      124
      87
      

      Isso irá mostrar todos os valores que o diário armazenou para o campo ID de grupo. Isso pode ajudar a construir seus filtros.

      Por caminho de componente

      Também podemos filtrar fornecendo um caminho de pesquisa.

      Se o caminho levar a um executável, o journalctl irá exibir todas as entradas relacionadas ao executável em questão. Por exemplo, para encontrar essas entradas que estão relacionadas ao executável bash, digite:

      journalctl /usr/bin/bash
      

      Normalmente, se uma unidade estiver disponível para o executável, esse método é mais organizado e fornece informações mais completas (entradas de processos filhos associados, etc). Às vezes, no entanto, isso não é possível.

      Exibir mensagens de kernel

      As mensagens de kernel, que são aquelas geralmente encontradas na saída do dmesg, também podem ser recuperadas do diário.

      Para exibir apenas essas mensagens, podemos adicionar os sinalizadores -k ou --dmesg ao nosso comando:

      journalctl -k
      

      Por padrão, isso irá exibir as mensagens do kernel da inicialização atual. É possível especificar uma outra inicialização usando os sinalizadores de seleção de inicialização discutidos anteriormente. Por exemplo, para obter as mensagens de cinco inicializações atrás, digite:

      journalctl -k -b -5
      

      Por prioridade

      Um filtro no qual os administradores de sistema estão geralmente interessados é a prioridade de mensagem. Embora seja muitas vezes útil registrar informações em um nível bastante detalhado, ao resumir as informações disponíveis, o registro de baixa prioridade pode ser confuso.

      É possível usar o journalctl para exibir apenas mensagens de uma prioridade especificada ou superior usando a opção -p. Isso permite filtrar mensagens com níveis de prioridade inferiores.

      Por exemplo, para mostrar apenas entradas registradas no nível de erro ou acima, digite:

      journalctl -p err -b
      

      Isso irá exibir todas as mensagens marcadas como erro, crítico, alerta ou emergência. O diário implementa os níveis de mensagem padrão do syslog. É possível usar o nome da prioridade ou seu valor numérico correspondente. As prioridades, ordenadas da maior para a menor, são:

      • 0: emerg
      • 1: alert
      • 2: crit
      • 3: err
      • 4: warning
      • 5: notice
      • 6: info
      • 7: debug

      Os números ou nomes acima podem ser usados de maneira intercambiável com a -p opção. A seleção de uma prioridade irá exibir mensagens marcadas no nível especificado e acima.

      Modificar a exibição do diário

      Acima, demonstramos a seleção de entradas através da filtragem. No entanto, existem outras maneiras com as quais podemos modificar o resultado. Podemos ajustar a exibição do journalctl para atender diversas necessidades.

      Truncar ou expandir o resultado

      Podemos ajustar como o journalctl exibe os dados, dizendo-lhe para reduzir ou expandir o resultado.

      Por padrão, o journalctl irá mostrar a entrada inteira no pager, permitindo que as entradas se expandam à direita da tela. Essa informação pode ser acessada pressionando a tecla de seta para a direita.

      Se preferir o resultado truncado, inserindo reticências onde as informações foram removidas, use a opção --no-full:

      journalctl --no-full
      
      . . .
      
      Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
      Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
      Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot
      

      Também é possível ir na direção oposta e dizer ao journalctl para exibir todas as suas informações, mesmo se forem incluídos caracteres não imprimíveis. Podemos fazer isso com o sinalizador -a:

      journalctl -a
      

      Resultados em formato padrão

      Por padrão, o journalctl exibe o resultado em um pager para um consumo mais simples. No entanto, se você estiver planejando processar os dados com ferramentas de manipulação de texto, irá querer ser capaz de gerar resultados no formato padrão.

      Faça isso com a opção --no-pager:

      journalctl --no-pager
      

      Isso pode ser canalizado imediatamente em um utilitário de processamento ou redirecionado para um arquivo no disco, dependendo das suas necessidades.

      Formatos de saída

      Se você estiver processando entradas de diário, como mencionado acima, provavelmente será mais fácil analisar os dados se eles estiverem em um formato mais consumível. Felizmente, o diário pode ser exibido em uma variedade de formatos conforme a necessidade. Faça isso usando a opção -o com um especificador de formato.

      Por exemplo, gere um arquivo JSON a partir de entradas no diário digitando:

      journalctl -b -u nginx -o json
      
      { "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }
      
      . . .
      

      Isso é útil para análise com utilitários. Você poderia usar o formato json-pretty para ter uma melhor ideia melhor da estrutura de dados antes de passá-lo para o consumidor de JSON:

      journalctl -b -u nginx -o json-pretty
      
      {
          "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
          "__REALTIME_TIMESTAMP" : "1422990364739502",
          "__MONOTONIC_TIMESTAMP" : "27200938",
          "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
          "PRIORITY" : "6",
          "_UID" : "0",
          "_GID" : "0",
          "_CAP_EFFECTIVE" : "3fffffffff",
          "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
          "_HOSTNAME" : "desktop",
          "SYSLOG_FACILITY" : "3",
          "CODE_FILE" : "src/core/unit.c",
          "CODE_LINE" : "1402",
          "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
          "SYSLOG_IDENTIFIER" : "systemd",
          "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
          "_TRANSPORT" : "journal",
          "_PID" : "1",
          "_COMM" : "systemd",
          "_EXE" : "/usr/lib/systemd/systemd",
          "_CMDLINE" : "/usr/lib/systemd/systemd",
          "_SYSTEMD_CGROUP" : "/",
          "UNIT" : "nginx.service",
          "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
          "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
      }
      
      . . .
      

      Os formatos a seguir podem ser usados para exibição:

      • cat: exibe apenas o campo de mensagem em si.
      • export: um formato binário adequado para transferir e fazer um backup.
      • json: JSON padrão com uma entrada por linha.
      • json-pretty: JSON formatado para uma melhor legibilidade humana
      • json-sse: saída formatada em JSON agrupada para tornar um evento enviado ao servidor compatível
      • short: o estilo de saída padrão do syslog
      • short-iso: o formato padrão aumentado para mostrar as carimbos de data/hora da ISO 8601.
      • short-monotonic: o formato padrão com carimbos de data/hora monotônicos.
      • short-precise: o formato padrão com precisão de microssegundos
      • verbose: exibe todas os campos de diário disponíveis para a entrada, incluindo aqueles que geralmente estão escondidos internamente.

      Essas opções permitem exibir as entradas do diário no formato que melhor atende às suas necessidades atuais.

      Monitoramento de processo ativo

      O comando journalctl imita a forma como muitos administradores usam tail para monitorar atividades ativas ou recentes. Essa funcionalidade está embutida no journalctl, permitindo acessar esses recursos sem precisar utilizar uma outra ferramenta.

      Exibir registros recentes

      Para exibir uma quantidade definida de registros, use a opção -n, que funciona exatamente como tail -n.

      Por padrão, ele irá exibir as 10 entradas mais recentes:

      journalctl -n
      

      Especifique o número de entradas que quer ver com um número após o -n:

      journalctl -n 20
      

      Acompanhar registros

      Para acompanhar ativamente os registros à medida que são escritos, use o sinalizador -f. Novamente, isso funciona como o esperado, caso você tenha experiência usando o tail -f:

      journalctl -f
      

      Manutenção do diário

      Você deve estar se perguntando sobre o custo do armazenamento de todos os dados que vimos até agora. Além disso, você pode estar interessado em limpar alguns registros mais antigos e liberar o espaço.

      Descobrir o uso atual em disco

      É possível descobrir a quantidade de espaço que diário está ocupando no disco usando o sinalizador --disk-usage:

      journalctl --disk-usage
      
      Journals take up 8.0M on disk.
      

      Deletar registros antigos

      Se quiser reduzir o tamanho do seu diário, você pode fazer isso de duas maneiras diferentes (disponível com a versão 218 do systemd ou superior).

      Usando a opção --vacuum-size, você pode reduzir o tamanho do diário indicando um tamanho. Isso irá remover entradas antigas até o espaço total que o diário ocupa em disco esteja no tamanho solicitado:

      sudo journalctl --vacuum-size=1G
      

      Outra maneira para reduzir o tamanho do diário é fornecendo um tempo de corte com a opção --vacuum-time. Todas as entradas além daquele momento são excluídas. Isso permite manter as entradas que foram criadas após um tempo específico.

      Por exemplo, para manter as entradas do último ano, digite:

      sudo journalctl --vacuum-time=1years
      

      Limitar a expansão do diário

      É possível configurar seu servidor para colocar limites sobre a quantidade de espaço que diário pode ocupar. Isso pode ser feito editando o arquivo /etc/systemd/journald.conf.

      Os itens a seguir podem ser usados para limitar o crescimento do diário:

      • SystemMaxUse=: especifica o espaço máximo em disco que pode ser usado pelo diário em armazenamento persistente.
      • SystemKeepFree=: especifica a quantidade de espaço que o diário deve deixar livre no armazenamento persistente ao adicionar entradas.
      • SystemMaxFileSize=: controla o tamanho máximo até o qual os arquivos de diário individuais podem crescer em armazenamento persistente antes de serem girados.
      • RuntimeMaxUse=: especifica o espaço máximo em disco que pode ser usado como armazenamento volátil (dentro do sistema de arquivos /run).
      • RuntimeKeepFree=: especifica a quantidade de espaço a ser reservada para outros usos ao escrever dados no armazenamento volátil (dentro do sistema de arquivos /run).
      • RuntimeMaxFileSize=: especifica a quantidade de espaço que um arquivo de diário individual pode ocupar em armazenamento volátil (dentro do sistema de arquivos /run) antes de ser girado.

      Ao definir esses valores, você pode controlar como o journald consome e preserva o espaço no seu servidor. Tenha em mente que o SystemMaxFileSize e o RuntimeMaxFileSize irão mirar em arquivos arquivados para alcançar os limites declarados. Isso é importante de lembrar ao interpretar contagens de arquivos após uma operação de limpeza.

      Conclusão

      Como foi visto, o diário do systemd é incrivelmente útil para coletar e gerenciar seus dados de sistema e de aplicativo. A maior parte da sua flexibilidade vem da grande quantidade de metadados que são registrados automaticamente e da natureza centralizada do registro. O comando journalctl torna mais fácil aproveitar as funcionalidades avançadas do diário e fazer análises extensas e depuração relacional de diferentes componentes de aplicativos.



      Source link

      Cómo centralizar los registros con Journald en Ubuntu 20.04


      El autor seleccionó la Free and Open Source Fund para recibir una donación como parte del programa Write for DOnations.

      Introducción

      Los registros de sistemas son un componente extremadamente importante para administrar sistemas Linux. Proporcionan una visión valiosa sobre cómo funcionan los sistemas y cómo se utilizan porque, además de errores, registran información operativa como eventos de seguridad. La configuración estándar para sistemas Linux es almacenar sus registros localmente en el mismo sistema donde se produjeron. Esto funciona para sistemas independientes, pero rápidamente se convierte en un problema, ya que aumenta el número de sistemas. La solución para administrar todos estos registros es crear un servidor de registro centralizado donde cada host Linux envía sus registros en tiempo real a un servidor de administración de registros específico.

      Una solución de registro centralizada ofrece varias ventajas en comparación con el almacenamiento de registros en cada host:

      • Reduce la cantidad de espacio de disco necesaria en cada host para almacenar archivos de registro.
      • Los registros pueden mantenerse más tiempo, ya que el servidor de registro específico puede configurarse con más capacidad de almacenamiento.
      • Pueden realizarse análisis de registro avanzados que requieren registros de varios sistemas y también más recursos informáticos de los que puede estar disponible en los hosts.
      • Los administradores de sistemas pueden acceder a los registros para todos sus sistemas a los que, quizá, no puedan acceder directamente por razones de seguridad.

      En esta guía, configurará un componente de la serie de herramientas systemd para transmitir mensajes de registro desde los sistemas de cliente a un servidor de recopilación de registros centralizado. Configurará el servidor y el cliente para que utilicen certificados TLS para cifrar los mensajes de registro, ya que se transmiten a través de redes inseguras como Internet y también para autenticarse.

      Requisitos previos

      Para completar esta guía, necesitará lo siguiente:

      • Dos servidores Ubuntu 20.04.
      • Un usuario no root con privilegios sudo en ambos servidores. Siga la guía de configuración inicial de servidor con Ubuntu 20.04 para obtener instrucciones sobre cómo hacerlo. También debería configurar el firewall UFW en ambos servidores como se explica en la guía.
      • Dos nombres de host que apuntan a sus servidores. Un nombre de host para el sistema cliente que genera los registros y otro para el servidor de compilación de registros. Descubra cómo apuntar nombres de host a DigitalOcean Droplets consultando la documentación sobre dominios y DNS.

      Esta guía utilizará los dos nombres de host siguientes:

      • client.your_domain: el sistema de cliente que genera los registros.
      • server.your_domain: el servidor de compilación de registro.

      Inicie sesión en el cliente y en el servidor en terminales independientes a través de SSH como en el usuario sudo no root para empezar este tutorial.

      Nota: A lo largo del tutorial, se etiquetan los bloques de comandos con el nombre de servidor (cliente o servidor) en el que debería ejecutarse el comando.

      Paso 1: Instalar systemd-journal-remote

      En este paso, instalará el paquete systemd-journal-remote en el cliente y en el servidor. Este paquete contiene los componentes que utilizan el cliente y el servidor para transmitir los mensajes de registro.

      Primero, en el cliente y en el servidor, ejecute una actualización de sistema para garantizar que la base de datos de paquetes y el sistema estén actualizados:

      Client and Server

      • sudo apt update
      • sudo apt upgrade

      A continuación, instale el paquete systemd-journal-remote:

      Client and Server

      • sudo apt install systemd-journal-remote

      En el servidor, habilite e inicie los dos componentes systemd que necesita para recibir mensajes de registro con el siguiente comando:

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket
      • sudo systemctl enable systemd-journal-remote.service

      La opción --now en el primer comando inicia los servicios de inmediato. No lo utilizó en el segundo comando, ya que este servicio no se iniciará hasta que tenga certificados TLS, lo que creará en el siguiente paso.

      En el cliente, habilite el componente que systemd utiliza para enviar los mensajes de registro al servidor:

      Client

      • sudo systemctl enable systemd-journal-upload.service

      A continuación, en el servidor, abra los puertos 19532 y 80 en el firewall UFW. Esto permitirá al servidor recibir los mensajes de registro del cliente. El puerto 80 es el puerto que certbot utilizará para generar el certificado TLS. Los siguientes comandos abrirán estos puertos:

      Server

      • sudo ufw allow in 19532/tcp
      • sudo ufw allow in 80/tcp

      En el cliente, solo deberá abrir el puerto 80 con este comando:

      Client

      Ahora ha instalado los componentes necesarios y ha completado la configuración del sistema base en el cliente y en el servidor. Antes de que pueda configurar estos componentes para que empiecen a retransmitir los mensajes de registro, registrará los certificados TLS Let’s Encrypt para el cliente y el servidor usando la utilidad certbot.

      Paso 2: Instalar certificados de registro y Certbot

      Let’s Encrypt es una autoridad de certificación que emite certificados TLS gratuitos. Estos certificados permiten a los ordenadores cifrar los datos que envían entre ellos y también verificar la identidad de cada uno. Estos certificados le permiten proteger su navegación en Internet con HTTPS. Cualquier otra aplicación que quiera el mismo nivel de seguridad, puede usar los mismos certificados. El proceso de registro del certificado es el mismo sin importar para lo que los use.

      En este paso, instalará la utilidad certbot y la usará para registrar los certificados. También automáticamente se ocupará de renovar los certificados cuando expiren. El proceso de registro aquí es el mismo en el cliente y en el servidor. Solo deberá cambiar el nombre de host para que coincida con el host donde está ejecutando el comando de registro.

      Primero, habilite el repositorio universe de Ubuntu, ya que la utilidad certbot reside en el repositorio universe. Si ya tiene el repositorio universe habilitado, la ejecución de estos comandos es segura y no le hará a su sistema:

      Client and Server

      • sudo apt install software-properties-common
      • sudo add-apt-repository universe
      • sudo apt update

      A continuación, instale certbot en ambos hosts:

      Client and Server

      Ahora que ha instalado certbot, ejecute el siguiente comando para registrar los certificados en el cliente y en el servidor:

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      Las opciones de este comando significan lo siguiente:

      • certonly: registra el certificado y no realiza otros cambios en el sistema.
      • --standalone: utiliza el servidor web integrado de certbot para verificar la solicitud de certificado.
      • --agree-tos: acepta de forma automática los Términos de uso de Let’s Encrypt.
      • --email your-email: esta es la dirección de correo electrónico que Let’s Encrypt usará para notificarle sobre la expiración del certificado y otra información importante.
      • -d your_domain: el nombre de host para el que se registrará el certificado. Debe coincidir con el sistema donde lo ejecuta.

      Cuando ejecute este comando, se le solicitará si quiere compartir la dirección de correo electrónico con Let’s Encrypt para que puedan enviarle por correo electrónico noticias y otra información sobre su trabajo. Hacerlo es opcional, si no comparte su dirección de correo electrónico, el registro de certificados se completará de forma normal.

      Cuando se complete el proceso de registro de certificado, colocará el certificado y los archivos de clave en /etc/letsencrypt/live/your_domain/ donde your_domain es el nombre de host para el que registró el certificado.

      Por último, deberá descargar una copia de los certificados intermedios y de la autoridad de certificación Let’s Encrypt y ponerlos en el mismo archivo. journald usará este archivo para verificar la autenticidad de los certificados en el cliente y en el servidor cuando se comuniquen entre ellos.

      El siguiente comando descargará los dos certificados desde el sitio web Let’s Encrypt y los pondrá en un solo archivo llamado letsencrypt-combined-certs.pem en el directorio de inicio de su usuario.

      Ejecute este comando en el cliente y en el servidor para descargar los certificados y crear un archivo combinado:

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      A continuación, mueva este archivo al directorio Let’s Encrypt que contiene los certificados y las claves:

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

      Ahora ha registrado los certificados y las claves. En el siguiente paso, configurará el servidor de compilación de registro para que empiece a escuchar y almacenar los mensajes de registro del cliente.

      Paso 3: Configuración del servidor

      En este paso, configurará el servidor para que utilice el certificado y los archivos de clave que generó en el último paso, de forma que pueda comenzar a aceptar los mensajes de registro del cliente.

      systemd-journal-remote es el componente que escucha los mensajes de registro. Abra su archivo de configuración en /etc/systemd/journal-remote.conf con un editor de texto para empezar a configurarlo en el servidor:

      • sudo nano /etc/systemd/journal-remote.conf

      A continuación, elimine todas las líneas de la sección [remoto] y establezca las rutas para que apunten a los archivos TLS que acaba de crear:

      /etc/systemd/journal-remote.conf

      [Remote]
      Seal=false
      SplitMode=host
      ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem
      

      Aquí están las opciones que ha utilizado:

      • Seal=false: firma los datos de registro en el diario. Habilítelo si necesita una máxima seguridad; de lo contrario, puede dejarlo como false.
      • SplitMode=host: los registros de los clientes remotos se dividen host en /var/log/journal/remote. Si prefiere que se añadan todos los registros a un solo archivo configúrelo a SplitMode=false.
      • ServerKeyFile: el archivo de clave privada del servidor.
      • ServerCertificateFile: el archivo de certificado del servidor.
      • TrustedCertificateFile: el archivo que contiene los certificados de la autoridad de certificación Let’s Encrypt.

      Ahora, deberá cambiar los permisos en los directorios Let’s Encrypt que contienen los certificados y la clave para que systemd-journal-remote los pueda leer y usar.

      Primero, cambie los permisos para que el certificado y la clave privada se puedan leer:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      A continuación, cambie la propiedad de grupo de la clave privada al grupo systemd-journal-remote:

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Ahora puede iniciar systemd-journal-remote:

      • sudo systemctl start systemd-journal-remote.service

      Ahora se está ejecutando su servidor de compilación de registro y está listo para comenzar a aceptar mensajes de registro de un cliente. En el siguiente paso, configurará el cliente para que envíe los registros a su servidor de compilación.

      Paso 4: Configurar el cliente

      En este paso, configurará el componente que transmite los mensajes de registro al servidor de compilación de registro. Este componente se llama systemd-journal-upload.

      La configuración predeterminada para systemd-journal-upload es la que utiliza un usuario temporal que solo existe mientras se está ejecutando. Esto permite que systemd-journal-upload lea los certificados TLS y las claves más complicadas. Para resolverlo, creará un nuevo usuario de sistema con el mismo nombre que el usuario temporal que se utilizará en su lugar.

      Primero, cree el nuevo usuario llamado systemd-journal-upload en el cliente con el siguiente comando adduser:

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Estas opciones al comando son:

      • --system: crea el nuevo usuario como un usuario de sistema. Le da al usuario un número UID (Identificador de usuario) inferior a 1000. Normalmente, los UID superiores a 1000 se dan a las cuentas de usuario con las que un humano iniciará sesión.
      • --home /run/systemd: establece /run/systemd como el directorio de inicio de este usuario.
      • --no-create-home: no crea el conjunto de directorio de inicio, puesto que ya existe.
      • --disabled-login: el usuario no puede iniciar sesión en el servidor a través de SSH, por ejemplo.
      • --group: crea un grupo con el mismo nombre que el usuario.

      A continuación, establezca los permisos y la propiedad de los archivos del certificado Let’s Encrypt:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Ahora, edite la configuración para systemd-journal-upload, que está en /etc/systemd/journal-upload.conf. Abra este archivo con un editor de texto:

      • sudo nano /etc/systemd/journal-upload.conf

      Edite este archivo de forma que se parezca a lo siguiente:

      /etc/systemd/journal-upload.conf

      [Upload]
      URL=https://server.your_domain:19532
      ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem
      

      Por último, reinicie el servicio systemd-journal-upload para que utilice la nueva configuración:

      • sudo systemctl restart systemd-journal-upload.service

      Ahora su cliente está configurado y ejecutándose, y envía sus mensajes de registro al servidor de compilación de registro. En el siguiente paso, comprobará que se están enviando los registros de forma correcta.

      Paso 5: Probar el cliente y el servidor

      En este paso, probará que el cliente está enviando mensajes de registro al servidor y que el servidor los almacena correctamente.

      El servidor de compilación de registro almacena los registros de los clientes en un directorio en /var/log/journal/remote/. Cuando reinició el cliente al final del último paso, comenzó a enviar mensajes de registro, de forma que ahora hay un archivo de registro en /var/log/journal/remote/. El archivo será llamará como el nombre de host que utilizó para el certificado TLS.

      Utilice el comando ls para comprobar que el archivo de registro del cliente está presente en el servidor:

      Server

      • sudo ls -la /var/log/journal/remote/

      Esto imprimirá el contenido del directorio que muestra el archivo de registro:

      Output

      total 16620 drwxr-xr-x 2 systemd-journal-remote systemd-journal-remote 4096 Jun 30 16:17 . drwxr-sr-x+ 4 root systemd-journal 4096 Jun 30 15:55 .. -rw-r----- 1 systemd-journal-remote systemd-journal-remote 8388608 Jul 1 10:46 'remote-CN=client.your_domain'

      A continuación, escriba un mensaje de registro en el cliente para comprobar que el servidor está recibiendo los mensajes del cliente como se espera. Usará la utilidad logger para crear un mensaje de registro personalizado en el cliente. Si todo está funcionando, systemd-journal-upload transmitirá este mensaje al servidor.

      En el cliente ejecute el siguiente comando logger:

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      El -p syslog.debug en este comando establece la instalación y la gravedad del mensaje. Configurar esto a syslog.debug aclarará que es un mensaje de prueba. Este comando grabará el mensaje ### TEST MESSAGE from client.your_domain ### al diario del cliente, que systemd-journal-upload transmitirá al servidor.

      A continuación, lea el archivo de diario del cliente en el servidor para comprobar que los mensajes de registro están llegando desde el cliente. Este archivo es un archivo de registro binario, de forma que no podrá leerlo con herramientas como less. En su lugar, lea el archivo usando journalctl con la opción --file= que le permite especificar un archivo de diario personalizado:

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      El mensaje de registro aparecerá como se muestra:

      Test log message

      . . . Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Ahora su servidor de centralización de registro está recopilando correctamente los registros de su sistema de cliente.

      Conclusión

      En este artículo, configuró un servidor de compilación central de registro y configuró un cliente para que transmitiera una copia de sus registros de sistema al servidor. Puede configurar tantos clientes como necesite para transmitir los mensajes al servidor de compilación de registro usando los pasos de configuración del cliente que utilizó aquí.



      Source link