Daca aveti de-a face cu microservicii, arhitectura fara server, pentru orice alt tip de arhitectura distribuita, probabil ati auzit termenul „ Urmarire distribuita ”. Poate ca v-ati intrebat despre ce este vorba si de unde ar trebui sa incepeti, in aceasta postare, va voi spune despre calatoria pe care am trecut-o la Duda , din ziua in care am auzit despre urmarirea distribuita si am inceput sa exploram daca va fi util sa-l folosim in compania noastra, la explorarea a ceea ce este urmarit distribuit, care sunt diferitele solutii si care sunt arhitecturile lor si, in cele din urma, voi prezenta solutia noastra finala, modul in care am instrumentat (sutele de masini) serviciile si catre ce ne indreptam.

Pentru a face acest lucru, voi raspunde la urmatoarele intrebari:

De ce ati dori sa cititi chiar si despre urmarirea distribuita?

Ce este urmarirea distribuita, de unde a inceput totul, care sunt componentele de baza ale acesteia?

Voi povesti, de asemenea, despre consideratiile noastre la Duda, de ce am decis sa lucram cu instrumente si specificatii specifice si in ce mod am implementat monolitul si serviciile noastre.

Sa incepem cu cea mai importanta intrebare – de ce ati dori chiar sa investiti timp in integrarea urmaririi distribuite in stiva dvs. de tehnologie.

Array

Desi exista multe motive, le voi mentiona pe cele care sunt cele mai importante din perspectiva mea.

Dezvaluie dependentele de serviciu

A fost luata decizia strategica, compania dvs. a inceput sa treaca la o arhitectura distribuita, numarul componentelor incepe sa creasca si capacitatea de a intelege arhitectura companiei dvs. scade, folosind urmarirea distribuita puteti urmari calea unei cereri pe masura ce traverseaza un sistem complex .

Unele instrumente chiar calculeaza si deseneaza un grafic complet de dependenta, va poate ajuta sa aveti o imagine de ansamblu asupra arhitecturii dvs.

Array

si sa faceti o scufundare profunda pentru a intelege mai bine dependentele.

Descoperiti latenta componentelor de-a lungul unei cai date

Puteti descoperi latenta monitorizand o solicitare de la serviciile marginale utilizand sisteme de monitorizare. OK, ati primit alerta, acum trebuie sa aflati ce componenta determina depasirea cererii specifice SLO. Tocmai de aceea este aici urmarirea distribuita, Localizarea componentelor in cale care sunt blocaje sau care cauzeaza esecuri.

Analiza cauzelor fundamentale

Imaginati-va urmatorul scenariu – va treziti printr-o alerta, este ora 2 AM, o cerere care implica 5 microservicii diferite esueaza in mod repetat.

Array

Sariti la jurnale, tot incercand sa deschideti ochii impotriva ecranului ultra luminat, cautati erori in timpul alertei, dar fluxul de date este prea mare pentru a afla ce s-a intamplat, dureaza prea mult. Folosind urmarirea distribuita, puteti gasi primul serviciu care a esuat, puteti obtine jurnale de la esec si alte lucruri (depinde implementarea urmaririi).

Colectati evenimente in timpul solicitarii

Pentru a ajuta in procesul de depanare, puteti adauga bagaje la urmarire, de exemplu, la Duda, compania pentru care lucrez, adaugam toate semnalizarile de caracteristici evaluate la urmarire, prin aceasta, in caz de esec, putem cunoaste exact steagurile care au fost evaluate in interiorul fiecaruia dintre serviciile de pe calea cererii.

Acum, cand am discutat de ce ati dori chiar sa cititi restul acestei postari, daca sunteti inca alaturi de mine (sper ca urmarirea distribuita este minunata!), Sa continuam cu ceea ce este urmarirea distribuita si care sunt diferitele solutii pe care le puteti gasi acolo.

In primul rand, sa incepem cu elementele de baza, de unde au provenit toate solutiile de urmarire distribuite.

Desi au existat anterior cateva solutii de urmarire distribuita, hartia de proiectare Google Dapper (2010) este o piatra de temelie a urmaririi distribuite. Aceasta lucrare explica modul in care Google a dezvoltat un instrument de urmarire la nivel de productie, cu 3 obiective cheie in spate.

  1. Cost redus – sistemul de urmarire ar trebui sa aiba un impact neglijabil asupra performantei asupra serviciilor care ruleaza. In

    unele servicii extrem de optimizate, chiar si cheltuielile de monitorizare mici sunt usor de observat. De exemplu, o singura interogare de cautare Google parcurge mii de masini si servicii, Google nu isi poate permite o crestere deloc neglijabila pentru fiecare dintre aceste solicitari.

  2. Transparenta la nivel de aplicatie – Urmarirea nu ar trebui sa necesite o colaborare activa pentru programatori, deoarece ar putea fi fragila si consuma timpul scump al programatorilor pentru ao invata.
  3. Scalabilitate – Trebuie sa gestioneze scara Google cel putin cativa ani.

De asemenea, acestea adauga cerinta ca datele de urmarire sa fie disponibile la cateva minute dupa solicitare.

Instrumentarea si terminologia serviciului

Dapper a introdus unele terminologii, poate diferi intre diferite solutii, dar acestea sunt ideile utilizate in majoritatea solutiilor sale succesive.

Urmarire : descrierea unei tranzactii pe masura ce se deplaseaza printr-un sistem distribuit.

Span : O operatie numita, temporizata, reprezentand o parte din fluxul de lucru. Extensiile accepta cheie: etichete de valoare, precum si jurnale cu granulatie fina, marcate in timp, structurate atasate instantei de anume anume.

(Span) Context : Urmariti informatiile de identificare care insotesc tranzactia distribuita, inclusiv atunci cand acesta trece serviciul la serviciu prin retea sau printr-un bus de mesaje. Contextul span contine identificatorul de urmarire, identificatorul de span si orice alte date de care sistemul de urmarire trebuie sa se propage catre serviciul din aval.

Instrumentare : Instrumentarea este procesul prin care codul aplicatiei dvs. este extins pentru a capta si raporta intinderi de urmarire pentru operatiunile de interes.

Adnotari: adnotarile (uneori numite bagaje ), permit dezvoltatorului sa imbogateasca urmele cu date definite de utilizator, pot fi folosite pentru a salva contoare, jurnale relevante si orice date pot ajuta la investigarea unui incident.

Contextul de urmarire este serializat si transmis in timpul apelului intre serviciile instrumentate , va fi RPC, mesaj de eveniment, SMTP sau orice alt canal de comunicare pe care il aveti in minte dupa ce clientul a trimis serverului datele de urmarire (de exemplu prin antetul HTTP in Apeluri REST), serverul va deserializa intervalul si va incepe unul nou care indica intervalul sau parinte , intervalul a fost primit de client.

Aceste imagini urmatoare ajuta la demonstrarea relatiei dintre diferitele componente:

Un ciclu de viata de urmarire (Prezentare generala OpenTracing)

Arborele de urmarire Dapper (Dapper o infrastructura de urmarire a sistemelor distribuite pe scara larga, raport tehnic Google dapper 2010)

Colectarea si depozitarea urmelor

Dupa ce urmarirea este colectata in fiecare server instrumentat, trebuie sa fie agregata prin faptul ca intreaga urma si intinderile pot fi afisate intr-o singura interfata pentru a permite observatorului sa primeasca informatii despre cerere si despre comunicarea sa interna. Modul in care a introdus Dapper este un proces in trei etape.

  1. Datele span sunt scrise intr-un fisier jurnal local
  2. Colectionarii Dapper citesc de la demon pe masinile de productie urmele
  3. Colectionarii care scriu urma intr-un singur depozit Bigtable

Colectarea urmelor Dapper (Dapper o infrastructura de urmarire a sistemelor distribuite pe scara larga, Google Technical Report dapper 2010)

Aceasta metodologie a oferit Google o mediana de latenta de 15 secunde pentru colectie, ceea ce este foarte impresionant pentru o scara inalta, cu log overhead pentru aplicatiile existente.

Pentru a imbunatati performanta, se utilizeaza esantionarea, ceea ce inseamna ca doar o fractiune din toate urmele sunt inregistrate si colectate. Aici se presupune ca, pentru majoritatea cazurilor de utilizare, va fi suficient sa obtineti toate sau cel putin cele mai multe informatii si ca degradarea performantei ar trebui sa fie neglijabila.

Dupa ce am vorbit despre stramos, sa ajungem la solutiile disponibile in aceste zile – multi dintre ei impartasesc acelasi concept sau chiar solutie ca Dapper.

