Service Tracing, OpenTracing og Jaeger

Service Tracing, OpenTracing og Jaeger

Við notum örþjónustuarkitektúr í verkefnum okkar. Þegar flöskuhálsar á frammistöðu koma fram fer miklum tíma í að fylgjast með og flokka annála. Þegar tímasetningar einstakra aðgerða eru skráðar í annálaskrá er venjulega erfitt að skilja hvað leiddi til þess að þessar aðgerðir voru kallaðar til, að fylgjast með röð aðgerða eða tímafærslu einnar aðgerðar miðað við aðra í mismunandi þjónustu.

Til að lágmarka handavinnu ákváðum við að nota eitt af rekningartækjunum. Um hvernig og hvers vegna þú getur notað rekja og hvernig við gerðum það, og verður fjallað um það í þessari grein.

Hvaða vandamál er hægt að leysa með rekstri

  1. Finndu afköst flöskuhálsa bæði innan einnar þjónustu og í öllu framkvæmdatrénu á milli allra þátttakenda. Til dæmis:
    • Mörg stutt samfelld símtöl á milli þjónustu, til dæmis í landkóðun eða í gagnagrunn.
    • Langar I/O bið, svo sem netflutningar eða diskalestur.
    • Löng gagnagreining.
    • Langar aðgerðir sem krefjast örgjörva.
    • Hlutar af kóða sem eru ekki nauðsynlegir til að fá endanlega niðurstöðu og hægt er að fjarlægja eða seinka.
  2. Skildu greinilega í hvaða röð hvað er kallað og hvað gerist þegar aðgerðin er framkvæmd.
    Service Tracing, OpenTracing og Jaeger
    Það má sjá að til dæmis kom beiðnin til WS þjónustunnar -> WS þjónustan bætti við gögnum í gegnum R þjónustuna -> sendi síðan beiðni til V þjónustunnar -> V þjónustan hleðst mikið af gögnum frá R þjónusta -> fór í P þjónustu -> P þjónusta fór aftur í þjónustu R -> þjónusta V hunsaði niðurstöðuna og fór í þjónustu J -> og skilaði þá fyrst svarinu til þjónustu WS, á meðan haldið var áfram að reikna eitthvað annað í bakgrunnurinn.
    Án slíkrar ummerkis eða nákvæmra gagna fyrir allt ferlið er mjög erfitt að skilja hvað er að gerast þegar þú skoðar kóðann í fyrsta skipti og kóðinn er dreifður um mismunandi þjónustur og falinn á bak við fullt af hólfum og viðmótum.
  3. Söfnun upplýsinga um framkvæmdartréð fyrir síðari frestað greiningu. Á hverju stigi framkvæmdar er hægt að bæta upplýsingum við rakninguna sem eru tiltækar á þessu stigi og finna síðan út hvaða inntaksgögn leiddu til svipaðrar atburðarásar. Til dæmis:
    • notandanafn
    • Réttindi
    • Tegund valinnar aðferðar
    • Skrá eða framkvæmd villa
  4. Að breyta reklum í undirmengi mæligilda og frekari greining þegar í formi mæligilda.

Hvaða ummerki getur skráð. Span

Við rakningu er hugmyndin um span, þetta er hliðstæða einn log, við stjórnborðið. Heilsulindin hefur:

  • Nafn, venjulega nafn aðferðarinnar sem var framkvæmd
  • Heiti þjónustunnar sem span var mynduð í
  • Eigið einstakt auðkenni
  • Einhvers konar metaupplýsingar í formi lykils/gildis sem hefur verið skráður inn á hana. Til dæmis, aðferðarfæribreytur eða aðferðin endaði með villu eða ekki
  • Upphafs- og lokatímar fyrir þetta span
  • Foreldri span auðkenni

Hvert span er sent til span safnara til að vista í gagnagrunninum til síðari skoðunar um leið og það hefur lokið framkvæmd sinni. Í framtíðinni geturðu byggt upp tré af öllum sviðum með því að tengjast með foreldri auðkenni. Við greiningu má til dæmis finna öll spann í einhverri þjónustu sem tók meira en nokkurn tíma. Ennfremur, með því að fara á tiltekið span, sjáðu allt tréð fyrir ofan og neðan þessa span.

Service Tracing, OpenTracing og Jaeger

