Teenuste jälgimine, OpenTracing ja Jaeger

Meie projektides kasutame mikroteenuste arhitektuuri. Jõudlusprobleemide ilmnemisel kulub palju aega jälgimisele ja logide analüüsimisele. Aegade logimine eri operatsioonide jaoks logifaili seab tavaliselt probleeme, kuna on keeruline mõista, mis viis nende operatsioonide käivitamiseni, jälgida toimingute järjestust või ajastuse nihkumist ühe operatsiooni suhtes teise vahel erinevates teenustes.

Käsitöö vähendamiseks otsustasime kasutada ühte jälgimisriista. Sellest, kuidas ja miks jälgimist kasutada ning kuidas meie seda tegime, räägib see artikkel.

Milliseid probleeme saab jälgimisega lahendada

1. Leida kitsaskohti jõudluses nii ühe teenuse sees kui ka kogu teostuse puus kõigi osalevate teenuste vahel. Näiteks:
   • Palju lühikesi järjestikuseid kutseid teenuste vahel, näiteks geokodeerimise või andmebaasi päringute puhul.
   • Pikad ootamised sisendi / väljundi osas, näiteks andmete edastamine võrgus või kettalt lugemine.
   • Pikk andmete parsimine.
   • Pikad operatsioonid, mis nõuavad CPU-d.
   • Koodijupid, mis ei ole vajalikud lõpptulemuse saamiseks ja võiksid olla eemaldatud või viidatud hiljem.
2. Selgelt mõista, millises järjekorras asjad aset leiavad ja mis toimub, kui operatsioon käivitub.
   
   Näha, et näiteks päring tuli teenusesse WS -> teenus WS täiendas andmeid teenuse R kaudu -> seejärel saatis päringu teenusele V -> teenus V laadis palju andmeid teenusest R -> käidi teenuses P -> teenus P käis veel kord teenuses R -> teenus V ignoreeris tulemust ja läks teenusesse J -> ja alles seejärel naasis vastus teenusele WS, samal ajal jätkates midagi muud taustal arvutamist.
   Ilma sellise jälgimata või üksikasjaliku dokumentatsioonita kogu protsessi kohta on esmakordselt koodi vaadates väga keeruline mõista, mis toimub, ja kood on hajutatud erinevatesse teenustesse ning peidetud mitmete beani ja liideste taha.
3. Teostuse puu teabe kogumine edasiseks analüüsiks. Igas teostusetapis saab jälgisse lisada teavet, mis on sellel etapil saadaval, ja hiljem tuvastada, millised sisendi andmed viisid antud stsenaariumi ilmnemiseni. Näiteks:
   • Kasutaja ID
   • Õigused
   • Valitud meetodi tüüp
   • Log või töötluse viga
4. Käiguteede muutmine alameetriks ja edasine analüüs metrikate kujul.

Mida suudab logida jälgimine. Span

Jälgimises on mõisted span, mis on analoog ühele logile, konsoolis. Spanil on:

• Nimi, tavaliselt meetodi nimi, mis viidi läbi
• Teenuse nimi, milles span genereeriti
• Oma ainulaadne ID
• Mõni meta teave key/value kujul, mis on sinna logitud. Näiteks meetodi parameetrid või see, kas meetod lõppes veaga või mitte
• Span'i algus- ja lõppkja aeg
• Vanema span'i ID

Iga span saadetakse spanide kollektsionäärile, et salvestada see andmebaasi edasiseks vaatamiseks, niipea kui see on oma täitmise lõpetanud. Hiljem on võimalik ehitada kõigi spanide puu, ühendades neid vanema ID järgi. Analüüsi käigus on võimalik leida näiteks kõik spandid mõnes teenuses, mis võtsid rohkem aega kui teatud aeg. Edasi liikudes saab konkreetse span'i juurde minnes näha kõiki puu osi selle span'i kohal ja all.

Opentrace, Jaeger ja kuidas me seda oma projektides rakendasime

On olemas üldine standard Opentrace, mis kirjeldab, kuidas ja mida peab koguma, mitte seondudes jälgimise konkreetse teostusega mõnes keeles. Näiteks Java-s käib kogu jälgimistöötamine läbi üldise API Opentrace, ja selle all võib peituda näiteks Jaeger või tühi vaikimisi teostus, mis ei tee midagi.
Meie süsteem kasutab Jaeger kui Opentrace'i teostust. See koosneb mitmest komponendist:

• Jaeger-agent — kohalik agent, mis on tavaliselt igas masinas ja kuhu logivad teenused kohalikke vaikimisi porte. Kui agenti pole, siis on kõigi selle masina teenuste jälgimised tavaliselt välja lülitatud
• Jaeger-kollektor — kuhu kõik agendid saadavad kogutud jälgimised ning mis salvestab need valitud andmebaasi
• Andmebaas — nende eelistatuim on Cassandra, kuid meie kasutame Elasticsearchi, on olemas teostusi ka mõne muu andmebaasi ja mälu teostuse jaoks, mis ei salvestada midagi kettale
• Jaeger-küsimus — see on teenus, mis läheb andmebaasi ja toob juba kogutud jälgimised analüüsiks
• Jaeger-ui — see on veebirakendus jälgimiste otsimiseks ja vaatamiseks, mis läheb jaeger-küsimusse

Eraldi komponendina võib nimetada opentrace jaeger'i teostust konkreetsete keelte jaoks, mille kaudu span'id saadetakse jaeger-agenti.
Jageri ühendamine Java-s see on nähtav, et rakendada liidest io.opentracing.Tracer, mille järel kõik jäljed suunatakse läbi selle tegelikule agentile.

Samuti saab Springi komponente ühendada opentracing-spring-cloud-starter ja Jaegeri teostus opentracing-spring-jaeger-cloud-starter , mis konfigureerib automaatselt jälgimise kõigile, mis läbib neid komponente, näiteks HTTP-päringud kontrolleritesse, andmebaasi päringud läbi jdbc jne.

Jälgede logimine Java-s

Kusagil kõige kõrgeimal tasemel peaks olema loodud esimene Span, see võib toimuda automaatselt näiteks Springi kontrolleri kaudu päringu saamisel või käsitsi, kui sellist ei ole. Edasi edastatakse see alla Scope'i. Kui mõni allolev meetod soovib lisada Span'i, võtab ta Scope'ist praeguse activeSpan'i, loob uue Span'i ja määrab, et tema vanem on saadud activeSpan, ning teeb uue Span'i aktiivseks. Välistele teenustele edastatakse praegune aktiivne span ja need teenused loovad uued spanid, mis on seotud sellega.
Kogu töö käib Tracer'i näite kaudu, mille saab saada DI mehhanismi abil või GlobalTracer.get() kui globaalse muutujana, kui DI mehhanism ei tööta. Kui tracer ei ole algselt initsialiseeritud, naaseb NoopTracer, mis ei tee midagi.
Seejärel võetakse tracer'ist läbi ScopeManager'i praegune scope, luuakse uus scope praegusest, side uue span'iga, ja seejärel suletakse loodud Scope, mis sulgeb loodud span'i ja taastab varasema Scope'i aktiivseks olekuks. Scope on seotud ühe niidiga, seetõttu tuleb mitme niidi programmeerimisel meeles pidada, et edastada aktiivne span teisele niidile, et aktiveerida teise niidi Scope, mis on seotud selle span'iga.

io.opentracing.Tracer tracer = ...; // GlobalTracer.get()

void DoSmth () {
   try (Scope scope = tracer.buildSpan("DoSmth").startActive(true)) {
      ...
   }
}
void DoOther () {
    Span span = tracer.buildSpan("someWork").start();
    try (Scope scope = tracer.scopeManager().activate(span, false)) {
        // Tee asju.
    } catch(Exception ex) {
        Tags.ERROR.set(span, true);
        span.log(Map.of(Fields.EVENT, "error", Fields.ERROR_OBJECT, ex, Fields.MESSAGE, ex.getMessage()));
    } finally {
        span.finish();
    }
}

void DoAsync () {
    try (Scope scope = tracer.buildSpan("ServiceHandlerSpan").startActive(false)) {
        ...
        final Span span = scope.span();
        doAsyncWork(() -> {
            // STEP 2 ABOVE: aktiveeri span tagasi callbackis, edastades true
            // startActive() juhul, kui span peab olema lõpetatud.
            try (Scope scope = tracer.scopeManager().activate(span, false)) {
                ...
            }
        });
    }
}

Mitme lõime programmeerimiseks on olemas TracedExecutorService ja sarnased wrapper'id, mis edastavad automaatselt praeguse spani lõime, kui asünkroonsed ülesanded käivitatakse:

private ExecutorService executor = new TracedExecutorService(
    Executors.newFixedThreadPool(10), GlobalTracer.get()
);

Väliste http päringute jaoks on olemas TracingHttpClient

HttpClient httpClient = new TracingHttpClientBuilder().build();

Probleemid, millega me silmitsi seisame

