Ricerca nel sito web

Come visualizzare e configurare i log di Linux su Ubuntu, Debian e CentOS


introduzione

Gli amministratori di sistema Linux spesso devono esaminare i file di registro per la risoluzione dei problemi. Questa è una delle prime cose che farebbe un amministratore di sistema.

Linux e le applicazioni in esecuzione su di esso possono generare tutti i diversi tipi di messaggi, che vengono registrati in vari file di registro. Linux utilizza una serie di file di configurazione, directory, programmi, comandi e demoni per creare, archiviare e riciclare questi messaggi di registro. Sapere dove il sistema conserva i suoi file di registro e come utilizzare i relativi comandi può quindi aiutare a risparmiare tempo prezioso durante la risoluzione dei problemi.

In questo tutorial, daremo un'occhiata a diverse parti del meccanismo di registrazione di Linux.

Disclaimer

I comandi in questo tutorial sono stati testati in semplici installazioni vanilla di CentOS 9, Ubuntu 22.10 e Debian 11.

Passaggio 1: verifica della posizione predefinita del file di registro

La posizione predefinita per i file di registro in Linux è /var/log. È possibile visualizzare l'elenco dei file di registro in questa directory con il seguente comando:

  1. ls -l /var/log

Vedrai qualcosa di simile a questo sul tuo sistema CentOS:

Output
[root@centos-9-trim ~]# ls -l /var/log total 49316 drwxr-xr-x. 2 root root 6 Sep 27 19:17 anaconda drwx------. 2 root root 99 Jan 3 08:23 audit -rw-rw----. 1 root utmp 1234560 Jan 3 16:16 btmp -rw-rw----. 1 root utmp 17305344 Jan 1 00:00 btmp-20230101 drwxr-x---. 2 chrony chrony 6 Aug 10 2021 chrony -rw-r--r--. 1 root root 130466 Dec 8 22:12 cloud-init.log -rw-r-----. 1 root adm 10306 Dec 8 22:12 cloud-init-output.log -rw-------. 1 root root 36979 Jan 3 16:03 cron -rw-------. 1 root root 27360 Dec 10 23:15 cron-20221211 -rw-------. 1 root root 94140 Dec 17 23:07 cron-20221218 -rw-------. 1 root root 95126 Dec 24 23:14 cron-20221225 -rw-------. 1 root root 95309 Dec 31 23:04 cron-20230101 …

Passaggio 2: visualizzazione del contenuto del file di registro

Ecco alcuni file di registro comuni che troverai in /var/log:

  • wtmp
  • utmp
  • dmesg
  • messaggi
  • maillog o mail.log
  • spooler
  • auth.log o secure

I file wtmp e utmp tengono traccia degli utenti che accedono e si disconnettono dal sistema. Non puoi leggere direttamente il contenuto di questi file usando i comandi cat nel terminale – ci sono altri comandi specifici per questo e userai alcuni di questi comandi.

Per vedere chi è attualmente connesso al server Linux, usa il comando who. Questo comando ottiene i suoi valori dal file /var/run/utmp (per CentOS e Debian) o /run/utmp (per Ubuntu).

Ecco un esempio da Ubuntu:

Output
root@ubuntu-22:~# who root pts/0 2023-01-03 16:23 (198.211.111.194)

In questo caso particolare, siamo l'unico utente del sistema.

Il comando last ti dice la cronologia degli accessi degli utenti:

Output
root@ubuntu-22:~# last root pts/0 198.211.111.194 Tue Jan 3 16:23 still logged in reboot system boot 5.19.0-23-generi Thu Dec 8 21:48 still running wtmp begins Thu Dec 8 21:48:51 2022

Puoi anche usare il comando last con una barra verticale (|) per aggiungere una ricerca grep per utenti specifici.

Per scoprire quando il sistema è stato riavviato l'ultima volta, puoi eseguire il seguente comando:

  1. last reboot

Il risultato potrebbe apparire così in Debian:

Output
root@debian-11-trim:~# last reboot reboot system boot 5.10.0-11-amd64 Thu Dec 8 21:49 still running wtmp begins Thu Dec 8 21:49:39 2022

