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   ,   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   i diagnosticar problemes a les nostres aplicacions. Kubernetes els microserveis depurar  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,  , que va establir les bases per a l'eina de rastreig de Twitter, Zipkin, llançada el 2012.   Dapper, una infraestructura de seguiment de sistemes distribuïts a gran escala  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   i   . el seguiment, el registre 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   (identificador de l'operació actual) i   (identificador per a una subsol·licitud, amb cada reintent d'una subsol·licitud amb un   únic). `trace_id` `span_id` `span_id`  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 (   ), que es poden adjuntar selectivament a grups de registres, mètriques o traces. `http_path: "GET /user/:id/info"`  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:    Aquest és un conjunt de capçaleres (   ) desenvolupat originalment per al sistema de traça Zipkin. Va ser adaptat a OpenTracing i utilitzat per moltes eines i biblioteques. B3-Propagation porta   /   i un indicador que indica si el mostreig és necessari. Propagació B3 x-b3-* trace_id span_id    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ó. Context de seguiment del W3C   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.  A la visualització, cada barra s'anomena "span" i té un   únic. L'abast de l'arrel es coneix com a   i té un   , que serveix com a identificador per a tota la sol·licitud. "span_id" "trace" "trace_id"   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   i   per utilitzar-los en altres senyals. trace_id span_id   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ó.   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.   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   /   , 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ó. trace_id span_id     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:    com ara   ,   o   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. Passar informació de context empresarial userId productId deviceId    Configuració per a SDK o infraestructura. Paràmetres de configuració específics    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. Senyals d'encaminament  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:    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. Integració d'aplicacions    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. Configuració d'exportadors    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. Agregació i emmagatzematge    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. Visualització de dades  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ç!

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

Aquest àudio és produït a l'idioma original de la història!

Massa Llarg; Per llegir

Make resilience your competitive advantage

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

About Author

COMENTARIS

Etiquetes penjant

AQUEST ARTICLE VA SER PRESENTAT A

Related Stories

Startups of The Year: Meet the Education Industry

Startups of The Year: Meet the Commerce Industry

Your Next Viral Article Is a Google Trend Away

Startups of The Year: Meet the AI Industry

Startups of The Year: Meet the Education Industry

Startups of The Year: Meet the Commerce Industry

Your Next Viral Article Is a Google Trend Away

Startups of The Year: Meet the AI Industry

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps