Sistemul funcționează. Până în momentul în care încetează
Imaginează-ți un magazin online în care clienții pot răsfoi produsele, le pot adăuga în coș și pot trece la plată. Serverul răspunde, pagina se deschide, iar indicatorii de bază ai infrastructurii nu arată nicio problemă gravă. La prima vedere, totul funcționează corect.
Între timp, o parte dintre clienți nu reușesc să finalizeze comanda. Pentru unii plata durează câteva zeci de secunde, iar pentru alții apare o eroare. Echipa tehnică primește sesizări, dar nu știe încă dacă cauza este gateway-ul de plată, baza de date, ultima actualizare a aplicației sau poate o problemă de comunicare între servicii.
Aceasta este o situație în care monitorizarea obișnuită se poate dovedi insuficientă. Poate indica faptul că a crescut numărul de erori sau că s-a mărit timpul de răspuns, dar nu oferă întotdeauna informațiile necesare pentru a găsi rapid cauza.
Exact această lacună este acoperită de observability, adică observabilitatea sistemului. Scopul ei nu este doar constatarea faptului că aplicația funcționează incorect. Este vorba despre posibilitatea de a analiza comportamentul ei, de a reconstrui desfășurarea evenimentelor și de a găsi sursa problemei, inclusiv atunci când înainte nu a fost prevăzut un scenariu concret de defecțiune.
Monitorizare și observability - scopuri similare, posibilități diferite
Monitorizarea și observability sunt strâns legate, dar nu înseamnă același lucru.
Monitorizarea constă în colectarea și analizarea sistematică a datelor despre starea aplicației și a infrastructurii. Ea permite urmărirea unor parametri definiți, detectarea abaterilor de la normele stabilite și declanșarea alertelor atunci când apare o situație care necesită reacție.
Întrebări de exemplu la care răspunde monitorizarea sunt:
- Este serverul disponibil?
- Care este timpul mediu de răspuns al API-ului?
- Numărul de erori HTTP 500 depășește pragul stabilit?
- Care este utilizarea memoriei și a procesorului?
- Coada de sarcini crește mai repede decât poate sistemul să o proceseze?
Observability merge mai departe. Permite analizarea datelor provenite din diferite părți ale sistemului și conectarea lor într-un context care ajută la înțelegerea motivului pentru care a apărut un anumit comportament.
Se poate rezuma în trei întrebări:
- Monitorizare: Ceva nu este în regulă?
- Diagnoză: Unde a apărut problema?
- Observability: Ce s-a întâmplat, de ce și care a fost impactul asupra funcționării sistemului?
Observabilitatea nu înlocuiește monitorizarea. Este o abordare care folosește monitorizarea și datele telemetrice pregătite corespunzător pentru a permite o analiză mai profundă a comportamentului aplicației. OpenTelemetry descrie observability ca posibilitatea de a adresa sistemului întrebări despre comportamentul său pe baza semnalelor precum logurile, metricile și trasările distribuite. <Cite ref="turn154932search0"/>
Cei trei piloni ai observability: loguri, metrici și tracing
La baza observabilității stau trei tipuri de date telemetrice: logs, metrics și traces. Fiecare arată un aspect diferit al funcționării aplicației. Abia corelarea lor oferă o imagine mai amplă a situației.
1. Loguri - ce s-a întâmplat în aplicație?
Logurile (logs) sunt înregistrări ordonate ale evenimentelor generate de aplicație, sistemul de operare, servere, baze de date și alte elemente ale infrastructurii.
Ele pot înregistra, de exemplu:
- începerea și încheierea unui proces,
- încercarea de autentificare a utilizatorului,
- trimiterea unei cereri către un API extern,
- o eroare de validare a datelor,
- o tranzacție eșuată,
- o excepție generată de aplicație,
- schimbarea stării unei comenzi.
Un log poate conține un marcaj temporal, nivelul de severitate, numele serviciului, mesajul, identificatorul cererii și atribute suplimentare care descriu evenimentul.
Merită să facem distincția între logurile textuale și logurile structurate. O înregistrare textuală poate arăta astfel:Eroare la procesarea comenzii
Un astfel de mesaj indică apariția unei probleme, dar spune puțin despre contextul ei. Un log structurat poate conține însă câmpuri separate, precum identificatorul comenzii, numele operațiunii, codul de eroare, timpul de execuție și identificatorul traseului. Astfel, datele pot fi filtrate, grupate și analizate automat.
Bună practică: logurile ar trebui proiectate având în vedere analiza ulterioară, nu doar salvarea mesajelor. Merită folosită o denumire consecventă, niveluri de severitate și identificatori de corelare care să permită asocierea evenimentelor provenite din componente diferite.
În același timp, logarea necesită rațiune. Înregistrarea fiecărei operațiuni în întregime poate genera cantități uriașe de date, poate crește costurile de stocare și poate îngreuna găsirea informațiilor relevante. La fel de important, logurile nu ar trebui să dezvăluie parole, tokenuri de acces, datele cardurilor de plată sau alte informații confidențiale. Trebuie aplicate mascarea, controlul accesului, perioadele adecvate de retenție și reguli pentru procesarea sigură a datelor.
2. Metrici - cum se comportă sistemul în timp?
Metricile (metrics) sunt date numerice agregate care descriu starea, performanța și comportamentul sistemului într-o anumită perioadă.
Metricile de exemplu includ:
- numărul de cereri procesate pe secundă,
- procentul cererilor finalizate cu eroare,
- timpul de răspuns al API-ului,
- utilizarea CPU și a memoriei,
- numărul sesiunilor active,
- lungimea cozii de sarcini,
- numărul tranzacțiilor finalizate,
- timpul de așteptare pentru o conexiune la baza de date.
Cel mai mare avantaj al lor este posibilitatea de a observa tendințele. O singură eroare poate fi un incident, dar un timp de răspuns care crește treptat, un număr tot mai mare de tranzacții eșuate sau o coadă de sarcini care se acumulează pot indica o problemă în dezvoltare.
În practică, metricile ajută să răspundem nu doar la întrebarea dacă aplicația funcționează, ci și dacă performanța ei corespunde așteptărilor utilizatorilor și cerințelor de business.
Deosebit de utile sunt percentilele timpului de răspuns, de exemplu p95 și p99. Media poate ascunde situația în care majoritatea utilizatorilor primesc răspuns rapid, dar o mică parte se confruntă cu întârzieri foarte mari. Percentilele arată cât durează procesarea cererilor mai lente și ajută la observarea problemelor invizibile în valorile medii.
Bună practică: alege metrici care contează pentru utilizator și pentru procesul de business. Informația despre încărcarea procesorului nu îți va spune singură dacă un client poate plasa o comandă. Merită deci să monitorizezi și indicatori legați de funcțiile esențiale, precum succesul plăților, timpul de procesare a comenzilor sau disponibilitatea celor mai importante operațiuni.
3. Tracing - pe unde a trecut cererea?
Tracing, și în special distributed tracing, adică urmărirea distribuită, permite urmărirea traseului unei cereri individuale prin diferite componente ale sistemului.
Într-o aplicație modernă, o acțiune a utilizatorului poate include mai multe etape. Apăsarea butonului „Plasează comanda” poate declanșa o cerere în browser, care ajunge la API, apoi la serviciul de comenzi, la baza de date, la sistemul de depozit și la operatorul extern de plăți.
Dacă procesul se întârzie, simpla informație despre timpul de răspuns al întregului API poate să nu fie suficientă. Tracing-ul permite descompunerea acestui timp în operațiuni individuale și arată care etapă este responsabilă de întârziere.
Elementul de bază al unui trace este span-ul, adică înregistrarea unei singure operațiuni. Span-ul poate conține momentul de început și de sfârșit, numele operațiunii, statusul și metadatele. Span-urile asociate formează un trace care arată desfășurarea întregii cereri.
De exemplu:
- API-ul primește cererea și o transmite mai departe.
- Serviciul de comenzi verifică datele.
- Baza de date salvează comanda.
- Serviciul de depozit verifică disponibilitatea produsului.
- Gateway-ul de plată extern procesează tranzacția.
- Aplicația returnează rezultatul către utilizator.
Dacă întregul proces durează 8 secunde, tracing-ul poate arăta că 6,5 secunde au fost consumate de răspunsul gateway-ului extern de plată, iar celelalte operațiuni s-au desfășurat corect. Echipa primește astfel un punct concret pentru analiză ulterioară, în loc să înceapă diagnosticarea de la componente alese întâmplător.
Tracing-ul este deosebit de util în arhitecturile microservicii, sistemele distribuite, aplicațiile bazate pe cozi și soluțiile care integrează mai multe servicii externe. <Cite ref="turn154932search0"/>
Alerte - informația trebuie să ajungă la persoana potrivită
Datele de telemetrie sunt utile doar atunci când se poate acționa pe baza lor. De aceea, o parte importantă a observability este sistemul de alertare.
O alertă este o notificare despre un eveniment sau o stare care necesită atenție. Poate fi declanșată după depășirea unui prag al unei metrici, detectarea unui anumit tipar de erori sau constatarea faptului că o funcție esențială a aplicației nu funcționează conform așteptărilor.
Totuși, nu orice creștere a încărcării ar trebui să genereze o alarmă. Dacă sistemul gestionează regulat trafic mare la orele de vârf, notificarea fiecărei creșteri a numărului de cereri va produce zgomot informațional. Prea multe alerte duc la ignorarea lor și, în consecință, la trecerea cu vederea a unui incident cu adevărat important.
Prin urmare, merită stabilit:
- ce evenimente necesită reacție imediată,
- ce probleme pot fi analizate în regim normal de lucru,
- cine este responsabil pentru un anumit tip de alertă,
- ce informații ar trebui să conțină notificarea,
- ce acțiuni trebuie întreprinse după primirea ei.
Un bun punct de plecare este definirea alertelor pe baza impactului asupra utilizatorului și a obiectivelor de fiabilitate, nu doar pe baza parametrilor infrastructurii. De exemplu, o alertă privind creșterea procentului de plăți eșuate poate avea o importanță de business mai mare decât o creștere de scurtă durată a utilizării CPU-ului.
O alertă ar trebui să conducă la o acțiune. Dacă nu se știe cine trebuie să o gestioneze și ce trebuie făcut, ea este doar un alt mesaj în sistem.
Exemplu din practică: cum ajută observability la găsirea cauzei unei avarii?
Să presupunem că utilizatorii aplicației B2B semnalează că generarea rapoartelor durează mult mai mult decât de obicei. Monitorizarea detectează creșterea timpului de răspuns și declanșează o alertă.
Echipa începe analiza:
- Metricile arată că problema afectează în principal rapoartele care includ intervale mari de date. Celelalte funcții funcționează normal.
- Tracing-ul arată că cea mai mare întârziere apare în timpul executării unei interogări către baza de date.
- Logurile conțin detalii despre interogare, parametrii ei operaționali și informații despre erori, fără a dezvălui date sensibile.
- Corelarea datelor permite asocierea unui trace concret cu intrările corespunzătoare din loguri și cu modificările vizibile pe graficele metricilor.
- Analiza schimbării arată că problema a apărut după implementarea noii versiuni a raportului, care a început să execute o interogare costisitoare.
Datorită acestui lucru, echipa nu trebuie să verifice orbește întreaga infrastructură. Se poate concentra pe o operațiune concretă, poate compara comportamentul înainte și după implementare și apoi poate optimiza interogarea sau poate reveni asupra modificării.
Observability nu elimină avariile și nu garantează că fiecare cauză va fi găsită automat. Totuși, permite restrângerea ariei de căutare, scurtarea timpului de diagnostic și bazarea deciziilor pe date, nu pe presupuneri.
Corelarea datelor - cea mai mare valoare apare împreună
Logurile, metricile și tracing-ul sunt utile separat, dar adevărata lor valoare se dezvăluie atunci când pot fi corelate între ele.
Să ne imaginăm că dashboard-ul arată o creștere bruscă a timpului de răspuns. Metrica indică când și în ce amploare a apărut problema. Trace-ul arată ce operațiuni au alcătuit cererea lentă. Logurile permit verificarea evenimentelor apărute într-o etapă concretă.
Pentru ca acest lucru să fie posibil, sistemul ar trebui să transmită consecvent contextul cererii între servicii. Identificatorii de trace și span pot fi folosiți pentru a lega înregistrările din loguri de trace-uri. Merită, de asemenea, păstrate informații consecvente despre numele serviciului, mediul, versiunea aplicației și alte atribute care descriu sursa datelor.
Fără corelare, echipa poate avea acces la numeroase dashboard-uri, fișiere și instrumente, dar tot să piardă timp stabilind manual ce evenimente sunt legate între ele. OpenTelemetry indică corelarea logurilor, a trace-urilor și a contextului resurselor ca element important în construirea unei telemetrii utile. <Cite ref="turn154932search1"/>
OpenTelemetry - un standard comun pentru datele de telemetrie
Implementarea observability-ului nu trebuie să însemne dependență de un singur furnizor de instrumente. Una dintre soluțiile care susțin interoperabilitatea este OpenTelemetry (OTel) - un set deschis de standarde, interfețe API, biblioteci și instrumente pentru instrumentarea, generarea, colectarea și exportul datelor de telemetrie.
OpenTelemetry permite aplicației să emită metrici, loguri și trace-uri într-un model coerent. Datele pot fi apoi transmise către backend-ul de observability ales, care se ocupă de stocarea, căutarea, vizualizarea și analiza lor.
Un element important al ecosistemului este OpenTelemetry Collector. Acesta poate primi date din diverse surse, le poate procesa, îmbogăți cu context suplimentar și exporta către sistemele configurate. Astfel, aplicația nu trebuie să fie legată direct de fiecare instrument folosit pentru analiză.
Această abordare este deosebit de utilă atunci când compania folosește mai multe tehnologii, dezvoltă arhitectura sistemului sau dorește să păstreze posibilitatea schimbării furnizorului de instrumente. Totuși, standardul în sine nu asigură o observability completă. Sunt în continuare necesare o instrumentare corectă, o strategie bine gândită de colectare a datelor, dashboard-uri adecvate, alerte și proceduri de reacție. <Cite ref="turn154932search3"/>
Când merită implementată observability?
Observability poate fi utilă atât în sisteme distribuite mari, cât și în aplicații mai mici, în care o întrerupere sau o defecțiune greu de detectat are consecințe de business importante.
Merită luată în considerare această abordare mai ales atunci când:
- aplicația este alcătuită din mai multe servicii sau integrări,
- problemele apar neregulat și sunt greu de reprodus,
- utilizatorii raportează erori care nu sunt vizibile în testele standard,
- timpul de diagnosticare a incidentelor este prea lung,
- următoarele implementări provoacă efecte greu de prevăzut,
- compania dezvoltă sistemul și are nevoie de date pentru planificarea performanței,
- aplicația gestionează procese cheie de vânzări, operaționale sau financiare,
- echipa trebuie să înțeleagă mai bine impactul serviciilor externe asupra funcționării întregii soluții.
Acest lucru nu înseamnă însă că orice site web are nevoie de un mediu de telemetrie complex. Într-un serviciu mic și simplu, pot fi suficiente jurnalele de bază, monitorizarea disponibilității și câteva metrici cheie. Domeniul soluției ar trebui să corespundă complexității aplicației, scării traficului, cerințelor de fiabilitate și costurilor potențialelor întreruperi.
Când poate observability să fie o formă fără fond?
Implementarea unor instrumente complexe fără un scop clar definit poate aduce mai multe costuri decât beneficii.
Printre cele mai frecvente greșeli se numără:
- Colectarea a tot fără un plan. Excesul de date crește costurile și îngreunează găsirea informațiilor relevante pentru diagnostic.
- Lipsa întrebărilor la care sistemul trebuie să răspundă. Dashboardurile pot arăta impresionant, dar să nu ajute la rezolvarea problemelor reale.
- Alertarea la fiecare abatere. Prea multe notificări provoacă oboseală din cauza alertelor și cresc riscul de a rata un incident.
- Lipsa responsabilității pentru reacție. Chiar și o problemă bine detectată poate dura mult dacă nimeni nu știe cine ar trebui să se ocupe de ea.
- Lipsa protecției datelor. Telemetria poate conține informații sensibile, identificatori de utilizator sau date operaționale care necesită acces restricționat și retenție adecvată.
- Ignorarea costului instrumentării. Colectarea urmelor și a jurnalelor detaliate la scară mare poate afecta performanța aplicației și poate genera costuri semnificative de stocare și procesare.
- Tratarea instrumentului ca soluție gata făcută. Simpla instalare a platformei nu asigură o instrumentare corectă nici un proces eficient de diagnostic.
Observability necesită deci nu doar tehnologie, ci și decizii organizaționale: ce date sunt necesare, cine le analizează, cum reacționează echipa și în ce mod concluziile din incidente se traduc în schimbări în sistem.
Cum să planifici implementarea observability?
Cel mai sigur este să dezvolți observabilitatea etapizat, începând cu procesele și funcțiile a căror cădere are cel mai mare impact asupra utilizatorilor și companiei.
1. Identifică procesele de business cheie
Identifică cele mai importante operațiuni, cum ar fi autentificarea, plasarea comenzilor, plățile, generarea documentelor sau sincronizarea datelor. Acestea ar trebui să fie punctul de pornire pentru definirea a ceea ce înseamnă funcționarea corectă a aplicației.
2. Stabilește indicatorii de fiabilitate
Alege metrici care reflectă experiența utilizatorului, de exemplu disponibilitatea funcțiilor cheie, timpul de răspuns sau procentul operațiunilor finalizate cu succes. Pentru servicii importante se pot defini SLI (Service Level Indicator), adică indicatorul nivelului de serviciu, și SLO (Service Level Objective), adică obiectivul privind acest indicator.
3. Ai grijă de logurile structurate
Uniformizează formatul logurilor, nivelurile de importanță și atributele de bază. Ai grijă de identificatorii de corelare și de politica de ștergere sau mascarea datelor confidențiale. Logurile ar trebui să fie lizibile pentru echipă și să poată fi procesate de instrumente.
4. Adaugă tracing în căile critice
Începe cu procesele care implică mai multe servicii, baze de date sau integrări externe. Urmărește parcursul cererii prin sistem și ai grijă de propagarea contextului între componente.
5. Construiește dashboarduri în jurul unor întrebări concrete
În loc să creezi un singur panou uriaș, pregătește vizualizări care răspund nevoilor diferitelor roluri. Echipa tehnică poate avea nevoie de informații despre erori și întârzieri, iar proprietarul produsului - de date despre eficiența proceselor cheie și impactul defecțiunilor asupra utilizatorilor.
6. Proiectează alertele și procedurile de reacție
Stabilește praguri, priorități, persoane responsabile și instrucțiuni de acțiune. O alertă ar trebui să conțină contextul care ajută la începerea rapidă a diagnosticului, nu doar să informeze despre depășirea unei valori.
7. Testează observabilitatea
Verifică dacă echipa poate găsi cauza unei erori exemplu pe baza datelor disponibile. Se pot face teste controlate de avarie pe mediul de test sau exerciții de răspuns la incidente. Merită, de asemenea, verificat dacă alertele se declanșează atunci când ar trebui.
8. Dezvoltă soluția pe baza incidentelor
După fiecare problemă importantă merită verificat ce informații au fost disponibile, ce a lipsit și cum se poate îmbunătăți instrumentarea, alertarea sau procedurile. Observability nu este un proiect unic, ci un proces de perfecționare a cunoașterii funcționării sistemului.
Costuri și securitate - două aspecte care nu pot fi omise
Datele de telemetrie au un preț al lor. Costurile pot rezulta din instrumentare, transfer, indexare, stocare, retenție și analiză de date. În sistemele cu trafic mare, poate fi deosebit de costisitoare colectarea tuturor urmelor sau a jurnalelor foarte detaliate.
De aceea merită folosite retenția adaptată nevoilor, filtrarea datelor, eșantionarea urmelor (sampling) și diferite niveluri de detaliere în funcție de mediu. De exemplu, un sistem de producție poate colecta date complete pentru erori și pentru anumite operațiuni critice, iar o parte din cererile corecte pot fi eșantionate pentru a limita volumul.
La fel de importantă este protecția datelor. Jurnalele și urmele pot conține fără intenție date personale, identificatori de sesiune, fragmente de interogări sau informații despre structura infrastructurii. Trebuie limitat accesul la telemetrie, eliminate datele inutile, mascate informațiile confidențiale și controlate perioadele de păstrare. Merită, de asemenea, ca sistemele de observability să fie tratate ca parte a mediului de producție, care la rândul lui necesită protecții, copii de rezervă și controlul permisiunilor.
Observability ca instrument de management, nu doar de diagnostic
Deși observabilitatea este cel mai des asociată cu munca programatorilor, a echipelor DevOps și a administratorilor, valoarea ei depășește domeniul IT.
Datele despre timpul de răspuns, erori, disponibilitate și eficiența proceselor pot ajuta compania să înțeleagă care elemente ale tehnologiei susțin activitatea și care o limitează. Ele permit identificarea problemelor recurente, evaluarea efectelor schimbărilor și planificarea dezvoltării pe baza comportamentului real al sistemului.
Dacă, de exemplu, sistemul de comenzi încetinește regulat la anumite ore, datele de telemetrie pot ajuta la stabilirea dacă este nevoie de optimizarea interogărilor, de schimbarea modului de procesare a sarcinilor sau de extinderea infrastructurii. În loc să investească în resurse suplimentare pe baza intuiției, compania poate mai întâi să identifice blocajul real.
Observability sprijină, de asemenea, analiza efectelor implementărilor. Compararea metricilor, a trasărilor și a logurilor înainte și după schimbare permite detectarea mai rapidă a regresiilor și evaluarea dacă actualizarea a produs efectul așteptat.
Totuși, nu trebuie să confundăm observabilitatea cu luarea automată a deciziilor. Datele arată comportamentul sistemului, dar interpretarea lor necesită cunoașterea arhitecturii, a proceselor de business și a contextului incidentului concret.
Glosar de termeni
- Observability (observabilitate) - capacitatea de a înțelege comportamentul intern al sistemului pe baza datelor pe care le emite.
- Monitoring - urmărirea continuă a parametrilor selectați și detectarea stărilor definite care necesită atenție.
- Telemetry (telemetrie) - date colectate și transmise din aplicație și infrastructură în scopul analizării funcționării acestora.
- Logs (loguri) - înregistrări ale evenimentelor care au loc în aplicație sau infrastructură.
- Metrics (metrici) - măsurători numerice ale stării, performanței sau comportamentului sistemului în timp.
- Tracing - urmărirea desfășurării operațiilor prin componentele aplicației.
- Distributed tracing - urmărirea unei singure cereri într-un sistem alcătuit din mai multe servicii sau procese.
- Span - înregistrarea unei operațiuni individuale care face parte dintr-o trasă.
- Trace - un set de spanuri corelate care prezintă desfășurarea unei operațiuni.
- Alert - notificare privind o stare sau un eveniment detectat care necesită reacție.
- SLI - indicator care măsoară un aspect concret al funcționării serviciului.
- SLO - obiectiv stabilit pentru un indicator selectat de fiabilitate.
- Sampling - tehnică de limitare a numărului de date telemetrice colectate prin selectarea unei părți reprezentative a evenimentelor.
- OpenTelemetry - un set deschis de standarde și instrumente care sprijină instrumentarea și exportul datelor telemetrice.
Rezumat
O avarie a aplicației nu începe întotdeauna cu un server indisponibil sau cu un mesaj de eroare. Uneori sistemul funcționează formal, dar o funcție cheie devine prea lentă, o parte dintre tranzacții nu se finalizează cu succes sau integrarea eșuează doar în anumite condiții.
Monitoringul ajută la detectarea neregulilor. Observability permite înțelegerea a ceea ce a dus la apariția lor și care a fost impactul asupra funcționării aplicației. Logurile, metricile, tracingul și alertele bine concepute creează împreună baza pentru o diagnosticare mai eficientă, o dezvoltare conștientă și reducerea riscului operațional.
Nu este vorba despre a colecta cât mai multe date sau a crea cele mai complexe dashboarduri. Este vorba despre a nu întreba, în momentul apariției problemei, doar: „Funcționează sistemul?”, ci a putea stabili: „Ce anume s-a întâmplat exact în sistem, de ce și ce ar trebui să facem mai departe?”
O aplicație matură nu este doar una care funcționează. Este și una al cărei comportament poate fi înțeles, diagnosticat și îmbunătățit.
