Nota. transl.: L'autora d'aquest material és Cindy Sridharan, una enginyera d'imgix especialitzada en desenvolupament d'API i, en particular, proves de microserveis. En aquest material, comparteix la seva visió detallada dels problemes actuals en l'àmbit del traçat distribuït, on, segons la seva opinió, hi ha una manca d'eines realment efectives per resoldre problemes urgents.
[Il·lustració extreta de sobre el traçat distribuït.]
Es creu que els difícil d'implementar, i el seu retorn . Hi ha moltes raons per les quals el rastreig és problemàtic, sovint citant la mà d'obra implicada en la configuració de cada component del sistema per transmetre les capçaleres adequades amb cada sol·licitud. Tot i que aquest problema existeix, no és de cap manera insuperable. Per cert, no explica per què als desenvolupadors no els agrada molt el rastreig (fins i tot quan ja està funcionant).
El principal repte del traçat distribuït no és recollir dades, estandarditzar formats per distribuir i presentar resultats, o determinar quan, on i com fer mostres. No estic intentant imaginar-me trivial aquests "problemes de comprensibilitat" són, de fet, força importants tècnics i (si estem considerant veritablement el codi obert) ) reptes polítics que cal superar per tal que aquests problemes es considerin resolts.
Tanmateix, si ens imaginem que tots aquests problemes estan resolts, hi ha una alta probabilitat que res canviï significativament pel que fa a experiència d'usuari final. És possible que el rastreig encara no sigui d'utilitat pràctica en els escenaris de depuració més habituals, fins i tot després que s'hagi desplegat.
Un rastre tan diferent
El seguiment distribuït inclou diversos components diferents:
- equipar aplicacions i middleware amb eines de control;
- transferència de context distribuït;
- recollida de rastres;
- emmagatzematge de rastres;
- la seva extracció i visualització.
Es parla molt sobre el traçat distribuït tendeix a tractar-lo com una mena d'operació unària l'únic objectiu de la qual és ajudar a diagnosticar completament el sistema. Això es deu en gran part a com s'han format històricament les idees sobre el traçat distribuït. EN , fet quan es van obrir les fonts Zipkin, es va esmentar que [Zipkin] fa que Twitter sigui més ràpid. També es van promocionar les primeres ofertes comercials per al rastreig .
Nota. transl.: Per fer més fàcil la comprensió del text, anem a definir dos termes bàsics segons :
- Lapse — l'element bàsic del traçat distribuït. És una descripció d'un determinat flux de treball (per exemple, una consulta de base de dades) amb un nom, hores d'inici i finalització, etiquetes, registres i context.
- Normalment, els trams contenen enllaços a altres trams, la qual cosa permet combinar diversos trams Traça — visualització de la vida d'una sol·licitud a mesura que es mou a través d'un sistema distribuït.
Les traces contenen dades increïblement valuoses que poden ajudar amb tasques com ara proves de producció, proves de recuperació de desastres, proves d'injecció d'errors, etc. De fet, algunes empreses ja utilitzen el rastreig amb finalitats similars. Comencem per té altres usos a més de simplement moure espais al sistema d'emmagatzematge:
- Per exemple, Uber traçar els resultats per diferenciar entre el trànsit de prova i el trànsit de producció.
- Facebook dades de traça per a l'anàlisi de camins crítics i per a la commutació de trànsit durant les proves regulars de recuperació de desastres.
- També xarxa social Llibres de notes Jupyter que permeten als desenvolupadors executar consultes arbitràries sobre resultats de traça.
- Seguidors (Injecció de fallada impulsada pel llinatge) traces distribuïdes per a proves amb injecció d'errors.
Cap de les opcions enumerades anteriorment s'aplica completament a l'escenari depuració, durant el qual l'enginyer intenta resoldre el problema mirant el rastre.
Quan vé encara arriba a l'script de depuració, la interfície principal continua sent el diagrama traça vista (encara que alguns també en diuen "Diagrama de Gantt" o "diagrama de cascada"). Sota traça vista я tots els trams i metadades que l'acompanyen que conjuntament conformen el rastre. Tots els sistemes de traça de codi obert, així com totes les solucions de traça comercials, ofereixen un traça vista interfície d'usuari per visualitzar, detallar i filtrar traces.
El problema amb tots els sistemes de traça que he vist fins ara és que el resultat visualització (traceview) reflecteix gairebé completament les característiques del procés de generació de traces. Fins i tot quan es proposen visualitzacions alternatives: mapes de calor, topologies de servei, histogrames de latència, en última instància, es redueixen a traça vista.
En el passat jo que la majoria de les "innovacions" en el seguiment d'UI/UX semblen estar limitades metadades addicionals en traça, invertint-hi informació amb alta cardinalitat (alta cardinalitat) o proporcionar la possibilitat d'aprofundir en intervals específics o executar consultes inter i intratraça... On traça vista segueix sent la principal eina de visualització. Mentre aquest estat de coses continuï, el traçat distribuït ocuparà (en el millor dels casos) el 4t lloc com a eina de depuració, després de mètriques, registres i rastres de pila, i en el pitjor dels casos serà una pèrdua de temps i diners.
Problema amb traceview
Propòsit traça vista — proporcionar una imatge completa del moviment d'una sol·licitud única en tots els components del sistema distribuït amb el qual està relacionada. Alguns sistemes de traça més avançats us permeten profunditzar en trams individuals i veure un desglossament al llarg del temps dins un procés (quan els trams tenen límits funcionals).
La premissa bàsica de l'arquitectura de microserveis és la idea que l'estructura organitzativa creix amb les necessitats de l'empresa. Els defensors dels microserveis argumenten que distribuir diverses tasques empresarials en serveis individuals permet als equips de desenvolupament petits i autònoms controlar tot el cicle de vida d'aquests serveis, donant-los la possibilitat de construir, provar i desplegar aquests serveis de manera independent. Tanmateix, l'inconvenient d'aquesta distribució és la pèrdua d'informació sobre com cada servei interactua amb els altres. En aquestes condicions, el rastreig distribuït afirma ser una eina indispensable depuració interaccions complexes entre serveis.
Si realment , aleshores ni una sola persona és capaç de mantenir-ho al cap complet imatge. De fet, desenvolupar una eina basada en el supòsit que fins i tot és possible és una mena d'antipatró (un enfocament ineficaç i improductiu). Idealment, la depuració requereix una eina que ajudi restringeix la teva àrea de cerca, perquè els enginyers puguin centrar-se en un subconjunt de dimensions (serveis/usuaris/amfitrions, etc.) rellevants per a l'escenari del problema que s'està considerant. A l'hora de determinar la causa d'una fallada, els enginyers no han d'entendre què va passar durant la fallada tots els serveis alhora, ja que aquest requisit contradiria la idea mateixa d'arquitectura de microserveis.
Tanmateix, traceview ho és és a dir Això. Sí, alguns sistemes de traça ofereixen visualitzacions de traça comprimides quan el nombre de trams del traça és tan gran que no es poden mostrar en una sola visualització. Tanmateix, a causa de la gran quantitat d'informació continguda fins i tot en una visualització tan depurada, els enginyers encara forçat "Tamisar-lo", reduint manualment la selecció a un conjunt de serveis que són fonts de problemes. Malauradament, en aquest camp, les màquines són molt més ràpides que els humans, menys propenses a errors i els seus resultats són més repetibles.
Una altra raó per la qual crec que el traceview és incorrecte és perquè no és bo per a la depuració basada en hipòtesis. En el seu nucli, la depuració és iteratiu un procés que comença amb una hipòtesi, seguit de la verificació de diverses observacions i fets obtinguts del sistema al llarg de diferents vectors, conclusions/generalitzacions i una avaluació posterior de la veritat de la hipòtesi.
Oportunitat ràpid i barat provar hipòtesis i millorar el model mental en conseqüència pedra angular depuració Qualsevol eina de depuració hauria de ser interactiu i reduir l'espai de cerca o, en el cas d'una pista falsa, permetre a l'usuari tornar enrere i centrar-se en una àrea diferent del sistema. L'eina perfecta ho farà de manera proactiva, cridant immediatament l'atenció de l'usuari sobre les possibles àrees problemàtiques.
Ai, traça vista no es pot anomenar una eina amb una interfície interactiva. El millor que podeu esperar quan l'utilitzeu és trobar alguna font d'augment de latència i mirar totes les etiquetes i registres possibles associats amb ella. Això no ajuda l'enginyer a identificar-se patrons en trànsit, com ara les especificitats de la distribució del retard, o detectar correlacions entre diferents mesures. pot ajudar a solucionar alguns d'aquests problemes. Realment, anàlisi reeixida mitjançant l'aprenentatge automàtic per identificar intervals anòmals i identificar un subconjunt d'etiquetes que poden estar associades amb un comportament anòmal. Tot i això, encara no he vist visualitzacions convincents d'aprenentatge automàtic o troballes de mineria de dades aplicades a trams que són significativament diferents d'una vista de traça o d'un DAG (gràfic acíclic dirigit).
Els espais són massa baixos
El problema fonamental amb traceview és aquest allarga són primitives de nivell massa baix tant per a l'anàlisi de latència com per a l'anàlisi de la causa arrel. És com analitzar les ordres de processadors individuals per intentar resoldre una excepció, sabent que hi ha eines de nivell molt superior com el seguiment enrere que són molt més còmodes per treballar.
A més, em faré la llibertat d'afirmar el següent: idealment, no necessitem imatge completa es va produir durant el cicle de vida de la sol·licitud, que està representat per les eines de traça modernes. En canvi, es requereix alguna forma d'abstracció de nivell superior que contingui informació sobre què va anar malament (semblant al retrocés), juntament amb algun context. En lloc de mirar tota la traça, prefereixo veure-la часть, on passa alguna cosa interessant o inusual. Actualment, la cerca es fa manualment: l'enginyer rep el rastre i analitza de manera independent els trams a la recerca d'alguna cosa interessant. L'enfocament de les persones que miren trams en rastres individuals amb l'esperança de detectar activitats sospitoses no s'escala en absolut (sobretot quan han de donar sentit a totes les metadades codificades en diferents intervals, com ara l'identificador d'abast, el nom del mètode RPC, la durada de l'espai). 'a, registres, etiquetes, etc.).
Alternatives a traceview
Els resultats de traça són més útils quan es poden visualitzar d'una manera que ofereix una visió no trivial del que està passant a les parts interconnectades del sistema. Fins que això no passi, el procés de depuració es manté en gran part inert i depèn de la capacitat de l'usuari per notar les correlacions adequades, comprovar les parts correctes del sistema o unir les peces del trencaclosques, a diferència de eina, ajudant l'usuari a formular aquestes hipòtesis.
No sóc un dissenyador visual ni un especialista en UX, però a la següent secció vull compartir algunes idees sobre com poden ser aquestes visualitzacions.
Centrar-se en serveis específics
En un moment en què la indústria es consolida al voltant de les idees , sembla raonable que els equips individuals hagin de prioritzar assegurar-se que els seus serveis estiguin alineats amb aquests objectius. Se segueix que orientat al servei la visualització és la més adequada per a aquests equips.
Les traces, sobretot sense mostreig, són un tresor d'informació sobre cada component d'un sistema distribuït. Aquesta informació es pot enviar a un processador astut que subministrarà als usuaris orientat al servei Les troballes es poden identificar per endavant, fins i tot abans que l'usuari mire els rastres:
- Diagrames de distribució de latència només per a sol·licituds molt destacades (sol·licituds atípiques);
- Esquemes de distribució de retards per als casos en què no s'assoleixen els objectius de SLO del servei;
- Les etiquetes més "comuns", "interessants" i "estranyes" en les consultes que més sovint es repeteixen;
- Avaria de latència per als casos en què dependències els serveis no aconsegueixen els seus objectius SLO;
- Desglossament de la latència per a diversos serveis aigües avall.
Algunes d'aquestes preguntes simplement no es responen mitjançant mètriques integrades, cosa que obliga els usuaris a examinar els intervals. Com a resultat, tenim un mecanisme extremadament hostil a l'usuari.
Això planteja la pregunta: què passa amb les interaccions complexes entre diversos serveis controlats per diferents equips? oi? traça vista no es considera l'eina més adequada per posar de manifest una situació així?
Els desenvolupadors de mòbils, els propietaris de serveis sense estat, els propietaris de serveis gestionats amb estat (com les bases de dades) i els propietaris de plataformes poden estar interessats en alguna cosa més. presentació sistema distribuït; traça vista és una solució massa genèrica per a aquestes necessitats fonamentalment diferents. Fins i tot en una arquitectura de microserveis molt complexa, els propietaris de serveis no necessiten un coneixement profund de més de dos o tres serveis aigües amunt i aigües avall. Essencialment, en la majoria dels escenaris, els usuaris només han de respondre preguntes sobre conjunt limitat de serveis.
És com mirar un petit subconjunt de serveis a través d'una lupa per tal d'escrutar-lo. Això permetrà a l'usuari fer preguntes més urgents sobre les complexes interaccions entre aquests serveis i les seves dependències immediates. Això és similar al retrocés al món dels serveis, on l'enginyer ho sap que incorrecte i també té una certa comprensió del que està passant als serveis circumdants per entendre per què.
L'enfocament que estic promocionant és exactament el contrari de l'enfocament de dalt a baix, basat en traça, on l'anàlisi comença amb tota la traça i, a poc a poc, s'estén cap a intervals individuals. En canvi, un enfocament de baix a dalt comença analitzant una petita àrea propera a la causa potencial de l'incident i, a continuació, amplia l'espai de cerca segons sigui necessari (amb el potencial d'incorporar altres equips per analitzar una gamma més àmplia de serveis). El segon enfocament és més adequat per provar ràpidament les hipòtesis inicials. Un cop obtinguts resultats concrets, es podrà passar a una anàlisi més centrada i detallada.
Construcció d'una topologia
Les vistes específiques del servei poden ser increïblement útils si l'usuari ho sap què? un servei o grup de serveis és responsable d'augmentar la latència o provocar errors. Tanmateix, en un sistema complex, identificar el servei infractor pot ser una tasca no trivial durant una fallada, especialment si no s'han informat missatges d'error dels serveis.
La creació d'una topologia de servei pot ser de gran ajuda per esbrinar quin servei està experimentant un augment de les taxes d'error o un augment de la latència que fa que el servei es degradi notablement. Quan parlo de construir una topologia, no vull dir mapa de serveis, mostrant tots els serveis disponibles al sistema i coneguts pel seu . Aquesta vista no és millor que la vista de traça basada en un gràfic acíclic dirigit. En canvi m'agradaria veure topologia de servei generada dinàmicament, en funció de determinats atributs, com ara el percentatge d'errors, el temps de resposta o qualsevol paràmetre definit per l'usuari que ajudi a aclarir la situació amb serveis sospitosos específics.
Prenguem un exemple. Imaginem un hipotètic lloc de notícies. Servei de pàgina d'inici (portada) intercanvia dades amb Redis, amb un servei de recomanació, amb un servei de publicitat i un servei de vídeo. El servei de vídeo agafa vídeos de S3 i metadades de DynamoDB. El servei de recomanacions rep metadades de DynamoDB, carrega dades de Redis i MySQL i escriu missatges a Kafka. El servei de publicitat rep dades de MySQL i escriu missatges a Kafka.
A continuació es mostra una representació esquemàtica d'aquesta topologia (molts programes comercials d'encaminament construeixen la topologia). Pot ser útil si necessiteu entendre les dependències del servei. Tanmateix, durant depuració, quan un determinat servei (per exemple, un servei de vídeo) presenta un temps de resposta més gran, aquesta topologia no és molt útil.
Diagrama de servei d'un hipotètic lloc de notícies
El diagrama següent seria més adequat. Hi ha un problema amb el servei (vídeo) representat just al centre. L'usuari ho nota immediatament. A partir d'aquesta visualització, queda clar que el servei de vídeo funciona de manera anormal a causa d'un augment del temps de resposta S3, que afecta la velocitat de càrrega d'una part de la pàgina principal.
Topologia dinàmica que només mostra serveis "interessants".
Les topologies generades dinàmicament poden ser més eficients que els mapes de servei estàtics, especialment en infraestructures elàstiques i d'escalat automàtic. La capacitat de comparar i contrastar topologies de serveis permet a l'usuari fer preguntes més rellevants. És més probable que preguntes més precises sobre el sistema condueixin a una millor comprensió de com funciona el sistema.
Visualització comparativa
Una altra visualització útil seria una visualització comparativa. Actualment, les traces no són gaire adequades per a comparacions de costat, de manera que les comparacions solen ser-ho allarga. I la idea principal d'aquest article és precisament que els intervals són de nivell massa baix per extreure la informació més valuosa dels resultats de la traça.
La comparació de dues traces no requereix visualitzacions fonamentalment noves. De fet, n'hi ha prou amb un histograma que representi la mateixa informació que una vista de traça. Sorprenentment, fins i tot aquest senzill mètode pot aportar molt més fruit que simplement estudiar dos rastres per separat. Encara més potent seria la possibilitat visualitzar comparació de traces En total. Seria molt útil veure com un canvi de configuració de la base de dades implementat recentment per habilitar GC (recollida d'escombraries) afecta el temps de resposta d'un servei aigües avall en una escala de diverses hores. Si el que estic descrivint aquí sona com una anàlisi A/B de l'impacte dels canvis en la infraestructura en molts serveis utilitzant els resultats de la traça, no esteu massa lluny de la veritat.
Conclusió
No qüestiono la utilitat del traçat en si. Crec sincerament que no hi ha cap altre mètode per recollir dades tan rics, causals i contextuals com el contingut en un rastre. Tanmateix, també crec que totes les solucions de traça utilitzen aquestes dades de manera extremadament ineficient. Mentre les eines de traça es mantinguin enganxades a la representació de traceview, es veuran limitades en la seva capacitat per treure el màxim profit de la informació valuosa que es pot extreure de les dades contingudes a les traces. A més, hi ha el risc de desenvolupar encara més una interfície visual completament poc amigable i poc intuïtiva que limitarà greument la capacitat de l'usuari per resoldre els errors de l'aplicació.
Depurar sistemes complexos, fins i tot amb les eines més recents, és increïblement difícil. Les eines haurien d'ajudar el desenvolupador a formular i provar una hipòtesi, proporcionant activament informació rellevant, identificant els valors atípics i observant les característiques de la distribució dels retards. Perquè el rastreig es converteixi en l'eina preferida per als desenvolupadors a l'hora de resoldre problemes de producció o resoldre problemes que abasten diversos serveis, es necessiten interfícies d'usuari i visualitzacions originals que siguin més coherents amb el model mental dels desenvolupadors que creen i operen aquests serveis.
Caldrà un esforç mental important per dissenyar un sistema que representi els diferents senyals disponibles en els resultats de la traça d'una manera optimitzada per facilitar l'anàlisi i la inferència. Heu de pensar com abstraure la topologia del sistema durant la depuració d'una manera que ajudi l'usuari a superar els punts cecs sense mirar rastres o trams individuals.
Necessitem bones capacitats d'abstracció i capes (especialment a la interfície d'usuari). Uns que encaixarien bé en un procés de depuració basat en hipòtesis on podeu fer preguntes i provar hipòtesis de manera iterativa. No resoldran automàticament tots els problemes d'observabilitat, però ajudaran els usuaris a afinar la seva intuïció i formular preguntes més intel·ligents. Demano un enfocament més reflexiu i innovador de la visualització. Aquí hi ha una perspectiva real d'ampliar horitzons.
PS del traductor
Llegeix també al nostre blog:
- «»;
- «»;
- «».
Font: www.habr.com