OnLinux.ro

,

Diagnosticarea și monitorizarea unui Linux Server: ghid practic

👁 1 vizualizare

Un server Linux poate părea perfect sănătos până când o aplicație începe să răspundă greu, un filesystem se umple, memoria se termină sau un serviciu nu mai pornește. În astfel de situații, troubleshooting-ul eficient nu înseamnă să rulezi comenzi la întâmplare, ci să urmezi o metodă.

În acest ghid vom construi o metodologie practică pentru diagnosticarea și monitorizarea unui server Ubuntu LTS, Debian, AlmaLinux sau Rocky Linux.

Vom verifica resursele sistemului, procesele, disk-urile, I/O-ul, serviciile systemd, logurile, rețeaua și DNS-ul. La final vom avea și un checklist rapid pe care îl putem folosi atunci când un server „merge greu” și nu știm încă de ce.

1. Începe cu imaginea de ansamblu

Înainte să investighezi un proces sau un serviciu anume, verifică starea generală a sistemului.

uptime
hostnamectl
timedatectl
uname -a

Comanda uptime ne arată trei informații utile: de cât timp rulează serverul, câți utilizatori sunt conectați și load average-ul.

18:45:10 up 36 days,  4:12,  2 users,  load average: 0.31, 0.22, 0.18

Valorile reprezintă încărcarea medie aproximativă pentru ultimele 1, 5 și 15 minute.

Load average-ul nu trebuie interpretat izolat. Un load de 4 poate fi mare pe un server cu două procesoare logice și perfect acceptabil temporar pe unul cu 32.

nproc
lscpu

Primul obiectiv al troubleshooting-ului este să identifici dacă problema este globală sau limitată la un singur serviciu.

2. Verifică CPU-ul și procesele

Cea mai cunoscută unealtă este top:

top

În partea de sus putem vedea load average, utilizarea CPU și memoria. Mai jos sunt procesele active.

Pentru o listă sortată după consumul CPU:

ps aux --sort=-%cpu | head -20

Pentru memoria consumată:

ps aux --sort=-%mem | head -20

Un proces care apare temporar la 100% CPU nu este automat o problemă. Important este contextul: cât durează, câte core-uri există și dacă serviciul respectiv are de făcut efectiv muncă.

htop

Pentru administrare interactivă, htop este foarte comod.

Ubuntu și Debian:

sudo apt install htop

AlmaLinux și Rocky Linux, dacă pachetul este disponibil în repository-urile configurate:

sudo dnf install htop

3. Memoria RAM: free nu înseamnă ceea ce pare

free -h

Pe Linux este normal ca o parte importantă din memoria RAM să fie folosită pentru cache. De aceea câmpul available este deseori mai relevant decât simplul free.

Verifică și swap-ul:

swapon --show
free -h

Faptul că există date în swap nu înseamnă automat că serverul are o problemă. Mai important este dacă sistemul face swap intensiv în mod continuu.

vmstat

vmstat ne permite să urmărim CPU, memorie, procese și activitatea swap într-un singur loc.

vmstat 1

Comanda afișează un nou eșantion în fiecare secundă. Coloanele si și so indică swap-in și swap-out. Valori ridicate și constante pot indica presiune asupra memoriei.

4. Verifică dacă OOM Killer a intervenit

Dacă sistemul rămâne fără memorie, kernelul poate termina procese pentru a recupera RAM. Acesta este mecanismul cunoscut drept OOM Killer.

journalctl -k | grep -iE 'out of memory|oom|killed process'

Sau pentru boot-ul curent:

journalctl -k -b | grep -iE 'oom|killed process'

Dacă găsești astfel de evenimente, investighează procesul terminat, memoria disponibilă și limitele configurate pentru serviciu.

5. Verifică spațiul pe disk

df -h

Un filesystem care ajunge la 100% poate produce simptome aparent fără legătură: servicii care nu mai scriu loguri, baze de date care se opresc sau aplicații care nu mai pot crea fișiere temporare.

Verifică și tipurile de filesystem:

df -Th
lsblk -f
findmnt

Pentru instalarea și alegerea între ext4, XFS și Btrfs vezi ghidul nostru Instalare și configurare Linux Server: ghid și bune practici.

6. Nu uita de inode-uri

Un filesystem poate avea spațiu liber și totuși să nu mai poată crea fișiere dacă toate inode-urile sunt consumate.

df -i

Această situație apare mai ales când există milioane de fișiere foarte mici, cache-uri, sesiuni sau directoare temporare care nu sunt curățate.

7. Găsește ce consumă spațiul

Pentru o privire rapidă asupra directoarelor mari:

