Analisi iniziale di un server Linux

Capita che qualcuno chieda di dare un’occhiata ad un Linux sconosciuto o di dover analizzare velocemente da remoto i problemi di un server Linux.

Questa breve guida basata sull’ottimo articolo di Brendan D. Gregg elenca i comandi utili per iniziare a farsi un’idea dei possibili problemi.

Questi comandi sono il punto di partenza di un’analisi approfondita e servono per capire dove spendere energia per ulteriori analisi.

Non tutti i comandi descritti vengono installati di default in ogni distribuzione Linux; il consiglio è di provare a lanciarli anche sui server che si amministrano normalmente e di includere i relativi pacchetti nelle proprie installazioni standard perché sono comandi che prima o poi tornano utili, in fondo a questo articolo trovate una tabella con i nomi dei pacchetti che contengono i comandi descritti.

L’ordine di esposizione dei comandi va dai più generici ai più specifici.

date
È il primo comando da dare per capire se il sistema ha l’ora esatta e che fuso orario sta utilizzando. Questo permette di evitare errate interpretazioni dei log e consente di verificare se il problema di alcuni programmi che fanno affidamento all’ora esatta dipende da un’errata impostazione dell’orologio di sistema

uname -a
Occhiata veloce alla versione di Linux che sta girando, al nome dell’host e alla famiglia di processore. Se si desiderano ulteriori informazioni sul processore, si può consultare /proc/cpuinfo

lspci
Giusto per capire l’hardware sottostante. Se il server è virtualizzato qui potrebbe esserci traccia dei dispositivi virtualizzati.

ps ax
Rapida scorsa ai processi, senza soffermarsi troppo sui dettagli, ma per avere un’idea di cosa stia girando lì dentro. Con questo comando si possono beccare i problemi semplici da risolvere, ma non bisogna lasciarsi trarre troppo in inganno.

df -h
Quanto spazio libero abbiamo? Alcuni problemi derivano da file system (quasi) pieni.

mount
Come sono montati i file system e come sono formattati. Qui si vede anche se ci sono file system remoti o non standard. Utile per sapere come muoversi.

repquota -a
Giusto per verificare se siano stati attivati i limiti di allocazione disco per utente/gruppo. Se il comando non restituisce nulla, significa che quota non è attivo.

w
Qui entriamo più nell’analisi vera e propria:

 09:27:28 up 12 days, 16:29,  3 users,  load average: 0.25, 0.43, 0.42
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/7    host99-999-stati 12Jan16  0.00s  0.15s  0.00s w
root     pts/6    host99-999-stati 13Jan16  3days  0.16s  0.16s -/bin/bash
root     pts/8    host99-999-stati 13Jan16  4days  0.01s  0.01s -/bin/bash

Con un solo comando abbiamo l’output di uptime sulla prima riga e l’elenco degli utenti. La prima riga ci informa sia quando è avvenuto l’ultimo boot sia qual è il carico di sistema medio degli ultimi 1, 5 e 15 minuti. L’andamento del carico nei tre lassi di tempo indica anche se il sistema si sta caricando o scaricando di lavoro. Da non sottovalutare l’indicazione degli utenti interattivi collegati.

dmesg
Un’occhiata a cosa ha a avuto da dire il kernel ultimamente. Qui si trovano informazioni interessanti, come ad esempio

[236619.769450] r8169 0000:07:00.0 eth0: link down
[236628.323234] r8169 0000:07:00.0 eth0: link up
[236641.671771] r8169 0000:07:00.0 eth0: link down
[236664.791777] r8169 0000:07:00.0 eth0: link up

Tra parentesi quadre il numero di secondi dal boot a cui si riferisce l’evento, quindi sapendo l’uptime possiamo anche risalire al momento degli eventi. In particolare vediamo che questo server ha perso il link di rete per 9 secondi e dopo 13 secondi l’ha perso di nuovo per 23 secondi.

Qui troviamo anche eventi di Out of Memory con possibile invocazione di oom killer o eventi segnalati dallo stack TCP/IP. Non sempre si tratta di eventi critici, alcune volte sono messaggi dei driver come questo del controller RAID:

[547332.262768] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0029): Verify started:unit=0.
[561529.934361] 3w-9xxx: scsi0: AEN: INFO (0x04:0x002B): Verify completed:unit=0.

free -h
Questo comando offre una visione generale dell’utilizzo della memoria:

          total     used     free    shared  buff/cache   available
Mem:        11G     1.9G     331M      625M        9.4G        8.8G
Swap:      6.0G       0B     6.0G

È normale che un Linux abbia poca memoria libera, perché free memory is bad memory. Il valore available indica la memoria disponibile per avviare nuovi programmi senza che intervenga lo swap. È normale che ci sia un minimo di swap utilizzato, specialmente se non si è toccata la swappiness del kernel (la strategia di swapping è tema dibattutissimo e lo diventerà ancora di più con gli SSD).

