La determinación de problemas puede ser tanto un arte como una ciencia y, a veces, parece que incluso un poco de magia puede ser útil. Todo el mundo se ha encontrado con situaciones en las que no se ha podido reproducir un fallo informado, lo que siempre es frustrante tanto para el usuario como para el administrador del sistema. Incluso los electrodomésticos y los automóviles pueden ser obstinados y negarse a fallar cuando aparece el técnico de servicio.
Dejando de lado el antropomorfismo, los administradores de sistemas tienen algunas herramientas que pueden mostrar lo que ha estado sucediendo en sus computadoras Linux con diversos grados de granularidad. Hay herramientas, como top, htop, looks, sar, iotop, tcpdump, traceroute, mtr, iptraf-ng, df, du y muchas más, todas las cuales pueden mostrar el estado actual de un host y varias de las cuales pueden producir registros. de varios niveles de detalle.
Si bien estas herramientas se pueden usar para encontrar problemas continuos, no son particularmente útiles para problemas transitorios o aquellos que no tienen síntomas observables directamente, al menos no observables hasta que ocurra algún problema importante y posiblemente catastrófico.
Una herramienta importante que uso para la determinación de problemas son los registros del sistema y, con systemd, los diarios del sistema. El diario systemd es siempre una de las primeras herramientas a las que recurro cuando resuelvo un problema, especialmente los problemas que no parecen ocurrir cuando estoy mirando. Me tomó mucho tiempo al comienzo de mi carrera de administrador de sistemas darme cuenta de la gran cantidad de información en los archivos de registro, y este descubrimiento mejoró en gran medida mi velocidad para resolver problemas.
Ya has visto algunos usos del journalctl comando en muchos de los artículos anteriores de esta serie. En este artículo, exploraré algunos detalles sobre systemd journal, cómo funciona y formas de usar journalctl para localizar e identificar problemas.
Acerca de las revistas
El propósito de cualquier registro o diario es mantener un historial secuenciado en el tiempo de las actividades normales de los servicios y programas que se ejecutan en un host y registrar cualquier error o mensaje de advertencia que ocurra. Los mensajes de registro solían mantenerse en archivos separados en /var/log , generalmente un archivo para el núcleo y archivos separados para la mayoría de los servicios que se ejecutan en el host. Desafortunadamente, la gran cantidad de archivos de registro podría dispersar la información necesaria y retrasar el descubrimiento de la causa raíz de un problema. Esto podría llevar mucho tiempo cuando intenta determinar qué estaba sucediendo en un sistema cuando ocurrió un error.
El antiguo /var/log/dmesg El archivo se usaba generalmente para el núcleo, pero ese archivo fue descontinuado hace varios años a favor del uso de dmesg comando para mostrar la misma información e integrar esos mensajes (y más) en el /var/log/messages expediente. Esta fusión de otros registros en los mensajes El archivo ayudó a acelerar la determinación de problemas al mantener gran parte de los datos en un solo archivo, pero todavía había muchos servicios cuyos registros no estaban integrados en los mensajes más centrales. archivo.
El diario systemd está diseñado para recopilar todos los mensajes en una estructura única y unificada que puede mostrar una imagen completa de todo lo que sucedió en un sistema en y alrededor de un momento o evento específico. Debido a que los eventos, independientemente de la fuente, están en un lugar y en una secuencia de tiempo, es posible ver de un vistazo todo lo que sucede en un punto específico o rango de tiempo. En mi opinión, este es uno de los principales beneficios de systemd journaling.
Acerca del diario systemd
El servicio de registro en diario systemd es implementado por el systemd-journald demonio. Según el systemd-journald página man:
systemd-journald es un servicio del sistema que recopila y almacena datos de registro. Crea y mantiene revistas estructuradas e indexadas basadas en la información de registro que se recibe de una variedad de fuentes:
- Mensajes de registro del kernel, a través de
kmsg - Mensajes de registro del sistema simples, a través de
libc syslog(3)llamar - Mensajes de registro del sistema estructurado a través de la API nativa de Journal, consulte
sd_journal_print(3) - Salida estándar y error estándar de las unidades de servicio. Para obtener más detalles, consulte a continuación.
- Registros de auditoría, que se originan en el subsistema de auditoría del kernel
El demonio recopilará implícitamente numerosos campos de metadatos para cada mensaje de registro de forma segura e infalsificable. Ver systemd.journal-fields(7) para obtener más información sobre los metadatos recopilados.
Los datos de registro recopilados por la revista se basan principalmente en texto, pero también pueden incluir datos binarios cuando sea necesario. Los campos individuales que componen un registro almacenado en el diario pueden tener un tamaño de hasta 2^64-1 bytes.
Cambios de configuración
Más recursos de Linux
- Hoja de trucos de los comandos de Linux
- Hoja de trucos de comandos avanzados de Linux
- Curso en línea gratuito:Descripción general técnica de RHEL
- Hoja de trucos de red de Linux
- Hoja de trucos de SELinux
- Hoja de trucos de los comandos comunes de Linux
- ¿Qué son los contenedores de Linux?
- Nuestros últimos artículos sobre Linux
El daemon de diario de systemd se puede configurar usando /etc/systemd/journald.conf expediente. Para muchos hosts, este archivo no necesita ningún cambio porque los valores predeterminados son bastante razonables. Mire su journald.conf presente su archivo ahora, si aún no lo ha hecho.
Los cambios de configuración más comunes que podría considerar especificarían el tamaño máximo del archivo de diario, la cantidad de archivos de diario más antiguos y los tiempos máximos de retención de archivos. La razón principal para realizar esos cambios sería reducir el espacio de almacenamiento utilizado por la revista si tiene un dispositivo de almacenamiento pequeño. En un entorno de misión crítica, es posible que también desee reducir la cantidad de tiempo entre la sincronización de los datos del diario almacenados en la memoria RAM con el dispositivo de almacenamiento.
El journald.conf La página del manual tiene más detalles.
Controversias sobre el formato de datos
Una de las controversias que rodean a systemd es el formato binario en el que se almacenan los contenidos de las revistas. Algunos argumentos en contra de systemd se basan en que el diario de systemd se almacena en formato binario. Esto parecería ser contrario a la filosofía de Unix/Linux de usar texto ASCII para datos, que es un argumento que la gente usa para justificar su disgusto por systemd. Por ejemplo, Doug McIlroy, el inventor de las pipas, dijo:
"Esta es la Filosofía de Unix:Escribir programas que hagan bien una cosa. Escribir programas para trabajar juntos. Escribir programas para manejar flujos de texto, porque esa es una interfaz universal". —Doug McIlroy, citado en el libro de Eric S. Raymond The Art of Unix Programming
Sin embargo, estos argumentos parecen estar basados en al menos un concepto erróneo parcial porque la página del manual establece claramente que los datos "están principalmente basados en texto", aunque permite formas de datos binarios. El creador del kernel de Linux, Linus Torvalds, quien siempre tiene claros sus sentimientos, dijo:
"En realidad, no tengo opiniones particularmente sólidas sobre systemd en sí. He tenido problemas con algunos de los principales desarrolladores que creo que son demasiado arrogantes con respecto a los errores y la compatibilidad, y creo que algunos de los detalles de diseño son una locura (yo no me gustan los registros binarios, por ejemplo), pero esos son detalles, no grandes problemas". —Linus Torvalds, citado en "Linus Torvalds and others on Linux's systemd" de ZDNet en 2014
Los archivos de diario systemd se almacenan en uno o más subdirectorios de /var/log/journal . Inicie sesión en un sistema de prueba en el que tenga acceso de root y cree /var/log/journal el directorio de trabajo actual (PWD). Enumere los subdirectorios allí, elija uno y conviértalo en PWD. Puede consultar estos archivos de varias formas. Empecé con el stat comando (tenga en cuenta que los nombres de los archivos de diario en su host serán diferentes a los míos):
[root @ testvm1 3bccd1140fca488187f8a1439c832f07] # stat system@7ed846aadf1743139083681ec4042037-0000000000000001-0005a99c0280fd5f.journal
del archivo:system@7ed846aadf1743139083681ec4042037-0000000000000001-0005a99c0280fd5f.journal
Tamaño:8388608 Bloques:16392 IO Block:4096 regulares archivo
Dispositivo:fd04h/64772d Inodo:524384 Enlaces:1
Acceso:(0640/-rw-r-----) Uid:( 0/ root) Gid:( 190/systemd-journal )
Acceso:2020-07-13 08:30:05.764291231 -0400
Modificar:2020-07-04 07:33:52.916001110 -0400
Cambio:2020-07-04 07:33:52.916001110 -0400
Nacimiento:-
[root@testvm1 3bccd1140fca488187f8a1439c832f07]#
El archivo de diario se identifica como un archivo "regular", que no es especialmente útil. El archivo El comando lo identifica como un archivo de "diario", pero ya lo sabe. Mire dentro del archivo con el dd dominio. El siguiente comando envía el flujo de datos de salida a STDOUT; es posible que desee canalizarlo a través de less localizador:
[root@testvm1 3bccd1140fca488187f8a1439c832f07]# dd if=system@7ed846aadf1743139083681ec4042037-0000000000000001-0005a99c0280fd5f.journal | menos
9�P1�8��9_SOURCE_MONOTONIC_TIMESTAMP=191726���/��P��9MESSAGE=Inode-cache hash table entradas:1048576 (orden:11, 8388608 bytes , lineal)�hx
9�P1�p�9��/��P�b��9��9_SOURCE_MONOTONIC_TIMESTAMP=191825�pdXY�7p�9��9MESSAGE=mem auto-init :stack:off, heap alloc:off, heap free:off�i��
��(n�O���@Y� ���Z �82���7X�8 �����8��DZR�����8<~B�4�<� �8tM˞8$����8��Ж��h9�&������9 �����`@�9�pdXY�7b�ͺ��WV��9��9_SOURCE_MONOTONIC_TIM
ESTAMP=234745����4�h@�9��9MESSAGE=Memoria:12598028K/12963384K disponible (14339K código kernel, 2406K rwdata, 8164K rodata, 2468K init, 5072K b
ss, 365356K reservado, 0K cma-reservado)�j��(n�O�@Y� ��� �]��m�82���7X�8�������8��DZR�����8<~B�4�<� �8tM˞8$��8�� Æ��h9�&�����9�ͺ��WV��9���
4�hbB�a��^��9��9_SOURCE_MONOTONIC_TIMESTAMP=234758��3�� �9��9MESSAGE=random:get_random_u64 llamado desde __kmem_cache_create+0x3e/0x610 wi
th crng_init=0�k���(n�O���@Y� ����j��� �82�7X��8C�X�Y"��8�������8��DZR���8<~B�4�<� �8tM˞8$� �8� �Ж�à�9B���a�9�3��b�8�ȭ���9h�9_SO�9h�9MESSAGE=SLUB:HWalign=64, Order=0-3, MinObjects =0, CPU=4, Nodos=1�l����(n�O���@Y� ������z��X�82���7X�8������ �8��DZR�����8<~B�4�<� �8tM˞
b�(+I)�x�9�9_SOURCE_MONOTONIC_TIMESTAMP=235444r�%/p��9�9 MENSAJE =Aislamiento de tablas de páginas de kernel/usuario:activado�m����(n�O���@Y� ��k��B0��8
2���7X�8��� ��8��DZR�����8<~B�4�<� �8tM˞8$��8��Ж��h9�&��8�9�(+ I) Ҡ�9�%/pb8O{ W���8�9��9_SOURCE_MONOTONIC_TIMESTAMP=235464u�N`�FP M��9
��9MESSAGE=ftrace:asignación de 41361 entradas en 162 páginas�n ����(n�O���@Y�
Incluso esta pequeña porción del flujo de datos del dd El comando muestra una mezcla interesante de texto ASCII y datos binarios. Otra herramienta útil son las strings comando, que simplemente muestra todas las cadenas de texto ASCII contenidas en un archivo e ignora los datos binarios:
[root @ testvm1 3bccd1140fca488187f8a1439c832f07] # cuerdas system@7ed846aadf174313908368Ec042037-0000000000000001-0000000000000001-0000000000000001-0005f.journal
Mensaje =Linux versión 5.7.6-201.fc32.x86_64 ([email protected] .fedoraproject.org) (gcc versión 10.1.1 20200507 (Red Hat 10.1.1-1) (GC
C), GNU ld versión 2.34-3.fc32) #1 SMP lunes 29 de junio 15:15:52 UTC 2020
MENSAJE
_BOOT_ID=6e944f99ebd9405984090f829a927fa4
_BOOT_ID
_MACHINE_ID=3bccd1140fca488187f8a1439c832f07
_MACHINE_ID
_HOSTbo>_testvm1.org
_HOSTbo>_thvSTNAME
>PRIORIDAD=6
MENSAJE=Línea de comando:BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.7.6-201.fc32.x86_64 root=/dev/mapper/VG01-root ro resume=/dev/mapper/ VG01-swap rd.lv
m.lv=VG01/root rd.lvm.lv=VG01/swap rd.lvm.lv=VG01/usr selinux=0
MESSAGE=x86/fpu:Compatibilidad con XSAVE función 0x001:'x87 registros de coma flotante'
MESSAGE=x86/fpu:función XSAVE compatible 0x002:'registros SSE'
MESSAGE=x86/fpu:función XSAVE compatible 0x00 4:'Registros AVX'
Z_g3;
MESSAGE=x86/fpu:xstate_offset[2]: 576, xstate_sizes[2]: 256
Z_g3;
MESSAGE=x86/fpu :Funciones xstate habilitadas 0x7, el tamaño del contexto es de 832 bytes, usando formato 'estándar'.
MESSAGE=mapa de RAM físico proporcionado por BIOS:
`k2X
MESSAGE=BIOS-e820:[mem 0x0000000000000000 -0x000000000009fbff] USABLE
MENSAJE =BIOS-E820:[MEM 0x00000000000009FC00-0X00000000000009FFFFF] Reservado
Mensaje =BIOS-E820:[MEM 0x00000000000F0000-0X0000000000000FFFFFF] Reservado
PYLM
MENSAJE =BIOS -e820:[MEM 0x0000000000100000-0x0000000000dffffff] USABLE
MENSAJE =BIOS-E820:[MEM 0x0000000000DFF0000-0X0000000000DFFFFFFF] ACPI Datos
Mensaje =BIOS-E820:[MEM 0x00000000FEC00000-0X0000000000FEC00FFF] Reservado
Mensaje =BIOS-E820:[MEM 0x00000000FEE00000-0X00000000FEE00FFF] Reservado
Mensaje =BIOS-E820:[MEM 0x0000000000FFFC0000-0x0000000000FFFFFFFF] Reservado
Mensaje =BIOS-E820:[MEM 0x0000000100000000-0x00000003373FFFFFFFF] Utilizable
Estos datos pueden ser interpretados por humanos, y este segmento en particular se ve muy similar al flujo de datos de salida del dmesg dominio. Te dejaré explorar más por tu cuenta, pero mi conclusión es que los archivos de diario son claramente una mezcla de texto binario y ASCII. Esa combinación hace que sea engorroso usar las herramientas tradicionales de Linux basadas en texto para extraer datos utilizables. Pero hay una forma mejor que brinda muchas posibilidades para extraer y ver datos de diarios.
Acerca de journalctl
El diarioctl El comando está diseñado para extraer información utilizable de los diarios systemd utilizando criterios potentes y flexibles para identificar los datos deseados. Los artículos anteriores de esta serie han descrito journalctl , y hay más que saber.
Revisaré un poco primero y comenzaré con algunos conceptos básicos en caso de que no haya leído los artículos anteriores o simplemente necesite un repaso.
Puedes usar el journalctl Comando sin opciones ni argumentos para ver el diario systemd que contiene toda la información de registro y diario:
[root@testvm1 ~]# journalctl
-- Los registros comienzan el lunes 2020-06-08 07:47:20 EDT, terminan el jueves 2020-07-16 10:30:43 EDT. --
8 de junio 07:47:20 kernel testvm1.both.org:Linux versión 5.6.6-300.fc32.x86_64 ([email protected]) (gcc versión 10.0>
08 de junio 07:47:20 testvm1.both.org kernel:línea de comandos:BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.6.6-300.fc32.x86_64 root=/dev/mapper/VG01-root ro>
08 de junio 07:47:20 kernel testvm1.both.org:x86/fpu:Compatibilidad con la función XSAVE 0x001:'x87 registros de punto flotante'
08 de junio 07:47:20 kernel testvm1.both.org:x86/fpu:Compatibilidad con la función XSAVE 0x002:'Registros SSE'
8 de junio 07:47:20 testvm1.both.org kernel:x86/fpu:Compatibilidad con la función XSAVE 0x004:'Registros AVX'
8 de junio 07:47:20 kernel testvm1.both.org:x86/fpu:xstate_offset[2]: 576, xstate_sizes[2]: 256
8 de junio 07:47:20 kernel testvm1.both.org:x86/fpu :Funciones xstate habilitadas 0x7, el tamaño del contexto es de 832 bytes, utilizando el formato 'estándar'. :47:20 núcleo testvm1.both.org:BIOS-e820:[mem 0x00 00000000000000-0x000000000009fbff] utilizable
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:[1594907460.1765] dhcp4 (enp0s3):opción de enrutadores_solicitados => '1 '
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:[1594907460.1765] dhcp4 (enp0s3):opción rutas_estáticas_solicitadas => '1'
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:[1594907460.1765] dhcp4 (enp0s3):opción solicitada_subnet_mask => '1'
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:[1594907460.1765] dhcp4 (enp0s3):opción request_time_offset => '1'
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:[1594907460.1766] dhcp4 (enp0s3):opción solicitada_wpad => '1'
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:[1594907460.1766] dhcp4 (enp0s3):opción enrutadores => '192.168.0.2>
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:[1594907460.1766] dhcp4 (enp0s3):opción subred_ mask => '255.255.255>
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:[1594907460.1766] dhcp4 (enp0s3):estado cambiado extendido -> extendido
16 de julio 09:51:00 testvm1.both.org systemd[1]:Iniciando el servicio de distribución de secuencias de comandos de Network Manager...
16 de julio 09:51:00 testvm1.both.org systemd[1]:Administrador de red iniciado Script Dispatcher Service.
16 de julio 09:51:00 testvm1.both.org audit[1]:SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher com>
16 de julio 09:51:10 testvm1.both.org systemd[1]:NetworkManager-dispatcher.service:Succeeded.
16 de julio 09:51:10 testvm1.both.org audit[1]:SERVICE_STOP pid =1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm>
16 de julio 09:59:13 testvm1.both.org systemd[1]:Iniciando dnf makecache...
16 de julio 09:59:13 testvm1.both.org audit[1]:SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dnf-makecache comm="systemd">
16 de julio 09:59:13 testvm1.both.org audit[1]:SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dnf-makecache comm="systemd" e>
16 de julio 09:59:13 testvm1.both.org systemd[1]:dnf-makecache.service:Correcto.
16 de julio 09:59:13 testvm1.both.org systemd[1]:Finalizó dnf makecache.
16 de julio 09 :59:14 testvm1.both.org dnf[378549]:Caché de metadatos actualizado recientemente.
16 de julio 10:00:42 testvm1.both.org systemd[1]:Iniciando herramienta de contabilidad de actividad del sistema...
16 de julio 10:00:42 testvm1.both.org systemd[1]:sysstat-collect.service:Succeeded.
16 de julio 10:00:42 testvm1.both.org audit[1]:SERVICE_START pid =1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd>
16 de julio 10:00:42 testvm1.both.org systemd[1]:herramienta de contabilidad de actividad del sistema finalizada .
16 de julio 10:00:42 testvm1.both.org audit[1]:SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd">
16 de julio 10:01:01 testvm1.both.org CROND[378562]:(raíz) CMD (run-parts /etc/cron.hourly)
16 de julio 10:01:01 testvm1.both.org run-parts[378565]:(/etc/cron.hourly) a partir de 0anacron
16 de julio 10:01:01 testvm1.both.org run-parts[378571]:(/etc/cron.hourly) terminó 0anacron
También puede mostrar explícitamente los mismos datos el dmesg presenta el comando. Abra dos sesiones de terminal una al lado de la otra y emita el dmesg comando en uno y el siguiente comando en el otro:
[raíz@testvm1 ~]# journalctl --dmesg
La única diferencia que debería ver es el formato de hora. El dmesg El comando está en un formato monótono que muestra la cantidad de segundos desde que se inició el sistema. El diarioctl la salida tiene un formato de fecha y hora. La opción monótona corta muestra el tiempo desde el arranque:
[root@testvm1 ~]# journalctl --dmesg -o short-monotonic
-- Los registros comienzan el lunes 2020-06-08 07:47:20 EDT, finalizan el lunes 2020-07-20 13 :01:01 EDT. --
[ 0.000000] testvm1.both.org kernel:Linux versión 5.7.6-201.fc32.x86_64 ([email protected]) (gcc versión 10.1.>
[ 0.000000 ] testvm1.both.org kernel:línea de comando:BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.7.6-201.fc32.x86_64 root=/dev/mapper/VG01-root ro r>
[ 0.000000] kernel testvm1.both.org:x86/fpu:función XSAVE compatible 0x001:'registros de coma flotante x87'
[ 0.000000] kernel testvm1.both.org:x86/fpu:función XSAVE compatible 0x002:'registros SSE'
[ 0.000000] testvm1.both.org kernel:x86/fpu:Compatibilidad con la función XSAVE 0x004:'Registros AVX'
[ 0.000000] testvm1.both.org kernel:x86/fpu:xstate_offset[2]: 576 , xstate_sizes[2]: 256
[ 0.000000] testvm1.both.org kernel:x86/fpu:características de xstate habilitadas 0x7, el tamaño del contexto es 832 bytes, utilizando el formato 'estándar'.
[ 0.000002] testvm1.both.org kernel:clocksource:kvm-clock:mask:0xffffffffffffffff max_cycles:0x1cd42e4dffb, max_idle_ns:881 5905914>
[ 0.000005] testvm1.both.org kernel:tsc:Procesador de 2807,988 MHz detectado
[ 0.001157] testvm1.both.org kernel:e820:actualización [mem 0x00000000-0x00000fff] utilizable ==> reservado
[ 0.001159] kernel testvm1.both.org:e820:eliminar [mem 0x000a0000-0x000fffff] usable
[ 0.001162] kernel testvm1.both.org:last_pfn =0x24ec00 max_arch_pfn =0x400000000
[ 0.001173] kernel testvm1.both.org:rangos variables de MTRR deshabilitados:
[ 0.001173] kernel testvm1.both.org:deshabilitado
[ 0.001174] testvm1.both.org kernel:x86/PAT:MTRR deshabilitados, omitiendo la inicialización de PAT también.
[ 0.001176] testvm1.both.org kernel:CPU MTRR en blanco - sistema virtualizado.
[ 0.001179] testvm1.both.org kernel:x86/PAT:Configuración [0-7]:WB WT UC- UC WB WT UC- UC
[ 0.001182] testvm1.both.org kernel:last_pfn =0xdfff0 max_arch_pfn =0x400000000
[ 0.001238] prueba kernel vm1.both.org:se encontró la tabla SMP MP en [mem 0x0009fff0-0x0009ffff]
[ 0.081068] kernel testvm1.both.org:RAMDISK:[mem 0x34194000-0x360c1fff]
[ 0.081088] testvm1. kernel de both.org:ACPI:Verificación de suma de verificación de tabla temprana deshabilitada
[ 34.037575] kernel de testvm1.both.org:16:43:32.734466 main 6.1.10_Fedora r138449 iniciado. Nivel detallado =0
[ 34.042209] testvm1.both.org kernel:16:43:32.739032 principal vbglR3GuestCtrlDetectPeekGetCancelSupport:compatible (#1)
[ 55.746944] testvm1.both.org kernel:e1000:enp0s3 NIC Link is Up 1000 Mbps Full Duplex, control de flujo:RX
[ 55.747738] testvm1.both.org kernel:IPv6:ADDRCONF(NETDEV_CHANGE):enp0s3:el enlace está listo
líneas 624 -681/681 (FIN)
El diarioctl El comando tiene muchas opciones, incluido el -o (salida) con varias subopciones que le permiten seleccionar un formato de hora y fecha que cumpla con diferentes conjuntos de requisitos. He enumerado la mayoría de ellos a continuación, junto con una breve descripción que amplié o modifiqué del journalctl página de manual Tenga en cuenta que la principal diferencia entre la mayoría de estos es el formato de la fecha y la hora, y la otra información sigue siendo la misma.
formatos de hora y fecha journalctl
- breve: Este es el formato predeterminado y genera una salida que se asemeja más al formato de los archivos syslog clásicos, mostrando una línea por entrada de diario. Esta opción muestra los metadatos del diario, incluido el tiempo monótono desde el arranque, el nombre de host completo y el nombre de la unidad, como el kernel, DHCP, etc.
20 de julio 08:43:01 testvm1.both Kernel .org:Entradas de tabla hash de caché de inodo:1048576 (orden:11, 8388608 bytes, lineal) - corto-completo: Este formato es muy similar al predeterminado, pero muestra marcas de tiempo en el formato
--since=y--hasta=opciones aceptan. A diferencia de la información de marca de tiempo que se muestra en el modo de salida breve, este modo incluye información sobre el día de la semana, el año y la zona horaria en la salida y es independiente de la configuración regional.Mon 2020-06-08 07:47:20 EDT testvm1.both.org kernel:x86/fpu:Compatibilidad con la función XSAVE 0x004:'Registros AVX' - ISO corto: El formato iso corto es muy similar al predeterminado, pero muestra marcas de tiempo de reloj de pared ISO 8601.
2020-06-08T07:47:20-0400 testvm1.both.org kernel:kvm-clock :Usando msrs 4b564d01 y 4b564d00 - corto-iso-preciso:
2020-06-08T07:47:20.223738-0400 kernel testvm1.both.org:arranque del kernel paravirtualizado en KVM - corto-monótono:
[ 2.091107] testvm1.both.org kernel:ata1.00:ATA-6:VBOX HARDDISK, 1.0, max UDMA/ 133 - corto-preciso: Este formato también es similar al predeterminado, pero muestra las marcas de tiempo de syslog clásicas con una precisión de microsegundos. 0x000000000009ffff] reservado
- Unix abreviado: Como el predeterminado, pero muestra los segundos transcurridos desde el 1 de enero de 1970, UTC en lugar de las marcas de tiempo del reloj de pared ("hora Unix"). La hora se muestra con una precisión de microsegundos.
1591616840.232165 testvm1.both.org kernel:tcp_listen_portaddr_hash entradas de la tabla hash:8192 - gato: Genera una salida muy concisa que solo muestra el mensaje de cada entrada del diario sin metadatos, ni siquiera una marca de tiempo.
ohci-pci 0000:00:06.0:irq 22, io mem 0xf0804000 - detallado: Este formato muestra la estructura de datos completa para todos los elementos de entrada con todos los campos. Esta es la opción de formato que es más diferente de todas las demás.
Mon 2020-06-08 07:47:20.222969 EDT [s=d52ddc9f3e8f434b9b9411be2ea50b1e;i=1;b=dcb6dcc0658e4a8d8c781c21a2c6360d7f;m=242d7f;m=242d7f t=5a7912c6148f9;x=8f>
_SOURCE_MONOTONIC_TIMESTAMP=0
_TRANSPORT=kernel
PRIORITY=5
SYSLOG_FACILITY=0
SYSLOG_IDENTIFIER=kernel
MESSAGE=Linux versión 5.6.6-300.fc32.x86_64 ([email protected]) (gcc versión 10.0.1 20200328 (Red Hat 10.0.1-0>
_BOOT_ID=dcb6dcc0658e4a8d8c781c21a2c6360d _=ID MACHINE 3bccd1140fca488187f8a1439c832f07
_HOSTNAME=testvm1.both.org
Otras opciones, disponibles con -o opción, permite exportar los datos en varios formatos, como binario o JSON. También encuentro el -x opción iluminante porque puede mostrar mensajes explicativos adicionales para algunas entradas de diario. Si prueba esta opción, tenga en cuenta que puede aumentar considerablemente el flujo de datos de salida. Por ejemplo, la información adicional para una entrada como:
[ 4.503737] testvm1.both.org systemd[1]:Inicio de comprobación del sistema de archivos en /dev/mapper/VG01-root...
[ 4.691555] testvm1.both.org systemd-fsck[548] :raíz:limpio, 1813/327680 archivos, 48555/1310720 bloques
[ 4.933065] testvm1.both.org systemd[1]:Comprobación del sistema de archivos finalizada en /dev/mapper/VG01-root.
se expande a esto:
[ 4.503737] testvm1.both.org systemd[1]:Iniciando la verificación del sistema de archivos en /dev/mapper/VG01-root...
-- Asunto:Un trabajo de inicio para la unidad systemd-fsck-root .service ha comenzado a ejecutarse
-- Definido por:systemd
-- Soporte:https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Se ha iniciado la ejecución de un trabajo de inicio para la unidad systemd-fsck-root.service.
--
-- El identificador del trabajo es 36.
[ 4.691555] testvm1.both.org systemd -fsck[548]:raíz:limpio, 1813/327680 archivos, 48555/1310720 bloques
[ 4.933065] testvm1.both.org systemd[1]:Comprobación del sistema de archivos finalizada en /dev/mapper/VG01-root.
-- Asunto:Un trabajo de inicio para la unidad systemd-fsck-root.service ha finalizado correctamente
-- Definido por:systemd
-- Soporte:https://lists.freedesktop. org/mailman/listinfo/systemd-devel
--
-- Un trabajo de inicio para la unidad systemd-fsck-root.service ha finalizado correctamente.
--
-- El el identificador de trabajo es 36
Hay algo de información nueva aquí, pero creo que el principal beneficio es que la información está contextualizada para aclarar los breves mensajes originales hasta cierto punto.
Restringiendo la búsqueda
La mayoría de las veces, no es necesario ni deseable enumerar todas las entradas del diario y buscarlas manualmente. A veces busco entradas relacionadas con un servicio específico y otras veces busco entradas que ocurrieron en momentos específicos. El diarioctl El comando proporciona potentes opciones que le permiten ver solo los datos que le interesa encontrar.
Comience con --list-boots opción, que enumera todos los arranques durante el período de tiempo en que existen entradas de diario. Tenga en cuenta que el journalctl.conf El archivo puede especificar que las entradas del diario se descarten después de que alcancen una cierta antigüedad o después de que el espacio del dispositivo de almacenamiento (HDD/SSD) ocupado por los diarios alcance una cantidad máxima especificada:
[root@testvm1 ~]# journalctl --list-boots
-10 dcb6dcc0658e4a8d8c781c21a2c6360d Lun 2020-06-08 07:47:20 EDT—Lun 2020-06-08 07:53:05 EDT
-9 7d61951a85f445c5946774aaae8bc2a4 Vie 2020-07-03 15:50:06 EDT—Vie 2020-07-03 18:21:23 EDT
-8 1b3a847577e544b4a2679fe576b62206-08 EDT 1—07-203 Vie 202 Vie 2020-07-03 22:10:54 EDT
-7 5fef01a3568743af99118107ca6f61ae Vie 2020-07-03 22:18:41 EDT—Sáb 2020-07-04 06:50:19 EDT
-6 6E944F99EBD9405984090F829A927FA4 SAT 2020-07-04 07:33:25 EDT-SAT 2020-07-04 07:58:59 EDT
-5 EC8B0C81CA4744B1BAD071BDEF432959 SAT 2020-07-04 08:12:06 EDT-SAT 2020-07 -04 09:12:47 EDT
-4 cb173ec716824e21b87ccf6cb43a9a99 Sábado 04-07-2020 10:19:53 EDT—Sábado 2020-07-04 11:31:03 EDT
-3 4fe354a8931944096203 Sábado-3a 04-07 07:59:58 EDT—Dom 2020-07-05 09:39:30 EDT
-2 06fb81f1b29e4f68af9860844668446c Lun 2020-07-06 06:27:05 EDT—Lun 2020-07-13 08:50:06 EDT
-1 33dbf8e6b9de4113a591c4f487d0ac37 lun 2020-07-13 04:50:33 EDT— Jue 2020-07-16 13:49:32 EDT
0 75c9b70913934748b5396b3b172bee50 Lun 2020-07-20 08:43:01 EDT—Vie 2020-07-24 12:44:06 EDT
El ID de inicio más reciente aparece en la parte inferior; es el número hexadecimal aleatorio largo. Puede usar estos datos para ver los diarios de un arranque específico. Esto se puede especificar usando el número de compensación de arranque en la columna más a la izquierda o el UUID en la segunda columna. Este comando muestra el diario de la instancia de arranque con el desplazamiento de -2 —el segundo arranque anterior al actual:
[root@testvm1 ~]# journalctl -b -2
-- Los registros comienzan el lunes 2020-06-08 07:47:20 EDT, finalizan el viernes 2020-07-24 12:44:06 EDT. --
6 de julio 06:27:05 kernel testvm1.both.org:Linux versión 5.7.6-201.fc32.x86_64 ([email protected]) (gcc versión 10.1>
Jul 06 06:27:05 testvm1.both.org kernel:Command line:BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.7.6-201.fc32.x86_64 root=/dev/mapper/VG01-root ro>
Jul 06 06:27:05 testvm1.both.org kernel:x86/fpu:Supporting XSAVE feature 0x001:'x87 floating point registers'
Jul 06 06:27:05 testvm1.both.org kernel:x86/fpu:Supporting XSAVE feature 0x002:'SSE registers'
Or you could use the UUID for the desired boot. The offset numbers change after each boot, but the UUID does not:
[root@testvm1 ~]# journalctl -b 06fb81f1b29e4f68af9860844668446c
The -u option allows you to select specific units to examine. You can use a unit name or a pattern for matching, and you can use this option multiple times to match multiple units or patterns. In this example, I used it in combination with -b to show chronyd journal entries for the current boot:
[root@testvm1 ~]# journalctl -u chronyd -b
-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Sun 2020-07-26 09:10:47 EDT. --
Jul 20 12:43:31 testvm1.both.org systemd[1]:Starting NTP client/server...
Jul 20 12:43:31 testvm1.both.org chronyd[811]:chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCD>
Jul 20 12:43:31 testvm1.both.org chronyd[811]:Frequency -0.021 +/- 0.560 ppm read from /var/lib/chrony/drift
Jul 20 12:43:31 testvm1.both.org chronyd[811]:Using right/UTC timezone to obtain leap second data
Jul 20 12:43:31 testvm1.both.org systemd[1]:Started NTP client/server.
Jul 20 12:44:00 testvm1.both.org chronyd[811]:Selected source 192.168.0.52
Jul 20 12:44:00 testvm1.both.org chronyd[811]:System clock TAI offset set to 37 seconds
Jul 20 12:44:00 testvm1.both.org chronyd[811]:System clock wrong by 1.412227 seconds, adjustment started
Jul 20 12:44:01 testvm1.both.org chronyd[811]:System clock was stepped by 1.412227 seconds
[root@testvm1 ~]#
Suppose you want to look at events that were recorded between two arbitrary times. You can also use -S (--since ) and -U (--until ) to specify the beginning and ending times. The following command displays journal entries starting at 15:36:00 on July 24, 2020, through the current time:
[root@testvm1 ~]# journalctl -S "2020-07-24 15:36:00" And this command displays all journal entries starting at 15:36:00 on July 24, 2020, until 16:00:00 on July 25:
[root@testvm1 ~]# journalctl -S "2020-07-24 15:36:00" -U "2020-07-25 16:00:00"
This command combines -S , -U , and -u to give journal entries for the NetworkManager service unit starting at 15:36:00 on July 24, 2020, until 16:00:00 on July 25:
[root@testvm1 ~]# journalctl -S "2020-07-24 15:36:00" -U "2020-07-25 16:00:00" -u NetworkManager
Some syslog facilities, such as cron, auth, mail, daemon, user, and more, can be viewed with the --facility opción. You can use --facility=help to list the available facilities. In this example, the mail facility is not the Sendmail service that would be used for an email service, but the local client used by Linux to send email to root as event notifications. Sendmail actually has two parts, the server, which (for Fedora and related distributions) is not installed by default, and the client, which is always installed so that it can be used to deliver system emails to local recipients, especially root:
[root@testvm1 ~]# journalctl --facility=mail
The journalctl man page lists all the options that can be used to narrow searches. The table below summarizes some of the options I use most frequently. Most of these options can be used in various combinations to further narrow a search. Refer to my previous article Analyzing systemd calendar and timespans for details on creating and testing timestamps, as well as important tips like using quotes around timestamps.
Options to narrow searches of the journal
| Option | Description |
|---|---|
--list-boots | This displays a list of boots. The information can be used to show journal entries only for a particular boot. |
-b [offset|boot ID] | This specifies which boot to display information for. It includes all journal entries from that boot through shutdown or reboot. |
--facility=[facility name] | This specifies the facility names as they're known to syslog. Use --facility=help to list the valid facility names. |
-k , --dmesg | These display only kernel messages and are equivalent to using the dmesg command. |
-S , --since [timestamp] | These show all journal entries since (after) the specified time. They can be used with --until to display an arbitrary range of time. Fuzzy times such as "yesterday" and "2 hours ago"—with quotes—are also allowed. |
-u [unit name] | The -u option allows you to select specific units to examine. You can use a unit name or a pattern for matching. This option can be used multiple times to match multiple units or patterns. |
-U , --until [timestamp] | These show all journal entries until (prior to) the specified time. They can be used with --since to display an arbitrary range of time. Fuzzy times such as "yesterday" and "2 hours ago"—with quotes—are also allowed. |
| Option | Description |
-f , --follow | This journalctl option is similar to using the tail -f dominio. It shows the most recent entries in the journal that match whatever other options have been specified and also displays new entries as they occur. This can be useful when watching for events and when testing changes. |
-e , --pager-end | The -e option displays the end of the data stream instead of the beginning. This does not reverse the order of the data stream, rather it causes the pager to jump to the end. |
--file [journal filename] | This names a specific journal file in /var/log/journal/ . |
-r , --reverse | This option reverses the order of the journal entries in the pager so that the newest are at the top rather than the bottom. |
-n , --lines=[X] | This shows the most recent X number of lines from the journal. |
--utc | This displays times in UTC rather than local time. |
-g , --grep=[REGEX] | I like the -g option because it enables me to search for specific patterns in the journal data stream. This is just like piping a text data stream through the grep dominio. This option uses Perl-compatible regular expressions. |
--disk-usage | This option displays the amount of disk storage used by the current and archived journals. It might not be as much as you think. |
--flush | Journal data stored in the virtual filesystem /run/log/journal/ , which is volatile storage, is written to /var/log/journal/ which is persistent storage. This option ensures that all data is flushed to /run/log/journal/ at the time it returns. |
--sync | This writes all unwritten journal entries (still in RAM but not in /run/log/journal ) to the persistent filesystem. All journal entries known to the journaling system at the time the command is entered are moved to persistent storage. |
--vacuum-size= --vacuum-time= --vacuum-files= | These can be used singly or in combination to remove the oldest archived journal files until the specified condition is met. These options only consider archived files, and not active files, so the result might not be exactly what was specified. |