sudo du -xhd1 / | sort -h

Pentru /var:

sudo du -xhd1 /var | sort -h

Opțiunea -x împiedică traversarea altor filesystem-uri montate.

Pentru fișiere foarte mari:

sudo find /var -xdev -type f -size +1G -ls

8. Un disk poate avea spațiu liber și totuși să fie lent

Capacitatea și performanța sunt două lucruri diferite. Pentru a analiza I/O-ul putem folosi utilitarele din pachetul sysstat.

Ubuntu și Debian:

sudo apt install sysstat

AlmaLinux și Rocky Linux:

sudo dnf install sysstat

Apoi:

iostat -xz 1

Urmărește latența și gradul de ocupare al dispozitivelor, dar interpretează valorile în contextul tipului de storage: HDD, SSD, NVMe sau storage virtualizat.

Ce proces produce I/O?

pidstat -d 1

Această comandă este utilă când disk-ul este ocupat, dar nu știi ce proces generează activitatea.

9. Verifică serviciile systemd

Pentru serviciile eșuate:

systemctl --failed

Pentru un anumit serviciu:

systemctl status nginx

Detalii despre unit:

systemctl cat nginx

Vezi și ghidul nostru Systemd: cum administrezi serviciile unui server Linux.

10. journalctl este una dintre cele mai importante unelte

Mesajele importante din boot-ul curent:

journalctl -b -p warning

Pentru un serviciu:

journalctl -u nginx

Ultimele 100 de mesaje:

journalctl -u nginx -n 100

Urmărire live:

journalctl -u nginx -f

Pentru boot-ul anterior:

journalctl -b -1

Mai multe exemple găsești în Jurnalul Linux explicat: cum folosești journalctl.

11. Verifică mesajele kernelului

dmesg --level=err,warn

Sau prin journal:

journalctl -k

Aici putem descoperi erori legate de storage, filesystem, drivere, memorie, rețea sau dispozitive hardware.

12. Verifică interfețele și adresele IP

ip addr

Pentru o afișare mai compactă:

ip -br addr

Ruta implicită:

ip route

O configurație de rețea greșită poate face ca serviciul să ruleze perfect local, dar să fie inaccesibil din exterior.

13. Testează conectivitatea pe straturi

Un troubleshooting bun al rețelei începe simplu.

Verifică ruta către Internet:

ip route

Testează conectivitatea IP, dacă destinația permite ICMP:

ping -c 4 1.1.1.1

Testează apoi rezoluția DNS:

getent hosts onlinux.ro

Pentru HTTP/HTTPS:

curl -I https://onlinux.ro

Faptul că un host nu răspunde la ping nu demonstrează că este offline. ICMP poate fi filtrat.

14. Diagnosticarea DNS

Rezoluția DNS poate fi verificată fără să presupunem imediat că problema este la aplicație.

getent hosts example.com

Dacă ai disponibil dig:

dig example.com
dig example.com @1.1.1.1

Pe unele sisteme cu systemd-resolved:

resolvectl status
resolvectl query example.com

Verifică și:

cat /etc/resolv.conf

15. Ce porturi ascultă?

sudo ss -tulpn

Pentru conexiunile TCP stabilite:

ss -tn state established

Pentru un rezumat:

ss -s

Dacă aplicația trebuie să fie accesibilă din exterior, verifică și adresa pe care ascultă. Există o diferență importantă între:

127.0.0.1:8080

0.0.0.0:8080

Primul este accesibil doar local. Al doilea ascultă pe toate interfețele IPv4.

16. Verifică firewall-ul

Pe Ubuntu sau Debian cu UFW:

sudo ufw status verbose

Pe AlmaLinux sau Rocky Linux cu firewalld:

sudo firewall-cmd --list-all

Un serviciu poate asculta corect și totuși să fie inaccesibil deoarece firewall-ul hostului sau firewall-ul providerului blochează traficul.

Pentru hardening vezi Securizarea unui Linux Server după instalare: ghid complet.

17. Află ce proces folosește un port

sudo ss -ltnp | grep ':443'

Alternativ, dacă ai lsof:

sudo lsof -i :443

Acest lucru este util mai ales atunci când un serviciu nu poate porni pentru că portul este deja ocupat.

18. Verifică uptime-ul serviciilor, nu doar al serverului

Un server poate avea uptime de 200 de zile, dar serviciul principal să se fi restartat acum cinci minute.

systemctl status nginx

Pentru momentul activării:

systemctl show nginx \
  -p ActiveEnterTimestamp \
  -p ExecMainStartTimestamp

19. Verifică restarturile și crash-urile

