Modulul 8 · 8.3
Monitorizarea serverului dumneavoastră
Modulul 8: Backupuri și monitorizare · Timp de citire: 10 minute
Obiectivul lecției: După această lecție veți putea stabili ce monitorizați pe serverul dumneavoastră (din exterior și din interior), ce praguri au sens și cum vă asigurați că o alertă ajunge cu adevărat la dumneavoastră fără să fiți copleșit de alerte.
Noțiuni cheie: monitorizare din exterior, monitorizare din interior, uptime, verificare http, verificare de port, expirarea certificatului, spațiu pe disc, memorie, load, heartbeat (dead man's switch), prag, canal de alertare, oboseala alertelor, graficele furnizorului
De ce monitorizare?
Fără monitorizare aflați despre probleme de la clienții dumneavoastră sau deloc. Un site care nu funcționează de sâmbătă, un certificat care a expirat, un disc care s-a umplut, un backup care eșuează în tăcere de trei săptămâni: toate sunt lucruri pe care le-ați fi putut observa la timp. Monitorizarea înseamnă că un program verifică permanent și vă avertizează atunci când ceva nu este în regulă.
O monitorizare bună răspunde la două întrebări:
- Funcționează pentru utilizator? Acest lucru îl măsurați din exterior.
- Se va strica ceva în curând? Acest lucru îl măsurați din interior: disc, memorie, actualizări, backupuri.
Din exterior: ce vede utilizatorul
Monitorizarea din exterior rulează pe o altă mașină decât serverul dumneavoastră, de preferință la un alt furnizor. Este logic: dacă serverul dumneavoastră nu funcționează, nu mai poate trimite singur avertismente.
| Verificare | Ce face | De ce |
|---|---|---|
| http(s) | descarcă o pagină în fiecare minut și verifică codul de stare (200) și, eventual, un cuvânt de pe pagină | site-ul funcționează cu adevărat, nu doar serverul |
| port | se conectează, de exemplu, la portul 22 sau 443 | serviciul ascultă și este accesibil |
| ping | trimite un pachet ICMP | serverul este viu (dar nu spune nimic despre site-ul dumneavoastră) |
| certificat | citește certificatul și data de expirare | avertizează cu mult înainte de expirare |
| DNS | interoghează înregistrarea A | numele indică în continuare serverul corect |
Certificatul merită o atenție specială. Certificatele Let's Encrypt au o valabilitate scurtă și sunt reînnoite automat (lecția 7.3), dar dacă reînnoirea eșuează în tăcere, observați acest lucru abia când vizitatorii primesc un avertisment. Din iunie 2025, Let's Encrypt nu mai trimite e-mailuri de reamintire despre certificatele care expiră și recomandă chiar ea monitorizarea. O verificare a certificatului care avertizează când valabilitatea scade sub 14 zile nu este, așadar, un lux.
Un program des folosit pentru a face acest lucru singur este Uptime Kuma, pe care îl instalați într-un container în lecția 9.4. De preferință, nu îl puneți pe același server pe care trebuie să îl monitorizeze sau combinați-l cu o a doua verificare, externă. Există și servicii terțe care fac același lucru; alegeți unul potrivit pentru dumneavoastră și verificați unde are sediul, dacă alertele pot conține date ale clienților dumneavoastră.
Din interior: ce se va strica în curând
Unele probleme se văd din exterior abia când este prea târziu. Pe acestea le măsurați pe serverul însuși:
| Ce | Cum vedeți | Un prag rezonabil |
|---|---|---|
| Spațiu pe disc | df -h | avertisment peste 80%, alarmă peste 90% |
| Inode-uri (numărul de fișiere) | df -i | la fel; un disc poate fi "plin" cu milioane de fișiere mici |
| Memorie | free -h, mesaje "Out of memory" în journalctl -k | fiecare mesaj OOM este un semnal |
| Load | uptime, top | timp îndelungat peste numărul de vCPU-uri |
| Servicii eșuate | systemctl --failed (lecția 6.1) | orice serviciu eșuat |
| Actualizări și repornire | /var/run/reboot-required, apt list --upgradable (lecția 4.2) | actualizare de securitate mai veche de două zile |
| Backupuri | finalul scriptului dumneavoastră de backup (lecția 8.2) | orice rulare eșuată sau care nu a avut loc |
Acest lucru se poate face cu un script simplu și un timer (lecția 6.3) care trimite o alertă la depășirea unui prag sau cu un program de monitorizare care are un agent pe server (exemple open-source cunoscute sunt Netdata și combinația Prometheus cu node_exporter). Începeți cu puțin: discul, serviciile eșuate și backupurile acoperă majoritatea problemelor.
Graficele din panoul furnizorului dumneavoastră (procesor, memorie, rețea, disc, pe o perioadă de la o zi la un an) sunt o completare foarte bună pentru a observa tendințe: dacă discul crește cu câteva procente în fiecare lună, știți când se va umple. La WebOké le găsiți în ecranul VPS-ului; la alți furnizori, în mod similar. De obicei nu trimit alerte, deci nu înlocuiesc monitorizarea.
Heartbeat: alertă atunci când nu se întâmplă nimic
Unele lucruri trebuie monitorizate tocmai după lipsa unui semnal. Backupul din noaptea trecută este cel mai bun exemplu: dacă scriptul nici nu pornește (timer oprit, server oprit, script defect), nu apare nici mesaj de eroare.
Soluția se numește heartbeat sau dead man's switch: sistemul de monitorizare așteaptă în fiecare zi un semnal. La final, și doar dacă totul a reușit, scriptul de backup trimite o mică cerere http către un URL fix și secret al sistemului de monitorizare:
restic backup ... && restic check && curl -fsS -m 10 https://status.example.com/api/push/Xyz123abc?status=up >/dev/nullDacă semnalul nu sosește într-o zi, primiți o alertă. Uptime Kuma are pentru aceasta tipul de monitor Push; există și programe pe care le puteți găzdui singur, precum Healthchecks. Astfel verificați cu o singură linie dacă backupul a rulat cu adevărat.
Alerte care ajung, dar nu prea multe
O alertă pe care nu o citește nimeni nu este monitorizare. Rezolvați trei lucruri:
- Un canal de alertare pe care îl vedeți cu adevărat: o notificare push pe telefon, un canal de chat, SMS. E-mailul este o opțiune, dar doar dacă serverul dumneavoastră poate trimite e-mailuri în mod fiabil, iar e-mailurile sunt ușor de trecut cu vederea. Pentru alertele cele mai importante folosiți două canale.
- Independent de ceea ce monitorizați. Dacă serverul însuși trimite e-mailul despre discul plin, acesta nu va sosi când discul este plin. Monitorizarea din exterior și un heartbeat acoperă această situație.
- Puține, dar justificate. Dacă primiți zilnic zece alerte cu care nu faceți nimic, veți începe să le ignorați, inclusiv pe cea care contează. Acest fenomen se numește oboseala alertelor. Setați pragurile astfel încât o alertă să însemne: trebuie să faceți ceva. Declanșați o alertă abia după câteva verificări eșuate consecutiv (de exemplu de trei ori), astfel încât un singur pachet pierdut să nu vă trezească din somn.
Testați-vă alertele: opriți un serviciu pentru scurt timp și verificați dacă sosește alerta și cât a durat.
Ce nu trebuie să faceți
- Pagini de monitorizare deschise oricui, cu nume și adrese interne. O pagină de stare publică este în regulă, dar afișați doar ce au voie să știe vizitatorii.
- Un cont de administrator al sistemului de monitorizare fără parolă puternică și 2FA. Cine are acces la monitorizarea dumneavoastră poate dezactiva alertele.
- Agenți cu mai multe drepturi decât este necesar. De obicei, un agent de monitorizare nu trebuie să ruleze ca root.
Rezumat
- Monitorizați din exterior dacă totul funcționează (http, port, certificat, DNS), de pe o altă mașină, și din interior dacă ceva se va strica în curând (disc, memorie, servicii, actualizări, backupuri).
- Certificatele merită o verificare proprie: din iunie 2025, Let's Encrypt nu mai trimite e-mailuri de reamintire.
- Un heartbeat semnalează lipsa unui semnal; ideal pentru backupuri și sarcini programate.
- Alegeți un canal de alertare pe care îl vedeți cu adevărat, independent de serverul însuși, și setați pragurile astfel încât fiecare alertă să necesite o acțiune.
- Graficele furnizorului arată tendințe, dar de obicei nu trimit alerte.
Test (quiz)
Exercițiu
Exercițiul O8.3: Lista dumneavoastră de monitorizare. Întocmiți o listă de monitorizare pentru propriul server: ce verificări din exterior (cu ce interval și de unde), ce verificări din interior (cu praguri), ce heartbeat-uri și prin ce canal sosesc alertele. Configurați cel puțin o verificare externă http sau de certificat și un heartbeat (de exemplu pentru backup) și testați alerta oprind un serviciu pentru scurt timp. Notați cât a durat până a sosit alerta.
Exercițiul O8.3: Lista dumneavoastră de monitorizare
Acest exercițiu îl faceți singur; nimeni nu îl verifică. Bifați ce ați făcut și marcați exercițiul ca finalizat.
Verificare din exterior de pe o altă mașină (de preferință la un alt furnizor), la fiecare 1 până la 5 minute, cu câteva reîncercări. Certificat 14 zile, disc 80/90%, systemctl --failed, heartbeat doar la un backup reușit. Notificările care nu cer nicio acțiune: eliminați-le sau creșteți pragul.
Bifele și notițele dumneavoastră rămân doar în acest browser; nu le trimitem nicăieri. Dacă sunteți autentificat, păstrăm în Cursurile mele doar faptul că ați finalizat exercițiul.
Lecturi suplimentare
- Nu mai aveți acces la VPS: ce faceți?
- Let's Encrypt, Expiration Notification Service Has Ended: https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended
- Uptime Kuma (GitHub): https://github.com/louislam/uptime-kuma
