Capitolo 13 di 1681%

Capitolo 13Sessione operativa · 3h

Linux / Kernel / Shell

Processi, Log e Troubleshooting

Osservabilità operativa Linux: leggere , seguire e diagnosticare problemi senza andare a tentoni.

Modalità

FocusOS / Linux

Outputteoria + pratica

Checkpoint 1

Usare ps, top e pgrep per capire cosa sta succedendo nel sistema.

Checkpoint 2

Leggere in modo progressivo con tail e journalctl.

Checkpoint 3

Applicare un flusso di troubleshooting ripetibile.

Glossario del capitolo

Termini da tenere aperti mentre studi

Tocca un termine per aprire il drawer e collegare teoria, comandi e pratica Linux.

Sezione operativa

Visibilità processi: snapshot vs live

ps ti dà una fotografia istantanea, top/htop una vista continua, pgrep ti aiuta a trovare subito il giusto senza rumore inutile. Nessuno di questi comandi è "migliore in assoluto": diventano potenti quando li usi in sequenza.

Il comportamento professionale non è partire da kill: è identificare, osservare, correlare e solo dopo decidere se intervenire.

Da tenere a mente

ps = snapshot.
top = monitor continuo.
pgrep riduce rumore quando cerchi per nome .

terminal

Fotografia rapida processi

$ ps aux | head

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

Usa ps quando vuoi una fotografia veloce da leggere, salvare o condividere in un ticket.

terminal

Trova PID per nome

$ pgrep -a ssh

912 /usr/sbin/sshd -D

Riduce il rumore rispetto a ps | grep e produce direttamente e comando completo.

Sezione operativa

Leggere log senza annegare

utility come tail -f e journalctl permettono di seguire eventi mentre accadono. Il punto però non è leggere tutto: è leggere abbastanza da collegare il sintomo a un evento reale, senza sommergerti di rumore.

Troubleshooting efficace significa raccogliere evidenza prima di agire e lasciare una traccia chiara di ciò che hai osservato.

Da tenere a mente

tail -f segue eventi in tempo reale.
journalctl aiuta su sistemi con systemd.
Prima evidenza, poi azione.

Laboratorio guidato—Workflow di diagnosi: identifica, osserva, intervieni

Scenario realistico: un servizio sembra lento o bloccato. L’obiettivo non è “riavviare e sperare”, ma produrre evidenza prima di cambiare stato al sistema.

Trova processo e PID

terminal

Identify process

$ pgrep -a node

1823 node server.js

Recuperi e comando completo in modo più pulito di un grep generico.

Osserva carico live

terminal

Observe live behavior

$ top

Verifica se CPU/memoria mostrano picchi coerenti con il problema riportato.

Segui log in tempo reale

terminal

Correlate logs

$ tail -f /var/log/syslog

Correla errori o warning al momento in cui il servizio mostra il sintomo.

Controlla gli eventi recenti del servizio se usi systemd

terminal

Inspect journal

$ journalctl -u nginx --since "10 minutes ago"

Su sistemi con systemd, journalctl permette di restringere il contesto e leggere solo l’intervallo temporale utile alla diagnosi.

Termina in modo controllato se necessario

terminal

Controlled stop

$ kill 1823

Invia SIGTERM prima di usare approcci forzati. È la strada più sicura in produzione.

warning:Usa kill -9 solo come ultima risorsa e dopo aver verificato impatto sul servizio.

Sezione operativa

Metodo operativo: sintomo -> evidenza -> azione

Quando qualcosa non funziona, evita il "riavvio riflesso". Parti dal sintomo, raccogli evidenza, formula un'ipotesi, valida con comandi e solo dopo applica un cambiamento.

Questo approccio riduce fix casuali, aiuta i postmortem e rende il troubleshooting trasferibile a un altro membro del team.

Da tenere a mente

No debug cieco: osserva prima di cambiare stato.
Ogni comando deve rispondere a una domanda specifica.
Documentare output chiave accelera i postmortem.

terminal

Salva evidenza prima di agire

$ ps aux > baseline-processes.txt

Quando la situazione è instabile, salvare una baseline prima di intervenire ti permette di confrontare stato prima/dopo e condividere evidenza nel team.

Checkpoint finale

Cosa portarti via

Osservabilità è una competenza, non un comando singolo.
Log e process inspection vanno usati insieme.
Troubleshooting robusto segue un metodo ripetibile.

⟫

Prompt operativo

Fermati e ragiona

Qual è il rischio principale del "kill e poi vediamo"?
Quando preferiresti pgrep rispetto a ps | grep?

Progress Dashboard Quiz

Hai completato 0/0 domande su 16 capitoli con quiz.

Capitoli completati: 0/16

Quiz capitolo

Verifica rapida

1/3

Devi allegare lo stato attuale dei processi a un ticket. Quale strumento parte meglio dal requisito?

Navigazione

Capitolo 13 di 16

Streams, Pipe e Redirection Inode, Link e Metadati del File System