Sesiunea 2
Azure Monitor, Observabilitate și SRE
De la zero la hero — concepte, arhitectură, portal Azure și bune practici
Ghid complet pentru începători și practicieni — de la zero la hero: concepte, arhitectură, portal Azure, exemple reale, AKS, Application Insights, Log Analytics, alerte, workbooks și bune practici de operare.
Ce vei înțelege
Cum funcționează Azure Monitor ca platformă de observabilitate cap-coadă: SLI, SLO, error budget, alert fatigue, cost control și triere operațională.
Ce vei configura
Workspace-uri, alerte, action groups, synthetic monitoring și vizualizare în portalul Azure.
Unde aplici
Aplicații web, infrastructură Azure, workloads cloud-native și AKS.
Arhitectură
Arhitectura Azure Monitor — Vedere de Ansamblu
De la colectare de date la alertare, analiză și răspuns operațional. Observabilitatea nu este un singur produs, ci un lanț complet: colectezi semnale, le stochezi corect, le transformi în informații utile și reacționezi rapid.
1. Surse de telemetrie
Resurse Azure (VM, App Service, AKS, SQL, Storage), Aplicații (requests, exceptions, traces), Kubernetes (Prometheus metrics, container logs), Platformă Azure (Activity Log, Service Health), Teste sintetice (Availability tests).
2. Platforma de date Azure Monitor
Metrice (serii temporale rapide), Logs / Log Analytics (KQL, retenție, corelare), Application Insights (APM, OpenTelemetry), Azure Monitor Workspace (Prometheus managed), Data Collection Rules (control centralizat).
3. Consum operațional
Alerts + Action Groups (email, SMS, webhook, Function, Logic App), Workbooks & Dashboards, Grafana / PromQL, RCA & Troubleshooting, Automatizare SRE (runbooks, tickets, escaladare).
Capitol 1
De ce este Azure Monitor Fundamental într-o Practică SRE
În multe organizații, monitorizarea este tratată prea târziu: după ce aplicația există, după ce utilizatorii se plâng, după ce apare primul incident sever. În realitate, monitorizarea nu este o activitate de 'după' — este fundația pe care se construiește operarea sigură a unui serviciu digital.
Dacă infrastructura este motorul, iar aplicația este mașina, Azure Monitor este bordul de instrumente, cutia neagră și sistemul de alarmă în același timp. Fără el, conduci rapid, dar aproape orb.
SRE ca disciplină
SRE există pentru a ajuta organizația să atingă un nivel potrivit de fiabilitate într-un mod sustenabil — nu 'zero incidente' naiv, ci gestionarea fiabilității cu obiective clare, date și feedback continuu.
Semnale din toate straturile
Azure Monitor oferă semnale din platformă Azure, resurse IaaS/PaaS, aplicații, Kubernetes, Prometheus, synthetic monitoring și health events.
Puterea corelării
Metricele îți spun că există o problemă, logurile te ajută să o explici, iar traces/telemetry îți arată exact unde s-a produs.
O echipă matură nu întreabă 'avem monitorizare?', ci 'putem detecta rapid o degradare, o putem înțelege, putem alerta doar persoana potrivită și putem învăța ceva după incident?'
Ce Înseamnă SRE în Limbaj Practic
Site Reliability Engineering este o disciplină inginească orientată spre fiabilitate, nu doar o funcție operațională. SRE înseamnă să tratezi producția ca pe un produs viu, măsurat continuu, nu ca pe o zonă unde 'sperăm să meargă'.
SLI
Service Level Indicator — ce măsori efectiv: latența P95 sau procentul de request-uri 2xx/3xx.
SLO
Service Level Objective — ținta internă: de exemplu 99.9% disponibilitate pe 30 de zile.
SLA
Service Level Agreement — promisiunea contractuală făcută clientului.
Error Budget
Spațiul permis pentru eșec fără a depăși SLO-ul; te ajută să echilibrezi viteză versus stabilitate.
Golden Signals
Latență, trafic, erori, saturație — model mental de pornire extrem de util.
Toil
Muncă repetitivă, manuală, fără valoare inginească pe termen lung. Un SRE matur o reduce prin automatizare.
Bucla SRE: De la Telemetrie la Îmbunătățire Continuă
Azure Monitor devine valoros doar când datele duc la decizii și automatizare.
Observă
Metrics, logs, traces — colectezi semnale din toate straturile.
Înțelege
Dashboards, queries, context — transformi datele în informații utile.
Alertează
Corect, acționabil — notifici persoana potrivită la momentul potrivit.
Răspunde
Runbook, on-call, incident — acționezi rapid și structurat.
Înveți
Postmortem, SLO review, toil reduction — îmbunătățești continuu.
Ce Problemă Rezolvă Azure Monitor într-o Companie Reală
| Situație | Fără observabilitate | Cu Azure Monitor bine configurat |
|---|---|---|
| Descoperirea incidentelor | Din reclamațiile utilizatorilor | Detectate înainte de impact major sau imediat după debut |
| Calitatea alertelor | Multe alerte, puține utile | Alerte mapate pe severitate, owner și runbook |
| Corelarea datelor | Date fragmentate în silozuri | Metrice, logs și traces corelate în aceeași investigație |
| Vizibilitate AKS | AKS este o "cutie neagră" | Prometheus, Container insights și Grafana dau vizibilitate detaliată |
| Învățare după incident | Nu se învață nimic | Postmortem-ul ajustează SLO, alerte și dashboard-uri |
Capitol 2
Cum este Construit Azure Monitor
Azure Monitor nu este un singur produs cu un singur ecran. Este o platformă compusă din mai multe piese care lucrează împreună. Dacă înțelegi clar fiecare piesă, portalul devine mult mai ușor de urmărit.
Metrics
Date numerice time-series, rapide, excelente pentru grafice și alertare aproape în timp real.
Logs
Date bogate, interogabile cu KQL, excelente pentru investigații, corelare și analiză complexă.
Application Insights
APM pentru aplicații, bazat modern pe OpenTelemetry pentru multe scenarii.
Log Analytics Workspace
Spațiul principal în care locuiesc logurile Azure Monitor — centrul pentru KQL și investigații.
Azure Monitor Workspace
Workspace separat folosit în special pentru metricile Prometheus managed.
Data Collection Rules (DCR)
Mecanism centralizat care definește ce se colectează și unde se trimite.
Alerts & Action Groups
Lanțul prin care datele devin notificări și acțiuni.
Workbooks și Grafana
Zona de consum și vizualizare avansată pentru echipe și management.
Logs, Metrics și Traces: Când Alegi Fiecare
Regula simplă: dacă vrei să vezi 'cât de mult' și să alertezi repede, începi cu metrics. Dacă vrei să înțelegi 'de ce s-a întâmplat', folosești logs. Dacă vrei să urmărești un request prin întregul flux aplicațional, ai nevoie de traces.
Metrics
Foarte rapid, time-series, cost/control bun. Exemple: CPU, memory, request rate, node pressure, latency P95.
Logs
Bogate în context, interogare flexibilă. Exemple: erori aplicație, audit, kube events, stdout/stderr.
Traces / APM
Legătură end-to-end între operații și dependențe. Exemple: un request care trece prin API, DB, queue și servicii externe.
Nu confunda cele două workspace-uri! LAW = centrul pentru logs. AMW = esențial pentru ecosistemul Prometheus managed.
Application Insights pe Scurt
Application Insights este componenta APM din Azure Monitor. Pentru multe scenarii moderne, Microsoft recomandă instrumentarea prin OpenTelemetry — o abordare mai portabilă și mai standard pentru telemetry de aplicație.
Ce colectează
Requests, dependencies, exceptions, traces, availability telemetry și metrice relevante de aplicație.
Ideal pentru
Web apps, API-uri, servicii backend și workload-uri în care contează experiența end-to-end.
Control cost și volum
Poți folosi sampling și filtre pentru a controla costul și volumul de date ingerate.
Recomandare aplicații noi
Pornește cu OpenTelemetry, nu cu o strategie veche de instrumentare, dacă nu ai un motiv puternic.
Cum Citești Portalul Azure când Lucrezi cu Azure Monitor
Un motiv pentru care Azure Monitor pare complex este că funcționalitatea este distribuită în mai multe locuri din portal. Trebuie să înveți harta, nu doar butoanele.
| Secțiune portal | Ce găsești |
|---|---|
| Azure Monitor > Overview | Punctul central: alerts, metrics, logs, insights, workbooks, action groups, DCRs |
| Resursă individuală > Monitoring | Metrice, diagnostic settings, alerts și insights direct pe resursa respectivă |
| Log Analytics Workspace | Queries, tables, retention, solutions, access control |
| Application Insights | Failures, performance, application map, live metrics, availability |
| AKS > Monitoring | Container insights, Prometheus, Grafana, logs, node/workload health |
Capitol 4
Laborator Ghidat: Construire de la Zero a unei Fundații Azure Monitor
Construim un setup didactic complet, simplu, dar suficient de realist pentru majoritatea claselor. Scopul nu este să configurăm absolut tot din prima, ci să înțelegem piesele și motivele fiecărei alegeri.
Pașii 1–3: Resource Group, Log Analytics Workspace și Retenție
Pasul 1: Creează Resource Group-ul pentru observability
Portal > Resource groups > Create. Nume exemplu: rg-monitoring-dev-weu. Un RG dedicat oferă guvernare mai bună, lifecycle mai clar și separare mentală sănătoasă între workload și platforma de monitorizare.
Pasul 2: Creează Log Analytics Workspace
Portal > Log Analytics workspaces > Create. Nume: law-monitoring-dev-weu. LAW este 'depozitul inteligent' pentru logs — aici rulezi KQL, investighezi incidente și stochezi date din diagnostic settings.
Pasul 3: Configurează retenția și cost awareness
Laborator/curs: 7-30 zile (cost mic). Producție standard: 30-90 zile (echilibru). Audit/compliance: 90+ zile sau export (doar dacă cerință reală).
Nu crea câte un workspace pentru fiecare resursă fără motiv. Câteva workspace-uri bine gândite sunt mai sănătoase decât zeci de workspace-uri haotice.
Pașii 4–6: Application Insights, Azure Monitor Workspace și Action Group
Pasul 4: Creează Application Insights (workspace-based)
Portal > Application Insights > Create. Alege Workspace-based mode și leagă resursa de LAW-ul creat. Centralizează analiza și permite corelarea naturală a telemetriei.
Pasul 5: Creează Azure Monitor Workspace pentru Prometheus
Portal > Azure Monitor workspaces > Create. Aceeași regiune cu AKS. Regula simplă: logs în LAW, Prometheus în AMW. Nu crea dacă laboratorul nu include AKS.
Pasul 6: Creează Action Group
Azure Monitor > Alerts > Action groups > Create. Nume: ag-ops-core. Adaugă cel puțin o acțiune: email pentru laborator. Gândește-le ca pachete reutilizabile.
Fluxul unei Alerte Bune în Azure Monitor
Model recomandat pentru reducerea alert fatigue și accelerarea răspunsului operațional.
Semnal
Metrică, log, trace, availability test, Activity Log.
Condiție
Threshold static/dinamic, KQL, PromQL, severitate.
Alert Rule
Scop, frecvență, window, split by dimension.
Action Group
Email, Teams via webhook, SMS, Function, ITSM.
Triere SRE
Acknowledge, investigație, runbook, RCA.
Severitate
Folosește Sev 0-4 cu reguli clare de business.
Noise Control
Aplică processing rules și praguri dinamice.
Ownership
Fiecare alertă trebuie să aibă owner și runbook.
Learning Loop
După incident, ajustezi regula sau dashboard-ul.
Capitol 5
Diagnostic Settings, DCR și Colectarea Datelor
Mulți începători configurează alerte înainte să se asigure că datele chiar ajung unde trebuie. Este o greșeală clasică. Mai întâi confirmi colectarea, apoi construiești vizualizare și alertare.
Diagnostic Settings
Mecanismul prin care resursele Azure trimit logs și metrics către destinații: Log Analytics Workspace (prima alegere), Storage Account (arhivă), Event Hub (streaming SIEM).
Data Collection Rules (DCR)
Definesc ce date se colectează, de unde și în ce destinație ajung. Pentru Azure Monitor Agent, Prometheus managed și alte fluxuri moderne, DCR este piesa de control.
Verificarea colectării — pași esențiali
Verifică resursa monitorizată
Deschide resursa și verifică secțiunea Monitoring.
Diagnostic settings
Asigură-te că trimit în workspace-ul corect.
Testează în LAW
Rulează o interogare simplă pe ultimele 30 minute.
Construiește alerta
Abia după aceea construiește alerta.
Capitol 6
Alerte în Azure Monitor: Toate Opțiunile Importante
Alertele nu sunt scopul final — ele sunt mecanismul prin care observabilitatea devine acțiune. O alertă bună este clară, măsurabilă, ușor de triat și legată de un owner.
Tipuri de alerte
| Tip alertă | Pe ce se bazează | Exemple bune |
|---|---|---|
| Metric alerts | Metrice platform, custom sau App Insights | CPU, memory, response time, node pressure |
| Log search alerts | Query KQL în LAW sau alte surse de logs | Erori aplicație, pattern de excepții, evenimente Kubernetes |
| Activity Log alerts | Evenimente de control plane Azure | Ștergere resource group, schimbări de role |
| Service Health alerts | Starea serviciilor Azure și mentenanță planificată | Incident regional Azure, advisory, maintenance |
| Prometheus alerts | Metrice Prometheus / PromQL | Pod restarts, kube-state, latency cloud-native |
În practică, folosești mai multe tipuri simultan: metric alert pentru semnale rapide, log alert pentru context, activity log alert pentru guvernare.
Metric Alert vs Log Alert și Dynamic vs Static Thresholds
Metric Alert
Când ai un numeric bine definit și vrei reacție rapidă. Exemplu: CPU > 80% timp de 10 minute pe o VM.
Log Alert
Când ai nevoie de logică bogată și context din query. Exemplu: TimeoutException > 20 în 15 minute.
Static Threshold
Tu alegi pragul — de exemplu CPU > 80%. Consum simplu, explicabil, bun când comportamentul este predictibil.
Dynamic Threshold
Platforma învață comportamentul istoric și detectează anomalii. Bun când semnalul are variații sezoniere.
Pentru studenți: începe cu static thresholds. După ce înțeleg stabil ce măsoară, introdu dynamic thresholds ca maturizare.
Exemplu Ghidat: Creează o Metric Alert în Portal
Intră pe resursă
App Service, VM sau AKS cluster.
Monitoring > Alerts > Create > Alert rule
Scope: verifică resursa corectă.
Condition
Alege metrică relevantă (Response Time, CPU Percentage sau Requests Failed).
Configurează
Aggregation, operator, threshold, frequency și lookback window.
Atașează Action Group
Setează severity și name clar: ex. app-web-prod-high-latency.
Scope = unde observi. Condition = când e problemă. Frequency/window = sensibilitatea. Severity = prioritatea. Action Group = cine află și ce se execută.
Capitol 7
Workbooks, Dashboards și Vizibilitate Executivă
Workbooks sunt una dintre cele mai subestimate componente din Azure Monitor. Ele combină text explicativ, metrice, query-uri, parametri și grafice într-un singur raport interactiv. Un workbook bun nu este doar un dashboard frumos — este un instrument de decizie.
Exemplu de structură Workbook pentru AKS
| Secțiune | Scop | Exemple de conținut |
|---|---|---|
| 1. Health summary | Stare generală | Cluster state, alerts, node readiness, incidents active |
| 2. Capacity | Capacitate | CPU/memory requests vs limits, node pressure, autoscaler activity |
| 3. Workloads | Sănătatea workload-urilor | Top namespaces, pod restarts, crash loops, deployments unhealthy |
| 4. Networking | Rețea | Ingress errors, DNS issues, latency, dropped packets |
| 5. Cost & retention | Cost | Volum logs, top noisy tables, sampling notes |
Capitol 8
Synthetic Monitoring și Availability Tests
Synthetic monitoring înseamnă să testezi proactiv aplicația chiar dacă încă nu există trafic real de utilizator. Este esențial pentru disponibilitate și degradări lente.
Ping / Standard Web Test
Pentru disponibilitate de bază și latență. Excelent punct de pornire pentru studenți.
Multi-step / Scenarii bogate
Pentru fluxuri funcționale unde simplul 200 OK nu este suficient.
Dependențe externe
Verifici API-uri externe, DNS, endpoint-uri publice. Foarte util în operațiuni enterprise.
Pași de configurare în portal
Deschide Application Insights
Selectează Availability sau Availability tests.
Create test
Completează URL-ul, locațiile, frecvența și criteriile de succes.
Activează alertarea
Dacă testul eșuează sau latența depășește pragul.
Validează
Salvează și verifică după câteva cicluri.
Unele probleme apar înainte ca utilizatorii să le raporteze. Testele sintetice pot prinde situația foarte devreme.
Capitol 9
Advanced Monitoring pentru AKS: Extensia Cloud-Native
Pentru AKS, Azure Monitor devine și mai valoros, deoarece Kubernetes introduce complexitate operațională reală: noduri, pods, namespaces, control plane, autoscaling, containers, Prometheus metrics, logs și evenimente.
Container Insights
Logs stdout/stderr, evenimente și performanță de cluster și container. Vizibilitate completă la nivel de workload.
Prometheus Metrics
Metrice Kubernetes native și custom exporters. Stocate în Azure Monitor Workspace, interogabile cu PromQL.
Azure Managed Grafana
Dashboard-uri bogate și interactivitate cloud-native. Integrare nativă cu AMW și Prometheus managed.
Diagnostic Settings Control Plane
Audit și troubleshooting al clusterului. Esențial pentru investigații avansate.
Ce Urmărești în AKS
| Arie | Semnale utile |
|---|---|
| Disponibilitate cluster | Node Ready, API server health, workload health |
| Capacitate | CPU/memory usage, requests/limits, pending pods, autoscaler activity |
| Stabilitate workload | Restarts, CrashLoopBackOff, OOMKilled, failed probes |
| Rețea și trafic | Ingress errors, latency, DNS, connection failures |
| Cost și zgomot | Namespace-uri cu prea multe logs sau metrice inutile |
Capitol 10
Cazuri Reale de Utilizare
API business critic — răspunde lent
Metric alert detectează latența P95 crescută, availability test confirmă degradarea, App Insights arată dependency calls lente, Log Analytics confirmă spike de timeout exceptions. Lecția: puterea vine din corelare.
Governance și schimbări neautorizate
Activity Log alert detectează ștergerea unui NSG, Action Group trimite notificare webhook, Alert processing rule evită spamul în fereastra de mentenanță. Lecția: monitorizarea = control operațional.
AKS cu incidente intermitente
Container insights arată pod restarts, Prometheus indică memory saturation, Grafana evidențiază pattern pe namespace. Postmortem-ul duce la ajustarea requests/limits.
Echipa executivă cere "o singură vedere"
Workbook executiv cu availability, error rate, cost hotspots. Separi workbook tehnic pentru SRE. Lecția: stakeholderii au nevoie de niveluri diferite de detaliu.
Capitol 11
Cost Control și Bune Practici
Bune practici esențiale
Colectează doar ce folosești
Nu activa toate categoriile de logs fără scop clar.
Separă medii și ownership
Evită amestecul haotic între dev/test/prod.
Folosește sampling
Mai ales pentru Application Insights și volum mare.
Optimizează retenția
Nu păstra luni întregi date fără valoare operațională.
Controlează cardinalitatea
Mai ales în Prometheus și cloud-native monitoring.
Revizuiește alertele lunar
Șterge sau ajustează alertele zgomotoase.
Anti-pattern-uri frecvente: workspace nou pentru fiecare resursă, alertă pentru orice mic spike fără context, severity mare pentru evenimente minore, diagnostic settings activate 'ca să fie' fără owner, AKS monitorizat doar la nivel de nod.
Principiu simplu de maturitate: începi cu vizibilitate minimă sănătoasă, nu cu perfecțiune. Apoi crești maturitatea în pași: semnale de bază → dashboard-uri → alerte curate → synthetic monitoring → corelare aplicație-infrastructură → automatizare și SLO-driven operations.
Capitol 12
Model de Implementare Recomandat pentru Curs
Această progresie funcționează foarte bine pentru studenți. Nu îi sufoci de la început cu tot portofoliul, dar nici nu simplifici excesiv.
Nivel 1 — Fundamentals
Overview Azure Monitor, metrics vs logs, LAW, o alertă simplă, un workbook de bază.
Nivel 2 — Operations
Action groups, log alerts, Service Health, Activity Log, diagnostic settings.
Nivel 3 — Application Observability
Application Insights, exceptions, traces, availability tests.
Nivel 4 — Cloud-Native
AKS monitoring, Prometheus, Grafana, Container insights.
Nivel 5 — SRE Practice
SLI/SLO, error budgets, alert tuning, postmortem și toil reduction.
Capitol 13
Checklist de Implementare Minimă pentru Orice Organizație
Definește ce este critic
Aplicații, endpoint-uri, procese și active de business. Fără această claritate, totul pare la fel de important.
Stabilește 3-5 SLI-uri principale
Pentru fiecare serviciu important. Acestea devin baza pentru SLO-uri și error budgets.
Creează cel puțin un Log Analytics Workspace
Cu un model clar de ownership. Configurează diagnostic settings pe resursele-cheie.
Activează Application Insights
Pentru aplicațiile importante. Configurează Action Groups și câteva alerte utile.
Adaugă availability tests și workbook-uri
Pentru punctele publice critice. Construiește 1-2 workbook-uri cu adevărat utile.
Dacă folosești AKS
Activează Container insights și Prometheus managed. Planifică revizuirea lunară a alertelor, costului și retenției.
Capitol 14
Recomandări Finale pentru Studenți
Înțelege fluxul, nu meniurile
Înțelege fluxul: sursă de date → stocare → analiză → alertare → răspuns.
Pornește cu un scenariu real
O aplicație, o resursă, un endpoint critic. Nu porni cu totul dintr-o dată.
Justifică fiecare alertă
Dacă nu poți explica de ce există, probabil nu ar trebui să existe.
SRE matur = mai mult decât dashboard-uri
Fără runbook-uri și ownership, nu faci încă SRE matur. Pentru AKS, combină infrastructură, Kubernetes și aplicație.
Cel mai bun mod de a preda Azure Monitor este să pornești de la incidente credibile: latență mare, excepții, resource deletion accidental, pod restarts, certificat expirat, endpoint indisponibil. Acolo studentul înțelege imediat de ce observabilitatea contează.
Anexa A
Exemple Utile de KQL pentru Laborator
Query-uri KQL de pornire
| Scop | Query |
|---|---|
| Heartbeat — agenți care raportează | Heartbeat | where TimeGenerated > ago(15m) | summarize LastSeen=max(TimeGenerated) by Computer |
| Erori de aplicație | AppExceptions | where TimeGenerated > ago(30m) | summarize Errors=count() by ProblemId |
| Request-uri lente | AppRequests | where TimeGenerated > ago(30m) | summarize AvgDuration=avg(DurationMs) by bin(TimeGenerated, 5m) |
| Kubernetes warnings | KubeEvents | where TimeGenerated > ago(30m) | where Type == 'Warning' |
| Top tabele cu volum | Usage | where TimeGenerated > ago(1d) | summarize QuantityGB=sum(Quantity)/1024 by DataType | sort by QuantityGB desc |
Testează întotdeauna query-ul în LAW înainte de a crea o alertă bazată pe el.
Anexa B
Întrebări Bune de Pus într-un Workshop SRE
Serviciul cel mai important
Care este cel mai important serviciu digital pentru business și cum îl măsurăm?
Alertele de noapte
Ce alertă ne trezește noaptea și chiar merită asta?
Ownership
Ce semnal avem astăzi, dar nu știm cine îl deține?
Corelare incidente
Putem vedea rapid diferența dintre incident de aplicație și incident de platformă?
Cost inutil
Ce date colectăm degeaba și ne costă inutil?
Monitoring sintetic
Ce endpoint public ar trebui monitorizat sintetic chiar azi?
Anexa C
Resurse Oficiale Microsoft Learn Recomandate
Fundamente Azure Monitor
Azure Monitor overview, Azure Monitor data platform, Azure Monitor Logs overview, Types of Azure Monitor alerts.
Alerte și Action Groups
Action groups in Azure Monitor, Alert processing rules, Application Insights overview și availability tests.
Vizualizare și Colectare
Azure Workbooks overview, Data collection rules (DCRs) in Azure Monitor.
AKS și Kubernetes
Monitor Azure Kubernetes Service (AKS), Best practices for monitoring Kubernetes with Azure Monitor.
Toate resursele sunt disponibile gratuit pe learn.microsoft.com.
Verifică-ți cunoștințele
1 Care sunt cele trei tipuri de semnale în observabilitate?
Metrics, Logs și Traces.
2 Ce este un SLO și cum diferă de un SLA?
SLO (Service Level Objective) este ținta internă de fiabilitate. SLA (Service Level Agreement) este promisiunea contractuală către client.
3 Care este diferența între Log Analytics Workspace și Azure Monitor Workspace?
LAW este centrul pentru logs (KQL, investigații). AMW este dedicat metricilor Prometheus managed.
4 De ce nu ar trebui să creezi alerte înainte de a verifica colectarea datelor?
Pentru că alertele fără date sunt inutile. Mai întâi confirmi că semnalele ajung în workspace-ul corect, apoi construiești alerte.
5 Ce înseamnă Error Budget?
Spațiul permis pentru eșec fără a depăși SLO-ul; te ajută să echilibrezi viteză versus stabilitate.
6 Ce componente Azure Monitor sunt esențiale pentru AKS?
Container Insights, Prometheus Metrics, Azure Managed Grafana și Diagnostic Settings pentru Control Plane.
Resurse și Pași Următori
Azure Monitor este fundația oricărei practici SRE mature în cloud. Pornește de la un scenariu real, construiește observabilitate pas cu pas și maturizează continuu.