Sari la conținutul principal

Laboratorul 5 - Observabilitate și autoscaling

În laboratoarele anterioare am containerizat aplicația Ticketing API, am rulat-o în Kubernetes împreună cu PostgreSQL și am împachetat resursele într-un chart Helm. În acest laborator trecem de la întrebarea „rulează aplicația?” la întrebările operaționale:

  • Câte cereri primește și câte eșuează?
  • Care este latența percepută de utilizator?
  • Ce pod sau ce componentă consumă resurse?
  • Putem detecta o degradare înainte să devină indisponibilitate?
  • Cum reacționează HPA la încărcare și ce nu poate rezolva autoscaling-ul?

Aplicația este oferită integral, deci nu vom scrie logică Go în timpul laboratorului. Vom urmări legătura dintre instrumentarea existentă, resursele Kubernetes și datele observate.

Obiective​

La finalul laboratorului veți putea:

  • diferenția metricile de resurse de metricile aplicației
  • explica rolurile Metrics Server, cAdvisor, Prometheus, Grafana și Alertmanager
  • verifica endpoint-ul /metrics și țintele descoperite prin ServiceMonitor
  • folosi PromQL pentru semnalele RED: rate, errors, duration
  • interpreta un dashboard Grafana păstrat ca artefact versionat
  • corela metrici, loguri și starea resurselor Kubernetes
  • urmări deciziile unui HorizontalPodAutoscaler
  • investiga și remedia un incident controlat de latență și erori.

Cele trei surse folosite în diagnostic​

SursăÎntrebarea principalăExemplu în laborator
MetriciCe se întâmplă și cât de des?rata cererilor, erori, latență p95, CPU
LoguriCe s-a întâmplat într-o cerere concretă?request_id, rută, status și durată
Starea KubernetesCum reacționează platforma?Pod-uri, evenimente, HPA și rollout
Despre traces

Trace-urile distribuite devin esențiale când o cerere traversează mai multe servicii. Aplicația acestui laborator este încă un singur serviciu, astfel încât ne concentrăm practic pe metrici și loguri. Instrumentarea cu OpenTelemetry este apoi un pas următor natural.