• Beendid ja DI ei pruugi alati töötada, kui tracerit ei kasutata teenuses või komponendis, siis Autowired Tracer ei pruugi töötada ja tuleb kasutada GlobalTracer.get().
• Annotatsioonid ei tööta, kui see ei ole komponent või teenus, või kui meetodi kutsumine toimub sama klassi naabermetodist. Tuleb olla ettevaatlik, kontrollida, mis töötab, ja kasutada manuaalset jälgimise loomist, kui @Traced ei tööta. Samuti saab lisada täiendava kompilaatori java annotatsioonide jaoks, siis peaks need töötama igal pool.
• Vanades spring ja spring boot versioonides ei toimi opentracing spring cloud automaatne seadistamine DI vigade tõttu, seega, kui soovite, et jälgimised komponentides automaatselt töötaksid, siis võib teha sarnaselt github.com/opentracing-contrib/java-spring-jaeger/blob/master/opentracing-spring-jaeger-starter/src/main/java/io/opentracing/contrib/java/spring/jaeger/starter/JaegerAutoConfiguration.java
• Groovy's ei toimi try with resources, tuleb kindlasti kasutada try finally.
• Iga teenuse kohta tuleb määrata oma spring.application.name, mille alusel jälgimised logitakse. Eraldi nimi tootmises ja testimises, et nad koos ei seguneks.
• Kui kasutada GlobalTracerit ja tomcat, siis kõik teenused, mis on selles tomcat'is käivitatud, jagavad ühte GlobalTracerit, seega on kõigil sama teenuse nimi.
• Jälgimiste lisamisel meetodisse tuleb olla kindel, et seda ei kutsuta tsüklis liiga sageli. Tuleb lisada üks ühine jälgimine kõigile kutsetele, mis logib koguaegade kokku. Vastasel juhul tekib liigset koormust.
• Kord, kui jaeger-ui's tehti liiga suuri päringuid suure hulga jälgimiste kohta ja kuna ei oodatud vastust, tehti see uuesti. Tulemuseks oli, et jaeger-query hakkas kasutama palju mälu ja aeglustas elastikut. Taastas jaeger-query'i taaskäivitamine aitas.

Jälgimiste proovivõtt, salvestamine ja vaatamine

On kolm tüüpi jälgimise proovivõtt:

1. Const, mis saadab ja salvestab kõik jälgimised.
2. Probabilistic, mis filtreerib jälgimisi kindla tõenäosusega.
3. Ratelimiting, mis piirab tehingute arvu sekundis. Nende parameetreid saab seadistada kliendil, kas jaeger-agendis või kogujas. Praegu on meil rakendustes kasutusel const 1, kuna päringute arv ei ole liiga suur, kuid need võtavad aega. Edasi, kui see süsteemile liiga palju koormust tekitab, saab piirata.

Kui kasutada cassandrat, siis salvestab see tehingud vaikimisi ainult kaheks päevaks. Meie puhul kasutatakse elasticsearch ja tehingud salvestatakse kogu aeg ja ei kustutata. Igal päeval luuakse eraldi indeks, näiteks jaeger-service-2019-03-04. Tulevikus tuleb seadistada automaatne vana tehingu kustutamine.

Tehingute vaatamiseks tuleks:

• Valida teenus, mille põhjal soovid tehinguid filtreerida, näiteks tomcat7-default teenuse puhul, mis on käivitatud tomcat-is ega saa omada oma nime.
• Seejärel valida operatsioon, ajavahemik ja minimaalne operatsiooni aeg, näiteks alates 10 sekundist, et võtta ainult pikki täitmisperioode.
  
• Liikuda ühe tehingu juurde ja vaadata, mis seal takistab.
  

Samuti, kui on teada mõni päringu ID, siis saab leida tehingu selle ID kaudu, otsides silte, kui see ID logitakse tehingu span'i.

Dokumentatsioon

• Opentracingi dokumentatsioon opentracing.io/docs/overview/what-is-tracing
• Jaegeri dokumentatsioon www.jaegertracing.io/docs/1.10
• Jaegeri Java ühendamine github.com/jaegertracing/jaeger-client-java
• Spring Opentracing ühendamine
  github.com/jaegertracing/jaeger-client-java
  github.com/opentracing-contrib/java-spring-cloud

Artiklid

• habr.com/ru/company/carprice/blog/340946 Jaeger Opentracing ja mikroteenused reaalses projektis PHP ja Golangi peal
• eng.uber.com/distributed-tracing Evolving Distributed Tracing at Uber Engineering
• opentracing.io/guides/java
• medium.com/jaegertracing/running-jaeger-agent-on-bare-metal-d1fc47d31fab Running Jaeger Agent on bare metal

Video

• www.youtube.com/watch?v=qg0ENOdP1Lo How We Used Jaeger and Prometheus to Deliver Lightning-Fast User Queries — Bryan Boreham
• www.youtube.com/watch?v=WRntQsUajow Intro: Jaeger — Yuri Shkuro, Uber & Pavol Loffay, Red Hat
• www.youtube.com/watch?v=fsHb0qK37bc Serghei Iakovlev, "Väike lugu suurest võidust: OpenTracing, AWS ja Jaeger"

Allikas: habr.com