Per vedere quando qualcuno ha effettuato l'ultimo accesso al sistema, usa lastlog:

  1. lastlog

Su un server Debian, potresti vedere un output come questo:

Output
root@debian-11-trim:~# lastlog Username Port From Latest root pts/0 162.243.188.66 Tue Jan 3 16:23:03 +0000 2023 daemon **Never logged in** bin **Never logged in** sys **Never logged in** sync **Never logged in** games **Never logged in** man **Never logged in** lp **Never logged in** mail **Never logged in** news **Never logged in** uucp **Never logged in** proxy **Never logged in** www-data **Never logged in** backup **Never logged in** list **Never logged in** irc **Never logged in** gnats **Never logged in** nobody **Never logged in** _apt **Never logged in** messagebus **Never logged in** uuidd **Never logged in** …

Per altri file di registro basati su testo, puoi utilizzare i comandi cat, head o tail per leggere il contenuto.

Nell'esempio seguente, stai cercando di guardare le ultime dieci righe del file /var/log/messages su un server Debian:

  1. sudo tail /var/log/messages

Riceverai un output simile a questo:

Output
root@debian-11-trim:~# tail /var/log/messages Jan 1 00:10:14 debian-11-trim rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="30025" x-info="https://www.rsyslog.com"] rsyslogd was HUPed Jan 3 16:23:01 debian-11-trim DropletAgent[808]: INFO:2023/01/03 16:23:01 ssh_watcher.go:65: [SSH Watcher] Port knocking detected. Jan 3 16:23:01 debian-11-trim DropletAgent[808]: INFO:2023/01/03 16:23:01 do_managed_keys_actioner.go:43: [DO-Managed Keys Actioner] Metadata contains 1 ssh keys and 1 dotty keys Jan 3 16:23:01 debian-11-trim DropletAgent[808]: INFO:2023/01/03 16:23:01 do_managed_keys_actioner.go:49: [DO-Managed Keys Actioner] Attempting to update 1 dotty keys Jan 3 16:23:01 debian-11-trim DropletAgent[808]: INFO:2023/01/03 16:23:01 do_managed_keys_actioner.go:70: [DO-Managed Keys Actioner] Updating 2 keys Jan 3 16:23:01 debian-11-trim DropletAgent[808]: INFO:2023/01/03 16:23:01 do_managed_keys_actioner.go:75: [DO-Managed Keys Actioner] Keys updated

Passaggio 3: utilizzo del demone rsyslog

Al centro del meccanismo di registrazione c'è il demone rsyslog. Questo servizio è responsabile dell'ascolto dei messaggi di log da diverse parti di un sistema Linux e dell'instradamento del messaggio a un file di log appropriato nella directory /var/log. Può anche inoltrare i messaggi di registro a un altro server Linux.

Il file di configurazione rsyslog

Il demone rsyslog riceve le sue informazioni di configurazione dal file rsyslog.conf. Il file si trova nella directory /etc.

Il file rsyslog.conf dice al demone rsyslog dove salvare i suoi messaggi di log. Questa istruzione proviene da una serie di righe in due parti all'interno del file.

Questo file può essere trovato in rsyslog.d/50-default.conf su Ubuntu.

L'istruzione in due parti è composta da un selettore e da un'azione. Le due parti sono separate da uno spazio bianco.

La parte del selettore specifica qual è l'origine e l'importanza del messaggio di registro e la parte dell'azione dice cosa fare con il messaggio.