journalctl -u nginx --since "24 hours ago"

Pentru mesaje de tip crash:

journalctl --since today | grep -iE 'segfault|fatal|panic|failed'

Nu interpreta însă fiecare apariție a cuvântului failed ca incident. Logurile trebuie citite în context.

20. Verifică logrotate

Logurile care cresc la nesfârșit pot umple filesystem-ul.

ls -lah /var/log
ls -lah /etc/logrotate.d/

Poți verifica configurația principală:

cat /etc/logrotate.conf

21. Când serverul este lent: metodologia în 5 minute

Dacă primești mesajul „serverul merge greu”, poți începe cu această secvență:

uptime

free -h

df -h

df -i

top

systemctl --failed

sudo ss -tulpn

journalctl -b -p warning --no-pager | tail -100

Aceste comenzi nu rezolvă automat problema, dar oferă rapid o imagine foarte bună asupra sistemului.

22. Ce merită monitorizat permanent?

  • CPU și load average;
  • memorie disponibilă;
  • swap;
  • spațiu pe disk;
  • inode-uri;
  • disk I/O și latență;
  • starea serviciilor;
  • porturile critice;
  • HTTP/HTTPS availability;
  • certificate TLS;
  • backup-uri;
  • erori importante din loguri.

23. Pragurile trebuie să genereze alerte înainte de incident

Nu este ideal să primești alertă abia când filesystem-ul ajunge la 100%.

Ca punct de pornire, poți urmări praguri precum:

Disk usage:
warning   80%
critical  90%

Certificate TLS:
warning   30 zile
critical   7 zile

Backup:
alerta daca ultima copie valida
depaseste intervalul asteptat

Aceste praguri sunt doar exemple. Valorile potrivite depind de workload și de infrastructură.

24. Monitoring nu înseamnă doar grafice frumoase

Un sistem de monitorizare trebuie să răspundă în primul rând la două întrebări:

  1. Există o problemă acum?
  2. Ce s-a schimbat înainte de apariția problemei?

Graficele istorice sunt extrem de utile. Dacă RAM-ul a crescut lent timp de trei zile sau latența disk-ului a început să urce după un deploy, un grafic face acest comportament mult mai ușor de observat.

Pentru infrastructuri mai mari poți folosi soluții precum Prometheus și Grafana, Zabbix sau alte platforme de monitorizare. Instrumentul ales contează mai puțin decât existența alertelor utile și a unei istorii măsurabile.

25. Nu ignora backup-ul în monitoring

Un job de backup care rulează fără erori nu garantează neapărat că datele pot fi restaurate.

Monitorizează cel puțin:

  • momentul ultimului backup;
  • statusul jobului;
  • dimensiunea rezultatului;
  • spațiul disponibil pe destinație;
  • testele periodice de restore.

Pentru sincronizare și copii de date vezi și rsync: backup și sincronizare eficientă în Linux.

Checklist de troubleshooting Linux Server

  1. Verifică uptime și load average.
  2. Verifică numărul de CPU-uri cu nproc.
  3. Verifică procesele cu consum mare de CPU.
  4. Verifică RAM și swap.
  5. Caută evenimente OOM.
  6. Verifică spațiul pe filesystem.
  7. Verifică inode-urile.
  8. Caută directoarele și fișierele mari.
  9. Verifică latența și I/O-ul disk-ului.
  10. Rulează systemctl --failed.
  11. Verifică logurile serviciului afectat.
  12. Verifică mesajele kernelului.
  13. Verifică interfețele și routing-ul.
  14. Testează DNS separat de conectivitatea IP.
  15. Verifică porturile care ascultă.
  16. Verifică firewall-ul.
  17. Identifică procesul care folosește portul.
  18. Caută restarturi sau crash-uri recente.
  19. Verifică logrotate.
  20. Verifică ultima copie de backup.

Concluzie

Diagnosticarea unui Linux Server devine mult mai simplă atunci când urmezi aceeași ordine de fiecare dată: stare generală, CPU, memorie, disk, servicii, loguri și rețea.

Ubuntu LTS, Debian, AlmaLinux și Rocky Linux au diferențe de ecosistem și administrare a pachetelor, dar instrumentele fundamentale de diagnosticare sunt în mare parte aceleași: top, ps, free, vmstat, df, ss, systemctl, journalctl, ip și instrumentele din sysstat.

Un administrator bun nu ghicește cauza unei probleme. Strânge dovezi, elimină ipotezele și modifică sistemul abia după ce înțelege ce se întâmplă.

Dacă pregătești un server nou, citește și ghidul de instalare și configurare Linux Server, urmat de ghidul complet de securizare după instalare.