paint-brush
Ce este OpenTelemetry și cum vă poate îmbunătăți calitatea backend-ului? de@ymatigoosa
39,154 lecturi
39,154 lecturi

Ce este OpenTelemetry și cum vă poate îmbunătăți calitatea backend-ului?

de Dmitrii Pakhomov8m2024/06/19
Read on Terminal Reader
Read this story w/o Javascript

Prea lung; A citi

OpenTelemetry este un set de instrumente puternic pentru monitorizarea și depanarea sistemelor backend moderne. Acesta integrează urmărirea, înregistrarea în jurnal și colectarea de valori, oferind o vedere unificată a performanței și fiabilității aplicației. Acest ghid explorează istoria, conceptele cheie și implementarea acestuia, făcându-l esențial pentru optimizarea microserviciilor și sistemelor distribuite.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Ce este OpenTelemetry și cum vă poate îmbunătăți calitatea backend-ului?
Dmitrii Pakhomov HackerNoon profile picture
0-item

În trecut, când vorbeam despre backend, de obicei ne referim la o aplicație mare cu o singură bază de date mare, iar înregistrarea era suficientă pentru monitorizare. Acum, datorită tehnologiilor precum Kubernetes , microserviciile au devenit standardul. Aplicațiile sunt mai numeroase și mai distribuite, iar înregistrarea tradițională nu mai este suficientă pentru depanarea și diagnosticarea problemelor din aplicațiile noastre.

O soluție excelentă pentru organizarea monitorizării este OpenTelemetry — un set de instrumente modern care poate fi utilizat pentru depanarea și analiza performanței sistemelor distribuite.


Acest articol este destinat profesioniștilor IT care doresc să-și extindă cunoștințele în optimizarea backend. Mai jos, vom detalia ce este OpenTelemetry, conceptele sale cheie și problemele pe care le ajută să le rezolve. Dacă sunteți interesat de modul în care OpenTelemetry vă poate schimba abordarea pentru monitorizarea și depanarea sistemelor backend, sporind fiabilitatea și eficiența acestora, citiți mai departe.


O scurtă istorie a OpenTelemetry

Marile companii tehnologice s-au confruntat pentru prima dată cu provocarea logării și urmăririi distribuite la sfârșitul anilor 2000. În 2010, Google a publicat o lucrare, Dapper, o infrastructură de urmărire a sistemelor distribuite la scară largă , care a pus bazele instrumentului de urmărire al Twitter, Zipkin, lansat în 2012.


În 2014, a apărut Kubernetes, simplificând semnificativ dezvoltarea microserviciilor și a altor sisteme distribuite în cloud. Acest lucru a dus la multe companii să întâmpine probleme cu înregistrarea distribuită și urmărirea în microservicii. Pentru a standardiza urmărirea distribuită, a fost creat standardul OpenTracing, adoptat de CNCF, și proiectul Google OpenCensus.


În 2019, proiectele OpenTracing și OpenCensus au anunțat o fuziune sub numele OpenTelemetry. Această platformă combină cele mai bune practici acumulate de-a lungul mai multor ani, permițând integrarea perfectă a urmăririi, înregistrării și a valorilor în orice sistem, indiferent de complexitatea acestora.


Astăzi, OpenTelemetry nu este doar un proiect; este un standard industrial pentru colectarea și transmiterea datelor de telemetrie. Este dezvoltat și susținut de o comunitate de specialiști și companii lideri pe piață precum Google și Microsoft. Proiectul continuă să evolueze, dobândind noi capabilități pentru a simplifica procesul de integrare și utilizare.


Ce este înăuntru?

OpenTelemetry este un set cuprinzător de practici și instrumente care definesc ce semnale poate genera o aplicație pentru a interacționa cu lumea exterioară și modul în care aceste semnale pot fi colectate și vizualizate pentru a monitoriza starea aplicațiilor și a sistemului în ansamblu. Cele trei tipuri principale de semnale sunt urmărirea, înregistrarea în jurnal și colectarea de valori .


**Să aruncăm o privire mai atentă la fiecare componentă: \

Contexte

OpenTelemetry introduce conceptul de contexte de operare. Un context include în primul rând atribute precum `trace_id` (identificator pentru operația curentă) și `span_id` (identificator pentru o sub-cerere, fiecare reîncercare a unei sub-cereri având un `span_id` unic).


În plus, un context poate conține informații statice, cum ar fi numele nodului în care este implementată aplicația sau numele mediului (prod/qa). Aceste câmpuri, cunoscute ca resurse în terminologia OpenTelemetry, sunt atașate la fiecare jurnal, metrică sau urmă pentru o căutare mai ușoară. Contextele pot include, de asemenea, date dinamice, cum ar fi identificatorul punctului final curent ( `http_path: "GET /user/:id/info"` ), care pot fi atașate selectiv la grupuri de jurnale, valori sau urme.


Contextele OpenTelemetry pot fi transmise între diferite aplicații folosind protocoale de propagare a contextului. Aceste protocoale constau din seturi de anteturi care sunt adăugate la fiecare solicitare HTTP sau gRPC sau antete ale mesajelor pentru cozi. Acest lucru permite aplicațiilor din aval să reconstruiască contextul de operare din aceste anteturi.


Iată câteva exemple de propagare a contextului:

  1. B3-Propagation Acesta este un set de anteturi ( x-b3-* ) dezvoltat inițial pentru sistemul de urmărire Zipkin. A fost adaptat în OpenTracing și folosit de multe instrumente și biblioteci. B3-Propagation poartă trace_id / span_id și un indicator care indică dacă eșantionarea este necesară.


  2. Contextul de urmărire W3C Dezvoltat de grupul de lucru W3C, acest standard unifică diverse abordări de propagare a contextului într-un singur standard și este implicit în OpenTelemetry. Un bun exemplu de aplicare a acestor standarde este urmărirea execuției unei cereri care trece prin microservicii implementate cu tehnologii diferite, fără a compromite acuratețea monitorizării și depanării.

Urmărirea

Urmărirea este procesul de înregistrare și, ulterior, de vizualizare a cronologiei căii unei cereri prin mai multe microservicii.


[sursa imagine: https://opentelemetry.io/docs/demo/screenshots/]


În vizualizare, fiecare bară este numită „span” și are un „span_id” unic. Spațiul rădăcină este denumit „urmă” și are un „id-urmă” , care servește ca identificator pentru întreaga solicitare.


Acest tip de vizualizare vă permite să:

  • Analizați timpul de execuție al solicitărilor în diferite sisteme și baze de date pentru a identifica blocajele care necesită optimizare.
  • Detectează dependențe ciclice între servicii.
  • Găsiți cereri duplicate. Folosind datele de urmărire, puteți construi și analize suplimentare, cum ar fi crearea unei hărți de microservicii sau distribuirea timpului pe diferite sisteme în timpul procesării operațiunii. Chiar dacă nu utilizați datele de urmărire pentru a vizualiza cronologie, OpenTelemetry generează în continuare trace_id și span_id pentru a fi utilizate în alte semnale.


Bușteni

În ciuda simplității sale aparente, înregistrarea în jurnal rămâne unul dintre cele mai puternice instrumente pentru diagnosticarea problemelor. OpenTelemetry îmbunătățește înregistrarea tradițională prin adăugarea de informații contextuale. Mai exact, dacă este prezentă o urmă activă, atributele `trace_id` și `span_id` sunt adăugate automat la jurnalele, legându-le la cronologia urmăririi. Mai mult, atributele de jurnal pot include informații statice din contextul OpenTelemetry, cum ar fi identificatorul de nod, precum și informații dinamice, cum ar fi identificatorul curent al punctului final HTTP (`http_path: "GET /user/:id"`).


Folosind `trace_id`, puteți găsi jurnalele de la toate microserviciile asociate cu cererea curentă, în timp ce `span_id` vă permite să faceți diferența între sub-cereri. De exemplu, în cazul reîncercărilor, jurnalele de la diferite încercări vor avea `span_id`s diferite. Utilizarea acestor identificatori permite analiza rapidă a comportamentului întregului sistem în timp real, accelerând diagnosticarea problemelor și sporind stabilitatea și fiabilitatea.


Metrici

Colectarea de valori oferă date cantitative despre performanța sistemului, cum ar fi latența, ratele de eroare, utilizarea resurselor și multe altele. Monitorizarea în timp real a valorilor vă permite să răspundeți prompt la schimbările de performanță, să preveniți eșecurile și epuizarea resurselor și să asigurați disponibilitatea și fiabilitatea ridicate a aplicației pentru utilizatori.


Integrarea cu sisteme metrice de stocare și vizualizare precum Prometheus și Grafana facilitează vizualizarea acestor date, simplificând semnificativ monitorizarea.


[sursa imagine: https://grafana.com/blog/2021/06/22/grafana-dashboard-showcase-visualizations-for-prometheus-home-energy-usage-github-and-more/]


Colectori metrici

Colectorii de metrici OpenTelemetry sunt compatibili cu standardele Prometheus și OpenMetrics, permițând o tranziție ușoară la soluțiile OpenTelemetry fără modificări semnificative. OpenTelemetry SDK permite ca exemplele trace_id să fie exportate împreună cu valorile, făcând posibilă corelarea valorilor cu exemplele de jurnal și urmele.


Corelația semnalului

Împreună, jurnalele, valorile și urmărirea creează o vedere cuprinzătoare a stării sistemului:

  • Jurnalele oferă informații despre evenimentele din sistem, permițând identificarea și rezolvarea rapidă a erorilor.
  • Metricurile reflectă indicatorii de performanță calitativi și cantitativi ai sistemului, cum ar fi timpii de răspuns sau ratele de eroare.
  • Urmărirea completează această vedere arătând calea de execuție a cererii prin diferite componente ale sistemului, ajutând la înțelegerea interrelațiilor dintre acestea. Corelația clară dintre jurnalele, urmele și valorile este o caracteristică distinctivă a OpenTelemetry. De exemplu, Grafana permite utilizatorilor să vadă urmările corespunzătoare și valorile de solicitare atunci când vizualizează un jurnal, îmbunătățind considerabil utilitatea și eficiența platformei.



[sursa imagine: https://grafana.com/blog/2020/03/31/how-to-successfully-correlate-metrics-logs-and-traces-in-grafana/]


Pe lângă cele trei componente de bază, OpenTelemetry include conceptele de eșantionare, bagaje și managementul contextului operațional.


Prelevarea de probe

În sistemele cu încărcare mare, volumul jurnalelor și urmelor devine enorm, necesitând resurse substanțiale pentru infrastructură și stocarea datelor. Pentru a rezolva această problemă, standardele OpenTelemetry includ eșantionarea semnalului - capacitatea de a exporta doar o parte a urmelor și a jurnalelor. De exemplu, puteți exporta semnale detaliate dintr-un procent de solicitări, solicitări de lungă durată sau solicitări de eroare. Această abordare permite o eșantionare suficientă pentru a construi statistici, economisind în același timp resurse semnificative.


Cu toate acestea, dacă fiecare sistem decide în mod independent ce solicitări să monitorizeze în detaliu, ajungem la o vizualizare fragmentată a fiecărei cereri. Unele sisteme pot exporta date detaliate, în timp ce altele pot exporta doar parțial sau nu pot exporta deloc.


Pentru a rezolva această problemă, mecanismele de propagare a contextului OpenTelemetry transmit un flag de eșantionare împreună cu `trace_id`/`span_id`. Acest lucru asigură că, dacă serviciul inițial care primește cererea utilizatorului decide că cererea trebuie monitorizată în detaliu, toate celelalte sisteme vor urma exemplul. În caz contrar, toate sistemele ar trebui să exporte parțial sau nu semnale pentru a conserva resursele. Această abordare se numește „Eșantionarea capului” — o decizie luată la începutul procesării cererii, fie aleatoriu, fie pe baza unor atribute de intrare.


În plus, OpenTelemetry acceptă „Tail Sampling”, unde toate aplicațiile exportă întotdeauna toate semnalele în detaliu, dar există un buffer intermediar. După colectarea tuturor datelor, acest buffer decide dacă păstrează datele complete sau păstrează doar o probă parțială. Această metodă permite un eșantion mai reprezentativ pentru fiecare categorie de solicitare (reușit/prelungit/eroare), dar necesită o configurare suplimentară a infrastructurii.


Bagaj

Mecanismul Baggage permite ca perechile cheie-valoare arbitrare să fie transmise împreună cu trace_id / span_id , trecând automat între toate microserviciile în timpul procesării cererii. Acest lucru este util pentru transmiterea informațiilor suplimentare necesare pe parcursul căii de solicitare, cum ar fi informații despre utilizator sau setările mediului de rulare.

Exemplu de antet pentru transmiterea bagajelor conform standardului W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Iată câteva exemple de utilizare a bagajelor:

  • Transmiterea de informații despre contextul afacerii, cum ar fi userId , productId sau deviceId pot fi transmise prin toate microserviciile. Aplicațiile pot înregistra automat aceste informații, permițând căutări în jurnal în funcție de contextul utilizatorului pentru cererea inițială.

  • Parametri de configurare specifici Setări pentru SDK-uri sau infrastructură.

  • Indicatori de rutare Indicatori care ajută echilibratorii de încărcare să ia decizii de rutare. În timpul testării, este posibil ca unele solicitări să fie direcționate către backend-uri simulate. Deoarece bagajele sunt transmise automat prin toate serviciile, nu este nevoie să creați protocoale suplimentare - trebuie doar să configurați o regulă pentru echilibrarea încărcăturii.


Rețineți că, deși impactul asupra performanței Bagajului este minim, utilizarea excesivă poate crește semnificativ încărcarea rețelei și a serviciilor. Alegeți cu atenție ce date trebuie să treceți prin Bagage pentru a evita problemele de performanță.

Implementarea infrastructurii

Implementarea OpenTelemetry la nivel de infrastructură implică integrarea backend-urilor OpenTelemetry în arhitectura aplicației și configurarea infrastructurii pentru agregarea datelor.


Procesul constă din patru etape:


  1. Integrarea aplicațiilor În prima etapă, SDK-urile OpenTelemetry sunt integrate direct în aplicații pentru a colecta valori, jurnale și urme, asigurând un flux continuu de date despre performanța fiecărei componente ale sistemului.


  2. Configurarea exportatorilor Datele colectate sunt direcționate de la aplicații prin exportatori către sisteme externe pentru procesare ulterioară, cum ar fi sisteme de înregistrare, monitorizare, urmărire sau analiză, în funcție de nevoile dvs.


  3. Agregarea și stocarea Această etapă poate implica normalizarea datelor, îmbogățirea acestora cu informații suplimentare și îmbinarea datelor din diferite surse pentru a crea o vedere unificată a stării sistemului.


  4. Vizualizarea datelor În cele din urmă, datele procesate sunt prezentate ca tablouri de bord în sisteme precum Grafana (pentru metrici și urme) sau Kibana (pentru jurnalele). Acest lucru permite echipelor să evalueze rapid starea de sănătate a sistemului, să identifice probleme și tendințe și să configureze alerte pe baza semnalelor generate.


Implementarea aplicației

Pentru a integra cu o aplicație, trebuie să conectați SDK-ul OpenTelemetry corespunzător pentru limbajul de programare utilizat sau să utilizați biblioteci și cadre care acceptă direct OpenTelemetry. OpenTelemetry implementează adesea interfețe utilizate pe scară largă din biblioteci cunoscute, permițând înlocuiri directe. De exemplu, biblioteca Micrometer este folosită în mod obișnuit pentru colectarea de valori în ecosistemul Java. SDK-ul OpenTelemetry oferă implementările sale ale interfețelor Micrometer, permițând exportul de metrici fără a modifica codul principal al aplicației. Mai mult, OpenTelemetry oferă implementări ale interfețelor OpenTracing și OpenCensus mai vechi, facilitând o migrare lină la OpenTelemetry.

Concluzie

În sistemele IT, OpenTelemetry poate deveni cheia pentru viitorul backend-urilor fiabile și eficiente. Acest instrument simplifică depanarea și monitorizarea și, de asemenea, deschide oportunități pentru o înțelegere profundă a performanței aplicației și a optimizării la un nou nivel. Alăturați-vă comunității OpenTelemetry pentru a ajuta la formarea unui viitor în care dezvoltarea backend este mai simplă și mai eficientă!