Il selettore stesso è nuovamente diviso in due parti separate da un punto (.). La prima parte prima del punto è chiamata facility (l'origine del messaggio) e la seconda parte dopo il punto è chiamata priority (la gravità del messaggio).

Insieme, la coppia struttura/priorità e azione dice a rsyslog cosa fare quando viene generato un messaggio di log che corrisponde ai criteri.

Puoi vedere un estratto da un file CentOS /etc/rsyslog.conf con questo comando:

  1. cat /etc/rsyslog.conf

Dovresti vedere qualcosa di simile come output:

Output
# rsyslog configuration file # For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html # or latest version online at http://www.rsyslog.com/doc/rsyslog_conf.html # If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html #### GLOBAL DIRECTIVES #### # Where to place auxiliary files global(workDirectory="/var/lib/rsyslog") # Use default timestamp format module(load="builtin:omfile" Template="RSYSLOG_TraditionalFileFormat") # Include all config files in /etc/rsyslog.d/ include(file="/etc/rsyslog.d/*.conf" mode="optional") #### MODULES #### module(load="imuxsock" # provides support for local system logging (e.g. via logger command) SysSock.Use="off") # Turn off message reception via local log socket; # local messages are retrieved through imjournal now. module(load="imjournal" # provides access to the systemd journal StateFile="imjournal.state") # File to store the position in the journal #module(load="imklog") # reads kernel messages (the same are read from journald) #module(load="immark") # provides --MARK-- message capability # Provides UDP syslog reception # for parameters see http://www.rsyslog.com/doc/imudp.html #module(load="imudp") # needs to be done just once #input(type="imudp" port="514") …

Per capire cosa significa tutto ciò, consideriamo i diversi tipi di funzionalità riconosciute da Linux. Ecco un elenco:

  • auth o authpriv: messaggi provenienti da eventi relativi all'autorizzazione e alla sicurezza
  • kern: qualsiasi messaggio proveniente dal kernel di Linux
  • mail: messaggi generati dal sottosistema di posta
  • cron: messaggi relativi al demone Cron
  • daemon: messaggi provenienti dai demoni
  • notizie: messaggi provenienti dal sottosistema delle notizie di rete
  • lpr: stampa dei messaggi di registro correlati
  • utente: registra i messaggi provenienti dai programmi utente
  • da local0 a local7: riservato per uso locale

Ed ecco un elenco di priorità in ordine crescente:

  • debug: informazioni di debug dai programmi
  • info: semplice messaggio informativo - non è richiesto alcun intervento
  • avviso: condizione che potrebbe richiedere attenzione
  • avvisa: avviso
  • err: errore
  • crit: condizione critica
  • avviso: condizione che richiede un intervento immediato
  • emerg: condizione di emergenza

Quindi ora consideriamo la seguente riga dal file:

Output
… # Log cron stuff cron.* /var/log/cron …

Questo dice semplicemente al demone rsyslog di salvare tutti i messaggi provenienti dal demone cron in un file chiamato /var/log/cron. L'asterisco (*) dopo il punto indica che verranno registrati i messaggi di tutte le priorità. Allo stesso modo, se la struttura fosse specificata come un asterisco, significherebbe tutte le fonti.

Strutture e priorità possono essere correlate in diversi modi.

Nella sua forma predefinita, quando c'è solo una priorità specificata dopo il punto, significa che tutti gli eventi uguali o maggiori di quella priorità verranno intercettati. Quindi la seguente direttiva fa in modo che tutti i messaggi provenienti dal sottosistema di posta con priorità warning o superiore vengano registrati in un file specifico in /var/log:

Output
mail.warn /var/log/mail.warn

Questo registrerà ogni messaggio uguale o maggiore della priorità di avviso, ma lascerà tutto al di sotto di essa. Quindi anche i messaggi con err, crit, alert o emerg verranno registrati in questo file.

L'utilizzo di un segno di uguale (=) dopo il punto causerà la registrazione solo della priorità specificata. Quindi, se volessimo intercettare solo i messaggi informativi provenienti dal sottosistema di posta, la specifica sarebbe simile alla seguente:

Output
mail.=info /var/log/mail.info

Ancora una volta, se volessimo intrappolare tutto dal sottosistema di posta tranne i messaggi informativi, la specifica sarebbe simile alla seguente

Output
mail.!info /var/log/mail.info

O

Output
mail.!=info /var/log/mail.info

Nel primo caso, il file mail.info conterrà tutto con una priorità inferiore a info. Nel secondo caso, il file conterrà tutti i messaggi con priorità sopra info.

Più strutture nella stessa riga possono essere separate da virgole.

Più fonti (facility.priority) nella stessa riga sono separate da un punto e virgola.

Quando un'azione è contrassegnata da un asterisco, significa tutti gli utenti. Questa è una voce nel tuo file CentOS rsyslog.conf che dice esattamente questo:

Output
# Everybody gets emergency messages *.emerg :omusrmsg:*

Prova a vedere cosa dice rsyslog.conf nel tuo sistema Linux. Ecco un estratto da un server Debian per un altro esempio:

Output
# /etc/rsyslog.conf configuration file for rsyslog # # For more information install rsyslog-doc and see # /usr/share/doc/rsyslog-doc/html/configuration/index.html ################# #### MODULES #### ################# module(load="imuxsock") # provides support for local system logging module(load="imklog") # provides kernel logging support #module(load="immark") # provides --MARK-- message capability # provides UDP syslog reception #module(load="imudp") #input(type="imudp" port="514") # provides TCP syslog reception #module(load="imtcp") #input(type="imtcp" port="514") ########################### #### GLOBAL DIRECTIVES #### ########################### # # Use traditional timestamp format. # To enable high precision timestamps, comment out the following line. # $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # # Set the default permissions for all log files. # $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 …

Come puoi vedere, Debian salva tutti i messaggi a livello di sicurezza/autorizzazione in /var/log/auth.log mentre CentOS li salva in /var/log/secure.

Le configurazioni per rsyslog possono provenire anche da altri file personalizzati. Questi file di configurazione personalizzati si trovano solitamente in directory diverse in /etc/rsyslog.d. Il file rsyslog.conf include queste directory utilizzando la direttiva $IncludeConfig.

Ecco come appare in Ubuntu:

Output
… # # Include all config files in /etc/rsyslog.d/ # $IncludeConfig /etc/rsyslog.d/*.conf …

Controlla i contenuti nella directory /etc/rsyslog.d con:

  1. ls -l /etc/rsyslog.d

Vedrai qualcosa di simile a questo nel tuo terminale:

Output
-rw-r--r-- 1 root root 314 Sep 19 2021 20-ufw.conf -rw-r--r-- 1 root root 255 Sep 30 22:07 21-cloudinit.conf -rw-r--r-- 1 root root 1124 Nov 16 2021 50-default.conf

La destinazione di un messaggio di registro non deve necessariamente essere un file di registro; il messaggio può essere inviato alla console di un utente. In questo caso, il campo azione conterrà il nome utente. Se più di un utente deve ricevere il messaggio, i loro nomi utente sono separati da virgole. Se il messaggio deve essere trasmesso a tutti gli utenti, è specificato da un asterisco (*) nel campo dell'azione.

Essendo parte di un sistema operativo di rete, il demone rsyslog non solo può salvare i messaggi di log localmente, ma può anche inoltrarli a un altro server Linux nella rete o fungere da repository per altri sistemi. Il demone ascolta i messaggi di log nella porta UDP 514. L'esempio seguente inoltrerà i messaggi critici del kernel a un server chiamato \texas.

Output
kern.crit @texas

Passaggio 4: creazione e test dei propri messaggi di registro

Quindi ora è il momento per te di creare i tuoi file di registro. Per verificarlo, eseguirai le seguenti operazioni:

  • Aggiungi una specifica del file di registro nel file /etc/rsyslog.conf
  • Riavvia il demone rsyslog
  • Testare la configurazione utilizzando l'utility logger

Nell'esempio seguente, aggiungerai due nuove righe nel file rsyslog.conf del tuo sistema CentOS Linux. Come puoi vedere con il seguente comando, ognuno di loro proviene da una struttura chiamata local4 e ha priorità diverse.

  1. vi /etc/rsyslog.conf

Ecco l'output:

Output
… # New lines added for testing log message generation local4.crit /var/log/local4crit.log local4.=info /var/log/local4info.log

Successivamente, il servizio verrà riavviato in modo che i dati del file di configurazione vengano ricaricati:

  1. /etc/init.d/rsyslog restart

Per generare ora il messaggio di log, l'applicazione logger viene chiamata:

  1. logger -p local4.info " This is a info message from local 4"

Guardando sotto la directory /var/log ora vengono mostrati due nuovi file:

Output
… -rw------- 1 root root 0 Jan 3 11:21 local4crit.log -rw------- 1 root root 72 Jan 3 11:22 local4info.log …

La dimensione di local4info.log è diversa da zero. Quindi, quando lo apri, vedrai che il messaggio è stato registrato:

  1. cat /var/log/local4info.log
Output
Jan 3 11:22:32 TestLinux root: This is a info message from local 4

Passaggio 5: rotazione dei file di registro

Man mano che vengono scritte sempre più informazioni nei file di registro, questi diventano sempre più grandi. Ciò pone ovviamente un potenziale problema di prestazioni. Inoltre, la gestione dei file diventa macchinosa.

Linux utilizza il concetto di rotazione dei file di registro invece di eliminarli o eliminarli. Quando un registro viene ruotato, viene creato un nuovo file di registro e il vecchio file di registro viene rinominato e facoltativamente compresso. Un file di registro può quindi avere più versioni precedenti che rimangono online. Questi file torneranno indietro per un periodo di tempo e rappresenteranno il backlog. Una volta generato un certo numero di backlog, una nuova rotazione del log causerà l'eliminazione del file di log più vecchio.

La rotazione viene avviata tramite l'utility logrotate.

Il file di configurazione logrotate

Come rsyslog, anche logrotate dipende da un file di configurazione e il nome di questo file è logrotate.conf. Si trova sotto /etc.

Ecco cosa vedi nel file logrotate.conf del tuo server Debian:

  1. cat /etc/logrotate.conf
Output
# see "man logrotate" for details # global options do not affect preceding include directives # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create # use date as a suffix of the rotated file #dateext # uncomment this if you want your log files compressed #compress # packages drop log rotation information into this directory include /etc/logrotate.d # system-specific logs may also be configured here.

Per impostazione predefinita, i file di registro devono essere ruotati settimanalmente con quattro backlog che rimangono online alla volta. Quando il programma viene eseguito, verrà generato un nuovo file di registro vuoto e facoltativamente quelli vecchi verranno compressi.

L'unica eccezione è per i file wtmp e btmp. wtmp tiene traccia degli accessi al sistema e btmp tiene traccia dei tentativi di accesso errati. Entrambi questi file di registro devono essere ruotati ogni mese e non viene restituito alcun errore se viene trovato un precedente file wtmp o btmp.

Le configurazioni di rotazione dei log personalizzate sono mantenute nella directory /etc/logrotate.d. Questi sono inclusi anche in logrotate.conf con la direttiva include. L'installazione di Debian mostra il contenuto di questa directory:

  1. ls -l /etc/logrotate.d
Output
total 32 -rw-r--r-- 1 root root 120 Jan 30 2021 alternatives -rw-r--r-- 1 root root 173 Jun 10 2021 apt -rw-r--r-- 1 root root 130 Oct 14 2019 btmp -rw-r--r-- 1 root root 160 Oct 19 2021 chrony -rw-r--r-- 1 root root 112 Jan 30 2021 dpkg -rw-r--r-- 1 root root 374 Feb 17 2021 rsyslog -rw-r--r-- 1 root root 235 Feb 19 2021 unattended-upgrades -rw-r--r-- 1 root root 145 Oct 14 2019 wtmp

Il contenuto di rsyslog mostra come riciclare una serie di file di log:

  1. cat /etc/logrotate.d/rsyslog
Output
/var/log/syslog /var/log/mail.info /var/log/mail.warn /var/log/mail.err /var/log/mail.log /var/log/daemon.log /var/log/kern.log /var/log/auth.log /var/log/user.log /var/log/lpr.log /var/log/cron.log /var/log/debug /var/log/messages { rotate 4 weekly missingok notifempty compress delaycompress sharedscripts postrotate /usr/lib/rsyslog/rsyslog-rotate endscript }

Come puoi vedere, il file messages verrà reinizializzato ogni giorno con quattro giorni di log conservati online. Altri file di registro vengono ruotati ogni settimana.

Vale anche la pena notare la direttiva postrotate. Questo specifica l'azione che si verifica dopo che l'intera rotazione del registro è stata completata.

Passaggio 6: test della rotazione

logrotate può essere eseguito manualmente per riciclare uno o più file. E per fare ciò, specifichi il file di configurazione pertinente come argomento del comando.

Per vedere come funziona, ecco un elenco parziale dei file di registro nella directory /var/log in un server CentOS di prova:

  1. ls -l /var/log
Output
total 49324 … -rw-------. 1 root root 84103 Jan 3 17:20 messages -rw-------. 1 root root 165534 Dec 10 23:12 messages-20221211 -rw-------. 1 root root 254743 Dec 18 00:00 messages-20221218 -rw-------. 1 root root 217810 Dec 25 00:00 messages-20221225 -rw-------. 1 root root 237726 Dec 31 23:45 messages-20230101 drwx------. 2 root root 6 Mar 2 2022 private drwxr-xr-x. 2 root root 6 Feb 24 2022 qemu-ga lrwxrwxrwx. 1 root root 39 Mar 2 2022 README -> ../../usr/share/doc/systemd/README.logs -rw-------. 1 root root 2514753 Jan 3 17:25 secure -rw-------. 1 root root 2281107 Dec 10 23:59 secure-20221211 -rw-------. 1 root root 9402839 Dec 17 23:59 secure-20221218 -rw-------. 1 root root 8208657 Dec 25 00:00 secure-20221225 -rw-------. 1 root root 7081010 Dec 31 23:59 secure-20230101 drwxr-x---. 2 sssd sssd 6 Jan 17 2022 sssd -rw-------. 1 root root 0 Dec 8 22:11 tallylog -rw-rw-r--. 1 root utmp 2688 Jan 3 16:22 wtmp

Il contenuto parziale del file logrotate.conf ha questo aspetto:

  1. cat /etc/logrotate.conf
Output
# see "man logrotate" for details # global options do not affect preceding include directives # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create # use date as a suffix of the rotated file dateext # uncomment this if you want your log files compressed #compress # packages drop log rotation information into this directory include /etc/logrotate.d # system-specific logs may be also be configured here.

Quindi esegui il comando logrotate:

  1. logrotate -fv /etc/logrotate.conf

I messaggi scorrono man mano che vengono generati nuovi file, vengono rilevati errori, ecc. Quando la polvere si deposita, controlli la presenza di nuovi mail, secure o messaggi File:

  1. ls -l /var/log/mail*
Output
-rw------- 1 root root 0 Dec 17 18:34 /var/log/maillog -rw-------. 1 root root 1830 Dec 16 16:35 /var/log/maillog-20131216 -rw------- 1 root root 359 Dec 17 18:25 /var/log/maillog-20131217
  1. ls -l /var/log/messages*
Output
-rw------- 1 root root 148 Dec 17 18:34 /var/log/messages -rw-------. 1 root root 180429 Dec 16 16:35 /var/log/messages-20131216 -rw------- 1 root root 30554 Dec 17 18:25 /var/log/messages-20131217
ls -l /var/log/secure*
-rw-------  1 root root    0 Jan 3 12:34 /var/log/secure
-rw-------. 1 root root 4187 Jan 3 16:41 /var/log/secure-20230103 
-rw-------  1 root root  591 Jan 3 18:28 /var/log/secure-20230103 ```

Come possiamo vedere, tutti e tre i nuovi file di registro sono stati creati. I file maillog e secure sono ancora vuoti, ma il nuovo file messages contiene già alcuni dati.

Conclusione

Speriamo che questo tutorial ti abbia dato alcune idee sulla registrazione di Linux. Puoi provare a esaminare i tuoi sistemi di sviluppo o test per avere un'idea migliore. Una volta acquisita familiarità con la posizione dei file di registro e le relative impostazioni di configurazione, utilizzare tale conoscenza per supportare i sistemi di produzione. Quindi puoi creare alcuni alias per puntare a questi file per risparmiare anche un po 'di tempo di digitazione.