Opentrace, Jagger og hvernig við innleiddum það fyrir verkefnin okkar

Það er sameiginlegur staðall opið, sem lýsir því hvernig og hverju skuli safnað, án þess að vera bundið með því að rekja til ákveðinnar útfærslu á einhverju tungumáli. Til dæmis, í Java, fer öll vinna með ummerki fram í gegnum sameiginlega Opentrace API og undir því er til dæmis hægt að fela Jaeger eða tóma sjálfgefna útfærslu sem gerir ekkert.
Við erum að nota Jaeger sem útfærsla á Opentrace. Það samanstendur af nokkrum hlutum:

Service Tracing, OpenTracing og Jaeger

  • Jaeger-agent er staðbundinn umboðsmaður sem er venjulega settur upp á hverri vél og þjónusta er skráð inn á hana á staðbundnu sjálfgefna gáttinni. Ef það er enginn umboðsmaður, þá eru ummerki um alla þjónustu á þessari vél venjulega óvirk
  • Jaeger-collector - allir umboðsmenn senda söfnuð ummerki til hans og það setur þau í valinn gagnagrunn
  • Gagnagrunnurinn er valinn cassandra þeirra, en við notum elasticsearch, það eru útfærslur fyrir nokkra aðra gagnagrunna og útfærslu í minni sem vistar ekkert á diskinn
  • Jaeger-query er þjónusta sem fer í gagnagrunninn og skilar þegar safnað ummerki til greiningar
  • Jaeger-ui er vefviðmót til að leita og skoða ummerki, það fer í jaeger-query

Service Tracing, OpenTracing og Jaeger

Hægt er að kalla sérstakan þátt útfærslu á opentrace jaeger fyrir ákveðin tungumál, þar sem span eru send til jaeger-agent.
Að tengja Jagger í Java kemur niður á að innleiða io.opentracing.Tracer viðmótið, eftir það munu öll ummerki í gegnum það fljúga til raunverulegs umboðsmanns.

Service Tracing, OpenTracing og Jaeger

Einnig fyrir gormahlutann er hægt að tengja opentracing-spring-cloud-starter og framkvæmd frá Jaeger opentracing-spring-jaeger-cloud-starter sem mun sjálfkrafa stilla rakningu fyrir allt sem fer í gegnum þessa íhluti, til dæmis http beiðnir til stjórnenda, beiðnir í gagnagrunninn í gegnum jdbc o.s.frv.

Rekja innskráningu í Java

Einhvers staðar á efsta stigi þarf að búa til fyrsta Span, þetta er hægt að gera sjálfkrafa, til dæmis með gormstýringu þegar beiðni berst, eða handvirkt ef engin er. Það er síðan sent í gegnum umfangið hér að neðan. Ef einhver aðferð hér að neðan vill bæta við Span, tekur hún núverandi activeSpan úr Scope, býr til nýtt Span og segir að foreldri þess sé activeSpan sem myndast og gerir nýja Span virkan. Þegar hringt er í ytri þjónustu er núverandi virka span send til þeirra og þær þjónustur búa til ný span með tilvísun í þetta span.
Öll vinna fer í gegnum Tracer dæmið, þú getur fengið það í gegnum DI vélbúnaðinn, eða GlobalTracer.get () sem alþjóðlega breytu ef DI vélbúnaðurinn virkar ekki. Sjálfgefið, ef tracer hefur ekki verið frumstillt, mun NoopTracer skila sem gerir ekkert.
Ennfremur er núverandi umfang fengið frá rekjasviðinu í gegnum ScopeManager, nýtt umfang er búið til úr því núverandi með bindingu á nýja spaninu og síðan er búið til umfang lokað, sem lokar búið til og skilar fyrra umfangi til virka ríkið. Umfang er bundið við þráð, þannig að við fjölþráða forritun má ekki gleyma að flytja virka spanið yfir á annan þráð, til frekari virkjunar á umfangi annars þráðs með vísan til þessa spannar.

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)) {
        // Do things.
    } 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: reactivate the Span in the callback, passing true to
            // startActive() if/when the Span must be finished.
            try (Scope scope = tracer.scopeManager().activate(span, false)) {
                ...
            }
        });
    }
}

Fyrir fjölþráða forritun er einnig til TracedExecutorService og álíka umbúðir sem senda sjálfkrafa núverandi span á þráðinn þegar ósamstillt verkefni eru sett af stað:

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

Fyrir utanaðkomandi http beiðnir er RekjaHttpClient

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

Vandamál sem við stóðum frammi fyrir

  • Baunir og DI virka ekki alltaf ef sporefnið er ekki notað í þjónustu eða íhlut, þá Sjálfvirkt snúið Tracer gæti ekki virkað og þú verður að nota GlobalTracer.get().
  • Skýringar virka ekki ef það er ekki hluti eða þjónusta, eða ef aðferðin er kölluð frá nálægri aðferð í sama flokki. Þú verður að gæta þess að athuga hvað virkar og nota handvirka rekjagerð ef @Traced virkar ekki. Þú getur líka hengt við viðbótarþýðanda fyrir java athugasemdir, þá ættu þeir að virka alls staðar.
  • Í gamla gorma- og gormastígvélinni virkar sjálfvirk stilling opna gormaskýjanna ekki vegna galla í DI, þá ef þú vilt að ummerkin í gormaíhlutunum virki sjálfkrafa geturðu gert það á hliðstæðan hátt með 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
  • Prófaðu með auðlindum virkar ekki í groovy, þú verður að nota try loksins.
  • Hver þjónusta verður að hafa sitt spring.application.name sem ummerki verða skráð undir. Hvað þýðir sérstakt nafn fyrir sölu og próf, svo sem ekki að trufla þá saman.
  • Ef þú notar GlobalTracer og tomcat, þá hafa allar þjónustur sem keyra í þessum tomcat einn GlobalTracer, svo þær munu allar hafa sama þjónustuheiti.
  • Þegar rekjum er bætt við aðferð þarf að vera viss um að það sé ekki kallað oft í lykkju. Nauðsynlegt er að bæta við einni sameiginlegri rekstri fyrir öll símtöl sem tryggir heildarvinnutímann. Annars verður umframálag búið til.
  • Einu sinni í jaeger-ui voru of stórar beiðnir gerðar um mikinn fjölda ummerkja og þar sem þeir biðu ekki eftir svari gerðu þeir það aftur. Þess vegna byrjaði jaeger-query að borða mikið af minni og hægja á teygju. Aðstoð með því að endurræsa jaeger-query

Sýnataka, geymsla og skoðun ummerki

Það eru þrjár tegundir sýnatökuspor:

  1. Const sem sendir og vistar öll ummerki.
  2. Líkindafræðilegt sem síar ummerki með einhverjum tilteknum líkum.
  3. Hraðatakmörkun sem takmarkar fjölda spora á sekúndu. Þú getur stillt þessar stillingar á biðlaranum, annað hvort á jaeger-agent eða á safnara. Nú notum við const 1 í verðmatsbunkanum, þar sem það eru ekki mjög margar beiðnir, en þær taka langan tíma. Í framtíðinni, ef þetta mun hafa of mikið álag á kerfið, geturðu takmarkað það.

Ef þú notar Cassandra, þá geymir það sjálfgefið aðeins ummerki í tvo daga. Við erum að nota teygjanám og ummerki eru geymd að eilífu og er ekki eytt. Sérstök vísitala er búin til fyrir hvern dag, til dæmis jaeger-service-2019-03-04. Í framtíðinni þarftu að stilla sjálfvirka hreinsun á gömlum ummerkjum.

Til þess að skoða ummerkin þarftu:

  • Veldu þjónustuna sem þú vilt sía ummerki eftir, til dæmis tomcat7-default fyrir þjónustu sem er í gangi í tomcat og getur ekki haft sitt eigið nafn.
  • Veldu síðan aðgerðina, tímabilið og lágmarksaðgerðartímann, til dæmis frá 10 sekúndum, til að taka aðeins langar framkvæmdir.
    Service Tracing, OpenTracing og Jaeger
  • Farðu í eitt af sporunum og sjáðu hvað hægðist þar.
    Service Tracing, OpenTracing og Jaeger

Einnig, ef einhver beiðni auðkenni er þekkt, þá getur þú fundið rekja eftir þessu auðkenni í gegnum merkjaleit, ef þetta auðkenni er skráð á rekjasviðinu.

Skjöl

Greinar

video

Heimild: www.habr.com

Bæta við athugasemd