Solutiile pot fi grupate in 2 grupe:

  1. Solutii Open Source

    Zipkin (Twitter)

    Jaeger (Uber)

    AppDash

  2. Solutii pentru intreprinderi

    Amazon X-Ray

    Google Cloud Trace

    Datadog

    Lightstep

    Relic noua

Acestea sunt unele, dar nu toate solutiile disponibile. Aceasta postare nu le va compara, voi spune doar ca fiecare dintre solutii are avantaje si dezavantaje, iar beneficiile depind de arhitectura, limbajul si, mai ales, stiva. Dupa ce ati ales una, pentru a evita cuplarea la o solutie specifica in timpul instrumentarii, au fost ridicate mai multe specificatii si standarde:

Specificatie W3 – defineste anteturi HTTP standard si un format de valoare pentru a propaga informatii de context.

OpenTracing – OpenTracing este alcatuit dintr-o specificatie API, cadre si biblioteci care au implementat specificatia si documentatia pentru proiect.

OpenCensus – OpenCensus este un set de biblioteci pentru diferite limbi care va permit sa colectati valorile aplicatiei si urmele distribuite, apoi sa transferati datele intr-un backend la alegere in timp real.

OpenTelemetry – O colaborare intre creatorii OpenTracing si OpenCensus, care este creata pentru a le inlocui cu o specificatie unificata cu biblioteci de instrumente scrise intr-o varietate de limbi. OpenTracing este acum un proiect de incubare al CNCF (Cloud Native Computing Foundation).

Acum, cand avem cunostintele fundamentale despre urmarirea distribuita, as dori sa va impartasesc experienta mea cu instrumentarea a peste 150 de masini folosind Jaeger si Opentracing. Am decis sa ne instrumentam serviciile folosind Opentracing, deoarece pe atunci era singura solutie pregatita pentru productie (Open Census este in faze beta), deoarece avem mii de solicitari pe secunda, avem nevoie de o solutie robusta care sa nu mareasca latenta. Au existat mai multe motive pentru care am ales Jaeger, mai intai, este o solutie open source matura proiect absolvit CNCF si pentru ca la Duda folosim logz.io ca solutie de stiva ELK si au inceput sa ofere o solutie de urmarire distribuita cu magazinul ElasticSearch si UI Jaeger,

Arhitectura noastra la Duda este compusa dintr-un monolit cadru Spring si aproximativ 10 microservicii Spring Boot. Pentru microservicii, pornitorii de pornire Spring isi fac magia, asa ca tot ce trebuia sa fac era sa instrumentez atat clientul nostru intern de repaus, cat si biblioteca partajata a evenimentelor. Pentru a permite dezvoltatorilor sa stie care a fost fluxul exact in serviciu, am instrumentat si biblioteca noastra de steaguri de caracteristici, astfel incat sa adauge cheia de steag si valoarea specifica evaluata in flux la bagajul de urmarire. In plus fata de instrumentele aplicative, am rulat un agent Jaeger pe fiecare masina si le-am conectat la un colector care livreaza jurnalele catre logz.io ElasticSearch.

Acum, cand aveti un fundal solid despre urmarire, sa vedem un exemplu de urma Jaeger compusa din 4 intinderi, in care service1 comunica cu service2 folosind un apel REST (unde service1 este clientul si service2 este serverul), service2 evalueaza un caracteristica steag doSomthing.featureFlag.enabled cu valoarea true si, ca rezultat, produce un eveniment consumat de service1. Dupa cum puteti observa, timpul de incepere al fiecarui interval ulterior este mai mare decat cel anterior, folosind aceste informatii jaeger poate calcula timpul fiecarui interval si va poate ajuta sa detectati blocaje in flux.

In cele din urma, am avut sesiuni cu dezvoltatorii, care explica despre urmarirea distribuita ca parte a solutiei noastre de observabilitate, cand ar trebui utilizata si cum, am trecut peste cateva exemple de cod, astfel incat acestia sa stie cum sa instrumenteze toate fluxurile importante si suspecte de blocaj, astfel incat avem informatii maxime si distrageri minime in urma noastra.

Asta este tot deocamdata, speram sa aveti o vedere mai stralucita despre CE este urmarirea distribuita si DE CE ar trebui sa utilizati urmarirea distribuita in organizatia dvs., daca aveti vreo intrebare cu privire la implementare sau la decizia pe care am luat-o sau orice idee sau sfat, doar raspunde la postare!

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR