paint-brush
Què és OpenTelemetry i com pot millorar la qualitat del vostre backend? per@ymatigoosa
39,154 lectures
39,154 lectures

Què és OpenTelemetry i com pot millorar la qualitat del vostre backend?

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

Massa Llarg; Per llegir

OpenTelemetry és un potent conjunt d'eines per supervisar i depurar sistemes backend moderns. Integra el seguiment, el registre i la recollida de mètriques, proporcionant una visió unificada del rendiment i la fiabilitat de l'aplicació. Aquesta guia explora la seva història, els conceptes clau i la implementació, la qual cosa la fa essencial per optimitzar els microserveis i els sistemes distribuïts.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Què és OpenTelemetry i com pot millorar la qualitat del vostre backend?
Dmitrii Pakhomov HackerNoon profile picture
0-item

En el passat, quan parlàvem del backend, normalment ens referim a una aplicació gran amb una base de dades única i gran, i el registre era suficient per a la supervisió. Ara, gràcies a tecnologies com Kubernetes , els microserveis s'han convertit en l'estàndard. Les aplicacions són més nombroses i distribuïdes, i el registre tradicional ja no és suficient per depurar i diagnosticar problemes a les nostres aplicacions.

Una solució excel·lent per organitzar la supervisió és OpenTelemetry, un conjunt d'eines modern que es pot utilitzar per a la depuració i l'anàlisi del rendiment de sistemes distribuïts.


Aquest article està pensat per als professionals informàtics que busquen ampliar els seus coneixements en optimització de backend. A continuació, detallarem què és OpenTelemetry, els seus conceptes clau i els problemes que ajuda a resoldre. Si esteu interessats en com OpenTelemetry pot canviar el vostre enfocament per supervisar i depurar sistemes de fons, millorant la seva fiabilitat i eficiència, continueu llegint.


Una breu història d'OpenTelemetry

Les grans empreses tecnològiques es van enfrontar per primera vegada al repte del registre i el rastreig distribuïts a finals dels anys 2000. El 2010, Google va publicar un article, Dapper, una infraestructura de seguiment de sistemes distribuïts a gran escala , que va establir les bases per a l'eina de rastreig de Twitter, Zipkin, llançada el 2012.


El 2014, va sorgir Kubernetes, que va simplificar significativament el desenvolupament de microserveis i altres sistemes distribuïts al núvol. Això va fer que moltes empreses tinguessin problemes amb el registre i el seguiment distribuïts als microserveis. Per estandarditzar el traçat distribuït, es va crear l'estàndard OpenTracing, adoptat per CNCF, i el projecte OpenCensus de Google.


El 2019, els projectes OpenTracing i OpenCensus van anunciar una fusió sota el nom d'OpenTelemetry. Aquesta plataforma combina les millors pràctiques acumulades durant molts anys, permetent una integració perfecta de traça, registre i mètriques en qualsevol sistema, independentment de la seva complexitat.


Avui dia, OpenTelemetry no és només un projecte; és un estàndard de la indústria per recopilar i transmetre dades de telemetria. Està desenvolupat i recolzat per una comunitat d'especialistes i empreses líders en el mercat com Google i Microsoft. El projecte continua evolucionant, guanyant noves capacitats per simplificar el procés d'integració i ús.


Què hi ha dins?

OpenTelemetry és un conjunt complet de pràctiques i eines que defineixen quins senyals pot generar una aplicació per interactuar amb el món exterior i com es poden recollir i visualitzar aquests senyals per supervisar l'estat de les aplicacions i del sistema en conjunt. Els tres tipus principals de senyals són el seguiment, el registre i la recollida de mètriques .


** Fem una ullada més de prop a cada component: \

Contextos

