Î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   ,   au devenit standardul. Aplicațiile sunt mai numeroase și mai distribuite, iar înregistrarea tradițională nu mai este suficientă pentru   și diagnosticarea problemelor din aplicațiile noastre. Kubernetes microserviciile depanarea  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,  , care a pus bazele instrumentului de urmărire al Twitter, Zipkin, lansat în 2012.   Dapper, o infrastructură de urmărire a sistemelor distribuite la scară largă  Î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   și   . urmărirea, înregistrarea în jurnal 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   (identificator pentru operația curentă) și   (identificator pentru o sub-cerere, fiecare reîncercare a unei sub-cereri având un   unic). `trace_id` `span_id` `span_id`  Î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 (   ), care pot fi atașate selectiv la grupuri de jurnale, valori sau urme. `http_path: "GET /user/:id/info"`  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:    Acesta este un set de anteturi (   ) dezvoltat inițial pentru sistemul de urmărire Zipkin. A fost adaptat în OpenTracing și folosit de multe instrumente și biblioteci. B3-Propagation poartă   /   și un indicator care indică dacă eșantionarea este necesară. B3-Propagation x-b3-* trace_id span_id    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. Contextul de urmărire W3C   Urmărirea     Urmărirea este procesul de înregistrare și, ulterior, de vizualizare a cronologiei căii unei cereri prin mai multe microservicii.  În vizualizare, fiecare bară este numită „span” și are un   unic. Spațiul rădăcină este denumit   și are un   , care servește ca identificator pentru întreaga solicitare. „span_id” „urmă” „id-urmă”   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   și   pentru a fi utilizate în alte semnale. trace_id span_id   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.   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.   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   /   , 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. trace_id span_id     Exemplu de antet pentru transmiterea bagajelor conform standardului W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5   Iată câteva exemple de utilizare a bagajelor:    cum ar fi   ,   sau   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ă. Transmiterea de informații despre contextul afacerii, userId productId deviceId    Setări pentru SDK-uri sau infrastructură. Parametri de configurare specifici    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. Indicatori de rutare  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:    Î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. Integrarea aplicațiilor    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. Configurarea exportatorilor    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. Agregarea și stocarea    Î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. Vizualizarea datelor  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ă!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Even

Google

Microsoft

Real

reflect

Trace

Read My Stories

Acest audio este produs în limba originală a poveștii!

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

About Author

COMENTARII

Etichete suspendate

ACEST ARTICOL A FOST PREZENTAT IN

Related Stories

Intel Stuns Employees By Cutting Free Office Fruit (And Staff)

Holy 🎅 HackerNoon's Web 2.5 Documentary is Out! 😮

Elon Just Made Gambling Define the News - And It's More Honest Than Journalism Ever Was

How Soon Can Google Investors Make Bank?

Intel Stuns Employees By Cutting Free Office Fruit (And Staff)

Holy 🎅 HackerNoon's Web 2.5 Documentary is Out! 😮

Elon Just Made Gambling Define the News - And It's More Honest Than Journalism Ever Was

How Soon Can Google Investors Make Bank?

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps