Sesiunea 10 din 12
Monitorizare și Observabilitate în Azure
Cum știi că totul funcționează corect?
Cum știi că tot ce ai construit funcționează corect? Astăzi descoperim monitorizarea și observabilitatea — straturile care transformă o colecție de servicii într-un sistem pe care îl înțelegi și îl controlezi.
Fundamente
De ce monitorizarea nu este opțională
Imaginați-vă că lansați o aplicație web pentru un client important. Totul merge perfect în ziua lansării. O săptămână merge bine. Și apoi, într-o joi seara, utilizatorii încep să primească erori. Pagina se încarcă în zece secunde în loc de una. Clienții trimit emailuri furioase.
Ce găsiți când vă conectați în panică
CPU-ul la 100% de două ore
Serverul nu mai poate procesa cereri noi. Aplicațiile răspund lent sau deloc.
Mii de conexiuni deschise la DB
Baza de date este suprasaturată, un proces a luat-o razna.
Utilizatorii suferă de două ore
Nimeni nu v-a notificat. Ați aflat de la clienți furioși, nu de la sistem.
Nicio urmă în log-uri
Fără monitorizare, nu știți nici ce s-a întâmplat, nici de ce.
Regula nescrisă a industriei: Dacă nu monitorizezi, nu operezi. Orice sistem în producție fără monitorizare este un sistem pe care nu îl înțelegi. Monitorizarea nu previne întotdeauna problema — dar vă anunță în momentul în care apare.
Ce este monitorizarea? Modelul mental complet
Monitorizarea are trei componente principale, fiecare cu un scop distinct. Împreună formează un sistem complet de observabilitate.
Metrici — Semnele vitale
Valorile numerice măsurate în timp real: utilizare CPU, memorie, rețea, disc. Exact cum medicul măsoară pulsul și tensiunea — te spun ce se întâmplă acum cu sistemul.
Log-uri — Istoricul medical
Înregistrările complete ale tot ce s-a întâmplat: cine s-a conectat, ce operațiuni au rulat, ce erori au apărut. Log-urile îți spun de ce se întâmplă ceea ce observi.
Alerte — Alarma automată
Echivalentul dispozitivului medical care bipăie când pulsul depășește pragul critic. Nu trebuie să stai constant cu ochii pe monitor — sistemul te anunță automat.
Metricile îți arată CE se întâmplă. Log-urile îți arată DE CE se întâmplă. Alertele te anunță că trebuie să acționezi.
Azure Monitor
Centrul de comandă
În Azure, toate capabilitățile de monitorizare sunt centralizate în Azure Monitor — platforma unificată care colectează, stochează, analizează și acționează pe baza datelor din toate resursele voastre.
Gândiți-vă la Azure Monitor ca la centrul de comandă al unui aeroport. Controlorii de trafic aerian nu se urcă în fiecare avion să vadă cum merge. Ei au ecrane care agregă informații de la sute de avioane simultan.
Metrics
Date numerice în timp real despre comportamentul resurselor: CPU, memorie, rețea, disc.
Activity Log
Jurnalul operațiunilor: cine a creat, modificat sau șters resurse în subscripția Azure.
Log Analytics
Motorul de căutare și analiză pentru volume mari de log-uri, cu query-uri KQL.
Alerts
Sistemul de notificare automat: email, SMS, webhook sau declanșarea de acțiuni.
Application Insights
Monitorizarea dedicată aplicațiilor: performanță end-to-end, erori, comportament utilizatori.
Creăm resursele pentru exercițiu
Înainte să explorăm monitorizarea, avem nevoie de ceva de monitorizat.
Creați Resource Group
Numiți-l rg-s10-[prenumele vostru]. Selectați regiunea cea mai apropiată.
Creați o mașină virtuală
Windows sau Linux — cel mai mic size din seria B (B1s sau B2s).
Configurați accesul
NSG cu RDP (Windows) sau SSH (Linux), sursa: My IP Address.
Așteptați deployul
Cât timp rulează deploymentul, continuăm cu contextul teoretic.
Seria B este cea mai economică. Nu uitați să ștergeți resursele la finalul sesiunii.
Metrici
Semnele vitale ale serverului tău
Când VM-ul este gata: navigați la el în Azure Portal → Monitoring → Metrics. Adăugați pe rând: Percentage CPU, Network In, și Disk Read Bytes.
Cum interpretăm CPU Percentage
0–5% → Server inactiv
Poate fi normal (serverul așteaptă cereri) sau o problemă (aplicația a căzut și nu mai procesează nimic).
50–70% → Încărcare normală
Serverul procesează activ. Semnul unui sistem sănătos sub trafic real.
100% susținut → Problemă critică
Serverul nu mai poate procesa cereri noi. Aplicațiile răspund lent sau deloc.
Întrebarea capcană: Dacă CPU-ul este constant la 2% — este bine sau rău? Dacă plătiți pentru 4 vCPU și folosiți 2% → risipă de bani, dimensionare greșită. O metrică nu este bună sau rea în mod absolut. Este bună sau rea în contextul a ceea ce ar trebui să facă sistemul.
Granularitate temporală și Time Ranges
Un aspect esențial pe care îl veți folosi constant în practică.
Investigarea unui incident
Zoom pe intervalul afectat (ex. 2:00–4:00 AM) cu granularitate de 1 minut. Vedeți exact momentul în care a explodat CPU-ul.
Analiza tendințelor
Intervale mari (săptămâni, luni) cu granularitate de ore sau zile. Identificați creșterea treptată a utilizării discului.
Decizia de scaling
Comparați perioadele de vârf vs. normale. Dacă peak-ul zilnic atinge constant 80% CPU, e timpul pentru scale up/out.
Granularitate mare (1 minut) → diagnostic rapid. Granularitate mică (1 oră/zi) → planificare și tendințe pe termen lung.
Log-uri
Camera de supraveghere a infrastructurii
Navigați la VM → Monitoring → Activity Log. Veți vedea o listă cronologică a tuturor operațiunilor: când a fost creată resursa, cine a creat-o, dacă cineva a modificat configurația sau regulile de firewall.
Scenariul 1: Securitate
Dacă cineva a șters accidental o resursă importantă, Activity Log-ul spune exact cine a făcut-o și când. Dacă o configurație a cauzat o problemă, Log-ul arată ce s-a schimbat. Prima linie de răspuns în orice investigație de securitate.
Scenariul 2: Compliance și Auditare
Organizațiile din domenii financiar, medical și guvernamental trebuie să demonstreze: cine a avut acces, ce acțiuni a efectuat, când au avut loc modificările, cine a aprobat schimbările critice.
Log Analytics și Kusto Query Language (KQL)
Activity Log-ul arată operațiunile la nivelul resursei. Dar pentru a vedea ce se întâmplă în interiorul ei — log-urile OS-ului, ale aplicațiilor, ale proceselor interne — aveți nevoie de Log Analytics.
Log Analytics colectează, stochează și permite căutarea în volume mari de log-uri din multiple surse. Pentru a trimite log-urile unui VM, instalați Azure Monitor Agent pe mașina respectivă.
KQL (Kusto Query Language) este un limbaj declarativ similar cu SQL, optimizat pentru analiză de log-uri în timp real pe volume mari. Exemplu: Event | where EventLevelName == "Error" | where TimeGenerated > ago(24h) | order by TimeGenerated desc — toate erorile din ultimele 24 de ore.
Alerte — Lab
Creăm prima alertă — pas cu pas
O alertă în Azure Monitor este o regulă care spune: dacă o metrică depășește un prag, notifică-mă.
Structura unei alerte
Condiția
Ce metrică monitorizăm, ce prag o declanșează, pe ce interval. Ex: CPU > 5% timp de 5 minute.
Grupul de acțiuni
Ce se întâmplă când condiția este îndeplinită: email, SMS, webhook, Logic App sau Azure Function.
Regula de alertă
Combinația condiție + acțiune, cu nume, descriere și severitate (0=Critic → 4=Verbose).
Pași în Azure Portal
VM → Monitoring → Alerts → Create → Alert rule
Navigați la secțiunea de monitorizare a VM-ului.
Condition: Percentage CPU > 5%
Granularitate 1 min, evaluare 5 min. Folosim 5% ca să vedem alerta declanșându-se în timp real.
Actions: Create action group → Email
Creați un action group cu notificare pe adresa voastră de email.
Details: Alert-CPU-High-[prenume]
Severity: 2 — Warning. Dați Create. Alerta este activă imediat.
În producție reală veți configura praguri realiste: CPU > 80% pentru 10 min, Disc < 10% spațiu liber, HTTP 5xx > 1% din cereri, Latență SQL > 1 secundă.
Metrici per Serviciu
Monitorizare la Web App și SQL Database
Un principiu important: în Azure, monitorizarea este integrată în fiecare serviciu din momentul creării. Fiecare resursă expune automat un set de metrici relevante pentru tipul ei.
Azure Web App — Metrici critice
Requests
Numărul de cereri HTTP pe secundă. Indicatorul principal al traficului.
Response Time
Dacă normalul este 200ms și brusc ajunge la 2s — ceva s-a schimbat.
HTTP 5xx
Erori de server. O creștere bruscă înseamnă problemă internă în aplicație.
HTTP 4xx
Erori de client (404 etc.). O creștere neașteptată poate indica scanning.
CPU Time
Util pentru detectarea memory leak-urilor sau a buclelor infinite în cod.
Azure SQL Database — Metrici critice
DTU Percentage
Constant la 90–100%? Baza de date este subprovisionată și trebuie upgrade.
CPU Percentage
Utilizarea procesorului la nivelul motorului SQL. Indicator cheie de performanță.
Data IO Percentage
Operațiunile I/O pe disc. Gâtul de sticlă cel mai comun în SQL.
Sessions Count
O creștere neașteptată poate indica un connection leak — conexiuni niciodată închise.
Deadlocks
Blocaje între tranzacții. Indică probleme de design în logica de acces concurent.
Fiecare serviciu are metrici specifice, dar toate urmează aceeași filozofie: utilizare de resurse, performanță, erori.
Observabilitate
Dincolo de monitorizare
Monitorizarea și observabilitatea sunt concepte diferite cu implicații practice distincte.
Monitorizare
Urmărești ce știi deja că contează. Configurezi alerte pentru CPU, memorie, disc. Este un demers reactiv — răspunzi la scenarii pe care le-ai anticipat.
Observabilitate
Sistemul este proiectat astfel încât să poți înțelege orice comportament intern prin ieșirile externe. Poți pune întrebări la care nu te-ai gândit. Este un demers proactiv și exploratoriu.
Cei trei piloni ai observabilității
Metrici
Valori numerice în timp real. Semnalele vitale. Răspund la: Ce se întâmplă acum?
Log-uri
Înregistrări istorice detaliate. Răspund la: De ce s-a întâmplat?
Trace-uri (Distributed Tracing)
Parcursul complet al unei cereri prin toate componentele. Răspund la: Unde s-a pierdut timpul?
Un distributed trace înregistrează fiecare hop: load balancer → API → autentificare → inventar → plăți → email → DB. Azure oferă Application Insights pentru aceasta.
Application Insights — Monitorizarea aplicațiilor
Dacă Azure Monitor este centrul de comandă al infrastructurii, Application Insights este instrumentul dedicat monitorizării aplicațiilor — nu a serverelor, ci a codului, a cererilor și a experienței utilizatorilor.
Ce face concret
Urmărește fiecare cerere HTTP (URL, metodă, cod, durată). Detectează automat dependențele externe (SQL, API-uri, blob). Înregistrează excepțiile negestionate. Urmărește page views și sesiuni.
Smart Detection
Analizează pattern-urile normale și alertează automat la abateri: creștere a ratei de eșec, degradare de performanță, anomalii în timpii de răspuns. Nu trebuie praguri manuale — sistemul învață ce este normal.
Application Map — o vizualizare grafică a componentelor și dependențelor, actualizată în timp real. Integrare în câteva clickuri, fără modificări de cod. SDK-uri: .NET, Java, Node.js, Python, PHP.
Costuri și bune practici în monitorizare
Monitorizarea costă bani. Metricile standard sunt gratuite, dar Log Analytics are costuri bazate pe volume de date.
Ingestie selectivă
Nu trimiteți toate log-urile. Selectați categoriile relevante: erori, avertismente, securitate. Log-urile verbose aparțin development-ului, nu producției.
Retenție adecvată
Datele mai vechi de 90 de zile pot fi arhivate în Azure Storage la un cost considerabil mai mic decât în Log Analytics.
Sampling în App Insights
Dacă aplicația primește mii de cereri/secundă, un eșantion de 10–20% oferă o imagine precisă la un cost mult mai mic.
Monitorizarea nu este un cost. Este o investiție în vizibilitate și reziliență. Costul unui incident major fără date depășește cu mult costul monitorizării.
Scenarii reale de monitorizare
Trei scenarii care se repetă în orice companie care operează sisteme în cloud.
Degradarea performanței
Alertă: Response Time > 2s. App Insights arată că query-urile SQL au crescut de la 20ms la 150ms. DTU la 98%. Cauză: trafic organic crescut. Soluție: Scale up SQL Database. Fără monitorizare: aflați de la utilizatori că e lentă.
Incident de securitate
Trafic neobișnuit pe un server. Log Analytics: mii de autentificări eșuate dintr-un IP extern, între 1:00–3:00 AM. Cauză: atac brute force. Acțiune: blocare IP în NSG, activare 2FA. Fără Log: nu ați fi știut că atacul a avut loc.
Capacitate disc
Alertă la 8 AM: disc la 95%. Log-uri: job nocturn a generat prea multe fișiere temporare. Soluție: extindere disc din portal fără restart + politică de curățare automată. Fără alertă: disc plin, procese oprite.
Cleanup — Ștergerea resurselor
La finalul sesiunii ștergem resursele. Astăzi avem o operație specială înainte de cleanup.
Ștergeți regula de alertă
Navigați la Azure Monitor sau VM → Alerts. Găsiți regula Alert-CPU-High-[prenume] și ștergeți-o explicit.
Ștergeți Resource Group-ul
Resource Groups → rg-s10-[prenumele vostru] → Delete. Confirmați cu numele.
Verificați că nu au rămas resurse
Mergeți la All Resources și filtrați. Asigurați-vă că nu a rămas nicio resursă activă.
Tema pentru acasă
Două puncte principale și un bonus opțional.
Punctul 1 — Explicați conceptele
Explicați diferența dintre o metrică, un log și o alertă. Folosiți o analogie proprie. Imaginați-vă că explicați unui manager non-tehnic de ce are nevoie de monitorizare.
Punctul 2 — Impact de business
De ce este monitorizarea critică pentru o aplicație live? Dați cel puțin două scenarii concrete: pierderi financiare, clienți nemulțumiți, probleme de securitate.
Bonus — Azure Service Health
Cercetați ce este Azure Service Health. Este diferit de monitorizarea resurselor voastre — monitorizează infrastructura Microsoft. Cum ați folosi Service Health la un incident major?
Următoarea sesiune
Sesiunile 11 și 12
Opriți-vă un moment și priviți panorama a ceea ce ați construit. Ați pornit de la zero — de la ce este un IP, ce este un port. Azi, tabloul arată altfel.
Nu știți doar să folosiți servicii Azure. Știți să gândiți arhitectural: de ce folosim asta, ce se întâmplă dacă ceva se strică, cât costă, cine are acces, cum știu că funcționează. Aceasta este mentalitatea unui profesionist cloud.
Vă mulțumesc pentru participare, curiozitate și persistență. Ne vedem la sesiunea unsprezece.