OpenTelemetry introdueix el concepte de contextos d'operació. Un context inclou principalment atributs com ara `trace_id` (identificador de l'operació actual) i `span_id` (identificador per a una subsol·licitud, amb cada reintent d'una subsol·licitud amb un `span_id` únic).


A més, un context pot contenir informació estàtica, com ara el nom del node on es desplega l'aplicació o el nom de l'entorn (prod/qa). Aquests camps, coneguts com a recursos en terminologia d'OpenTelemetry, s'adjunten a cada registre, mètrica o traça per facilitar la cerca. Els contextos també poden incloure dades dinàmiques, com l'identificador del punt final actual ( `http_path: "GET /user/:id/info"` ), que es poden adjuntar selectivament a grups de registres, mètriques o traces.


Els contextos d'OpenTelemetry es poden passar entre diferents aplicacions mitjançant protocols de propagació de context. Aquests protocols consisteixen en conjunts de capçaleres que s'afegeixen a cada sol·licitud HTTP o gRPC o a les capçaleres dels missatges de les cues. Això permet que les aplicacions posteriors reconstrueixin el context d'operació a partir d'aquestes capçaleres.


Aquests són alguns exemples de propagació de context:

  1. Propagació B3 Aquest és un conjunt de capçaleres ( x-b3-* ) desenvolupat originalment per al sistema de traça Zipkin. Va ser adaptat a OpenTracing i utilitzat per moltes eines i biblioteques. B3-Propagation porta trace_id / span_id i un indicador que indica si el mostreig és necessari.


  2. Context de seguiment del W3C Desenvolupat pel grup de treball del W3C, aquest estàndard unifica diversos enfocaments de propagació del context en un únic estàndard i és el predeterminat a OpenTelemetry. Un bon exemple d'aplicació d'aquests estàndards és el seguiment de l'execució d'una sol·licitud passant per microserveis implementats amb diferents tecnologies sense comprometre la precisió del monitoratge i depuració.

Traçat

El seguiment és el procés d'enregistrament i, posteriorment, de visualització de la línia de temps del camí d'una sol·licitud a través de diversos microserveis.


[font de la imatge: https://opentelemetry.io/docs/demo/screenshots/]


A la visualització, cada barra s'anomena "span" i té un "span_id" únic. L'abast de l'arrel es coneix com a "trace" i té un "trace_id" , que serveix com a identificador per a tota la sol·licitud.


Aquest tipus de visualització us permet:

  • Analitzeu el temps d'execució de les sol·licituds en diferents sistemes i bases de dades per identificar colls d'ampolla que necessiten optimització.
  • Detectar dependències cícliques entre serveis.
  • Cerca sol·licituds duplicades. Amb dades de traça, també podeu crear analítiques addicionals, com ara crear un mapa de microserveis o distribuir el temps entre diferents sistemes durant el processament de l'operació. Encara que no utilitzeu dades de traça per visualitzar línies de temps, OpenTelemetry encara genera trace_id i span_id per utilitzar-los en altres senyals.


Registres

Malgrat la seva aparent simplicitat, el registre segueix sent una de les eines més potents per diagnosticar problemes. OpenTelemetry millora el registre tradicional afegint informació contextual. Concretament, si hi ha una traça activa, els atributs `trace_id` i `span_id` s'afegeixen automàticament als registres, enllaçant-los a la línia de temps de la traça. A més, els atributs de registre poden incloure informació estàtica del context d'OpenTelemetry, com ara l'identificador del node, així com informació dinàmica, com l'identificador de punt final HTTP actual (`http_path: "GET /user/:id"`).


Mitjançant el `trace_id`, podeu trobar registres de tots els microserveis associats a la sol·licitud actual, mentre que `span_id` us permet diferenciar entre les sub-sol·licituds. Per exemple, en el cas de reintents, els registres de diferents intents tindran `span_id`s diferents. L'ús d'aquests identificadors permet una anàlisi ràpida del comportament de tot el sistema en temps real, accelerant el diagnòstic de problemes i millorant l'estabilitat i la fiabilitat.


Mètriques

La recopilació de mètriques proporciona dades quantitatives sobre el rendiment del sistema, com ara la latència, les taxes d'error, l'ús de recursos i molt més. El seguiment en temps real de les mètriques us permet respondre ràpidament als canvis de rendiment, evitar errors i esgotament de recursos i garantir una alta disponibilitat i fiabilitat de l'aplicació per als usuaris.


La integració amb sistemes d'emmagatzematge i visualització de mètriques com Prometheus i Grafana facilita la visualització d'aquestes dades, simplificant significativament la supervisió.


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


Col·lectors mètrics

Els col·lectors de mètriques OpenTelemetry són compatibles amb els estàndards de Prometheus i OpenMetrics, la qual cosa permet una transició fàcil a les solucions OpenTelemetry sense canvis significatius. L'SDK d'OpenTelemetry permet exportar exemples de trace_id juntament amb mètriques, cosa que permet correlacionar mètriques amb exemples de registre i traces.


Correlació de senyals

En conjunt, els registres, les mètriques i el seguiment creen una visió completa de l'estat del sistema:

  • Els registres proporcionen informació sobre els esdeveniments del sistema, permetent una ràpida identificació i resolució d'errors.
  • Les mètriques reflecteixen indicadors de rendiment qualitatius i quantitatius del sistema, com ara els temps de resposta o les taxes d'error.
  • El seguiment complementa aquesta visió mostrant el camí d'execució de la sol·licitud a través de diversos components del sistema, ajudant a entendre les seves interrelacions. La clara correlació entre registres, traces i mètriques és una característica distintiva d'OpenTelemetry. Per exemple, Grafana permet als usuaris veure el seguiment corresponent i les mètriques de sol·licitud quan visualitzen un registre, millorant enormement la usabilitat i l'eficiència de la plataforma.



[font de la imatge: https://grafana.com/blog/2020/03/31/how-to-successfully-correlate-metrics-logs-and-traces-in-grafana/]


A més dels tres components bàsics, OpenTelemetry inclou els conceptes de mostreig, equipatge i gestió del context operatiu.


Mostreig

En sistemes d'alta càrrega, el volum de registres i traces es fa enorme, i requereixen recursos substancials per a la infraestructura i l'emmagatzematge de dades. Per solucionar aquest problema, els estàndards d'OpenTelemetry inclouen el mostreig del senyal: la capacitat d'exportar només una part de les traces i els registres. Per exemple, podeu exportar senyals detallats d'un percentatge de sol·licituds, sol·licituds de llarga durada o sol·licituds d'error. Aquest enfocament permet un mostreig suficient per generar estadístiques i estalviar recursos significatius.


Tanmateix, si cada sistema decideix de manera independent quines sol·licituds monitoritzar amb detall, acabem amb una visió fragmentada de cada sol·licitud. Alguns sistemes poden exportar dades detallades, mentre que d'altres només poden exportar parcialment o no exportar-ne en absolut.


Per resoldre aquest problema, els mecanismes de propagació de context d'OpenTelemetry transmeten un indicador de mostreig juntament amb el `trace_id`/`span_id`. Això garanteix que si el servei inicial que rep la sol·licitud de l'usuari decideix que la sol·licitud s'ha de supervisar en detall, tots els altres sistemes seguiran el mateix. En cas contrari, tots els sistemes haurien d'exportar parcialment o no els senyals per conservar els recursos. Aquest enfocament s'anomena "Mostreig del cap": una decisió presa al començament del processament de la sol·licitud, ja sigui aleatòriament o en funció d'alguns atributs d'entrada.


A més, OpenTelemetry admet "Tail Sampling", on totes les aplicacions sempre exporten tots els senyals amb detall, però existeix un buffer intermedi. Després de recollir totes les dades, aquest buffer decideix si conserva les dades completes o només una mostra parcial. Aquest mètode permet obtenir una mostra més representativa de cada categoria de sol·licitud (èxit/llarga/error), però requereix una configuració d'infraestructura addicional.


Equipatge

El mecanisme Baggage permet transmetre parells clau-valor arbitraris juntament amb trace_id / span_id , passant automàticament entre tots els microserveis durant el processament de la sol·licitud. Això és útil per transmetre informació addicional necessària al llarg del camí de la sol·licitud, com ara la informació de l'usuari o la configuració de l'entorn d'execució.

Exemple de capçalera per transmetre equipatge segons l'estàndard W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Aquests són alguns exemples d'ús de l'equipatge:

  • Passar informació de context empresarial com ara userId , productId o deviceId es pot passar a través de tots els microserveis. Les aplicacions poden registrar automàticament aquesta informació, permetent cerques de registre per context d'usuari per a la sol·licitud original.

  • Paràmetres de configuració específics Configuració per a SDK o infraestructura.

  • Senyals d'encaminament Senyals que ajuden els equilibradors de càrrega a prendre decisions d'encaminament. Durant les proves, és possible que algunes sol·licituds s'hagin d'enviar a backends simulats. Com que l'equipatge es transmet automàticament a través de tots els serveis, no cal crear protocols addicionals; només cal que configureu una regla a l'equilibrador de càrrega.


Tingueu en compte que, tot i que l'impacte sobre el rendiment de l'equipatge és mínim, l'ús excessiu pot augmentar significativament la càrrega de la xarxa i del servei. Trieu amb cura quines dades realment necessiteu passar per Equipatge per evitar problemes de rendiment.

Implementació d'infraestructures

La implementació d'OpenTelemetry a nivell d'infraestructura implica integrar els backends d'OpenTelemetry a l'arquitectura de l'aplicació i configurar la infraestructura per a l'agregació de dades.


El procés consta de quatre etapes:


  1. Integració d'aplicacions En la primera etapa, els SDK d'OpenTelemetry s'integren directament a les aplicacions per recopilar mètriques, registres i traces, garantint un flux continu de dades sobre el rendiment de cada component del sistema.


  2. Configuració d'exportadors Les dades recollides s'encaminen des de les aplicacions a través dels exportadors a sistemes externs per a un processament posterior, com ara sistemes de registre, seguiment, seguiment o anàlisi, en funció de les vostres necessitats.


  3. Agregació i emmagatzematge Aquesta etapa pot implicar normalitzar les dades, enriquir-les amb informació addicional i combinar dades de diferents fonts per crear una visió unificada de l'estat del sistema.


  4. Visualització de dades Finalment, les dades processades es presenten com a quadres de comandament en sistemes com Grafana (per a mètriques i traces) o Kibana (per a registres). Això permet als equips avaluar ràpidament la salut del sistema, identificar problemes i tendències i configurar alertes basades en els senyals generats.


Implementació de l'aplicació

Per integrar-se amb una aplicació, heu de connectar l'SDK d'OpenTelemetry adequat per al llenguatge de programació en ús o utilitzar biblioteques i marcs que admetin directament l'OpenTelemetry. OpenTelemetry sovint implementa interfícies àmpliament utilitzades de biblioteques conegudes, permetent substitucions directes. Per exemple, la biblioteca Micrometer s'utilitza habitualment per a la recollida de mètriques a l'ecosistema Java. L'SDK d'OpenTelemetry ofereix les seves implementacions d'interfícies Micrometer, que permeten l'exportació de mètriques sense canviar el codi de l'aplicació principal. A més, OpenTelemetry ofereix implementacions de les interfícies OpenTracing i OpenCensus més antigues, facilitant una migració fluida a OpenTelemetry.

Conclusió

En els sistemes informàtics, OpenTelemetry pot esdevenir la clau per al futur de backends fiables i eficients. Aquesta eina simplifica la depuració i la supervisió i també obre oportunitats per a una comprensió profunda del rendiment i l'optimització de les aplicacions a un nou nivell. Uneix-te a la comunitat OpenTelemetry per ajudar a donar forma a un futur on el desenvolupament de backend sigui més senzill i eficaç!