top
Qualche decina di secondi per vedere quali sono i task che girano e farsi un’idea di quali siano i processi che usano maggiorente le risorse. Lanciare abbastanza presto questo comando permette di proseguire l’analisi avendo più chiara l’immagine delle attività principali del server. In particolare qui vengono riassunti dei valori che verranno analizzati con i comandi successivi. Ovviamente nulla vieta di tornare su questo comando oppure di tenere una finestra aperta con top in esecuzione mentre si compiono altre analisi.

vmstat 1
Passiamo ora ad analizzare in dettaglio l’utilizzo specifico delle risorse del sistema e iniziamo dalle statistiche della memoria:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache    si   so    bi    bo   in   cs us sy  id wa st
 1  0      0 366976   1904 9851096    0    0    55    44    1    5  3  1  95  1  0
 0  0      0 367004   1904 9851128    0    0     0     0  566 1126  0  0 100  0  0
 0  0      0 367004   1904 9851128    0    0     0    12  503 1044  0  0 100  0  0
 1  0      0 366524   1904 9851128    0    0     0     0  593  940  1  0  99  0  0

Ci interessano queste colonne:

• r – il numero dei processi che stanno attendendo di essere eseguiti; come regola grossolana, se questo numero supera costantemente il numero delle CPU il sistema è intasato;
• memory – questo gruppo di colonne riporta gli stessi valori del comando free;
• swap – traffico da/per l’area di swap, se ce n’è molto la RAM non è sufficiente oppure i task sono troppo avidi di memoria;
• io – operazioni di I/O sui block device, dettagli in un altro comando;
• us, sy – user e system time, questo è l’indicatore che il sistema sta facendo qualcosa o per la parte utente o per il kernel;
• wa – tempo utilizzato per attendere le operazioni di I/O; se è alto non è un bel segnale. Prima del kernel 2.5.41 questo valore era incluso in id.

mpstat -P ALL 1
Questo comando ha senso solamente in sistemi con più CPU/core o con l’hyperthreading attivo. Qui possiamo vedere se una della CPU logiche (siano esse CPU vere, core o altro) è più carica della altre a causa di un thread che occupa troppe risorse.

pidstat 1
Mostra di fatto gli aggiornamenti all’elenco visualizzato da top, ma senza formattazione. Rende in una maniera visualmente differente l’idea di cosa sta girando sul sistema e quanto sta occupando.

iostat -xz 1
Mostra l’attività dei block device (i dischi):

Device: rrqm/s  wrqm/s    r/s    w/s  rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda       0.00    0.00   0.00  77.00   0.00  1698.50    44.12     0.83   44.68    0.00   44.68   6.61  50.90

Le prime sei colonne indicano le letture/scritture al secondo; questo è l’indicatore dell’attività di disco, non esistono regole generiche, ma bisogna valutare se le letture/scritture visualizzate sono coerenti con quello che si presume essere la normale attività del sistema.

Le tre colonne wait sono molto importanti per l’individuazione di possibili colli di bottiglia sull’I/O perché indicano quanti millisecondi di attesa sono necessari per portare a termine un’operazione.

L’ultima colonna %util indica la percentuale di utilizzo del dispositivo. Benché le soglie di attenzione varino notevolmente al variare dell’hardware sottostante, di sicuro una percentuale costantemente prossima al 100% è indice di problemi di saturazione del canale di I/O.

sar -n DEV 1
Da ultimo un’occhiata alla rete:

12:34:56 AM  IFACE  rxpck/s  txpck/s  rxkB/s   txkB/s  rxcmp/s  txcmp/s  rxmcst/s
12:34:56 AM   eth0    37.00    46.00    2.80    44.63     0.00     0.00      0.00
12:34:56 AM     lo    10.00    10.00    1.26     1.26     0.00     0.00      0.00

Questo comando mostra il traffico delle interfacce di rete, indipendentemente dal protocollo.

L’analisi dei dati presentati da questo comando dipende anche qui dal tipo di hardware sottostante e dai ruoli del server. Questo è uno dei livelli più bassi nello stack ISO/OSI a cui si può arrivare con delle utility di Linux.

Il comando sar -n supporta altri parametri: EDEV, NFS, NFSD, SOCK, IP, EIP, ICMP, EICMP, TCP, ETCP, UDP, SOCK6, IP6, EIP6, ICMP6, EICMP6, UDP6; quelli che iniziano per E visualizzano le statistiche degli errori. Questi parametri possono essere usati in maniera combinata per analizzare problemi specifici, ad esempio per analizzare il traffico e i problemi di IPv6 si può utilizzare il comando sar -n IP6,EIP6 1 oppure per vedere lo stato delle connessioni TCP il comando da utilizzare è sar -n TCP,ETCP 1 in cui la colonna retrans/s mostra le ritrasmissioni dei pacchetti dovute a problemi di connettività o a sovraccarico del sistema.

I pacchetti di CentOS e Debian/Ubuntu che includono le utility citate sono:

Questi comandi costituiscono solamente la prima fase se si vuole compiere un’analisi profonda di un sistema; chi è interessato può leggere questo articolo.