![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
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.
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,
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.
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: \
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:
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.
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ó.
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 "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:
trace_id
i span_id
per utilitzar-los en altres senyals.
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.
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ó.
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.
En conjunt, els registres, les mètriques i el seguiment creen una visió completa de l'estat del sistema:
A més dels tres components bàsics, OpenTelemetry inclou els conceptes de mostreig, equipatge i gestió del context operatiu.
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.
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.
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:
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.
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.
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.
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.
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.
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ç!