ProHoster > Blogs > Administrācija > Service Tracing, OpenTracing un Jaeger

Service Tracing, OpenTracing un Jaeger

Service Tracing, OpenTracing un Jaeger

Savos projektos mēs izmantojam mikropakalpojumu arhitektÅ«ru. Ja rodas veiktspējas vājās vietas, daudz laika tiek pavadÄ«ts žurnālu uzraudzÄ«bai un parsÄ“Å”anai. ReÄ£istrējot atseviŔķu darbÄ«bu laikus žurnāla failā, parasti ir grÅ«ti saprast, kas noveda pie Å”o darbÄ«bu izsaukÅ”anas, izsekot darbÄ«bu secÄ«bai vai vienas operācijas laika nobÄ«dei attiecÄ«bā pret citu dažādos pakalpojumos.

Lai samazinātu roku darbu, mēs nolēmām izmantot vienu no izsekoÅ”anas rÄ«kiem. Par to, kā un kāpēc varat izmantot izsekoÅ”anu un kā mēs to darÄ«jām, un tas tiks apspriests Å”ajā rakstā.

Kādas problēmas var atrisināt ar izsekoÅ”anu

  1. Atrodiet veiktspējas vājās vietas gan vienā pakalpojumā, gan visā izpildes kokā starp visiem iesaistītajiem pakalpojumiem. Piemēram:
    • Daudz Ä«su secÄ«gu zvanu starp pakalpojumiem, piemēram, Ä£eokodÄ“Å”anai vai datu bāzei.
    • Ilga I/O gaidÄ«Å”ana, piemēram, tÄ«kla pārsÅ«tÄ«Å”ana vai diska nolasÄ«Å”ana.
    • Ilga datu parsÄ“Å”ana.
    • Ilgas darbÄ«bas, kurām nepiecieÅ”ams centrālais procesors.
    • Koda sadaļas, kas nav vajadzÄ«gas gala rezultāta iegÅ«Å”anai un kuras var noņemt vai aizkavēt.
  2. Skaidri saproti, kādā secībā ko sauc un kas notiek, kad tiek veikta operācija.
    Service Tracing, OpenTracing un Jaeger
    Redzams, ka, piemēram, Pieprasījums ieradās WS servisā -> WS serviss papildināja datus caur R servisu -> pēc tam nosūtīja pieprasījumu V servisam -> V serviss ielādēja daudz datu no R serviss -> aizgāja uz P servisu -> P serviss atkal devās uz servisu R -> serviss V ignorēja rezultātu un devās uz servisu J -> un tikai tad atgrieza atbildi uz servisu WS, turpinot rēķināt ko citu fons.
    Ja nav Ŕādas izsekoÅ”anas vai detalizētas dokumentācijas visam procesam, ir ļoti grÅ«ti saprast, kas notiek, pirmo reizi aplÅ«kojot kodu, un kods ir izkaisÄ«ts pa dažādiem pakalpojumiem un paslēpts aiz tvertnēm un saskarnēm.
  3. Informācijas vākÅ”ana par izpildes koku turpmākai atliktajai analÄ«zei. Katrā izpildes posmā varat pievienot informāciju izsekojamÄ«bai, kas ir pieejama Å”ajā posmā, un pēc tam noskaidrot, kuri ievades dati noveda pie lÄ«dzÄ«ga scenārija. Piemēram:
    • Lietotāja ID
    • tiesÄ«bas
    • Izvēlētās metodes veids
    • Žurnāla vai izpildes kļūda
  4. Izsekojumu pārvērÅ”ana metrikas apakÅ”kopā un turpmāka analÄ«ze jau metrikas veidā.

Kādas pēdas var pieteikt. Spin

Izsekojot pastāv laiduma jēdziens, tas ir viena baļķa analogs konsolei. Spa ir:

  • Nosaukums, parasti izpildÄ«tās metodes nosaukums
  • Pakalpojuma nosaukums, kurā tika Ä£enerēts diapazons
  • Savs unikālais ID
  • Kaut kāda metainformācija atslēgas/vērtÄ«bas veidā, kas tajā ir reÄ£istrēta. Piemēram, metodes parametri vai metode beidzās ar kļūdu vai nē
  • Å Ä« perioda sākuma un beigu laiks
  • Vecāku diapazona ID

Katrs diapazons tiek nosÅ«tÄ«ts uz diapazona savācēju, lai to saglabātu datu bāzē vēlākai pārskatÄ«Å”anai, tiklÄ«dz tas ir pabeidzis izpildi. Nākotnē varat izveidot visu laidumu koku, izveidojot savienojumu, izmantojot vecāku ID. Analizējot, jÅ«s varat atrast, piemēram, visus dažu pakalpojumu posmus, kas prasÄ«ja vairāk nekā noteiktu laiku. Turklāt, pārejot uz noteiktu laidumu, skatiet visu koku virs un zem Ŕī laiduma.

Service Tracing, OpenTracing un Jaeger

Opentrace, Jagger un tas, kā mēs to ieviesām savos projektos

Ir kopÄ«gs standarts opentrace, kurā ir aprakstÄ«ts, kā un kas ir jāapkopo, un tas nav saistÄ«ts ar konkrētu implementāciju jebkurā valodā. Piemēram, Java viss darbs ar trasÄ“Å”anu tiek veikts, izmantojot parasto Opentrace API, un zem tā var paslēpt, piemēram, Jaeger vai tukÅ”u noklusējuma implementāciju, kas neko nedara.
Mēs lietojam Vilnas triko kā Opentrace ievieÅ”ana. Tas sastāv no vairākiem komponentiem:

Service Tracing, OpenTracing un Jaeger

  • Jaeger-agent ir vietējais aÄ£ents, kas parasti tiek instalēts katrā datorā, un pakalpojumi tiek pieteikti tajā vietējā noklusējuma portā. Ja aÄ£enta nav, visu pakalpojumu pēdas Å”ajā maŔīnā parasti tiek atspējotas
  • Jaeger-collector - visi aÄ£enti nosÅ«ta savāktās pēdas uz to, un tas ievieto tos izvēlētajā datu bāzē
  • Datubāze ir viņu vēlamā cassandra, bet mēs izmantojam elasticsearch, ir implementācijas dažām citām datu bāzēm un atmiņā esoÅ”a implementācija, kas neko nesaglabā diskā.
  • Jaeger-query ir pakalpojums, kas pāriet uz datu bāzi un atgriež jau savāktās pēdas analÄ«zei
  • Jaeger-ui ir tÄ«mekļa saskarne pēdu meklÄ“Å”anai un apskatei, tā pāriet uz jaeger vaicājumu

Service Tracing, OpenTracing un Jaeger

AtseviŔķu komponentu var saukt par opentrace jaeger ievieÅ”anu konkrētām valodām, caur kuru spans tiek nosÅ«tÄ«tas uz jaeger-agent.
Jagger savienoÅ”ana Java io.opentracing.Tracer interfeiss ir jāievieÅ”, pēc tam visas pēdas caur to aizlidos uz Ä«sto aÄ£entu.

Service Tracing, OpenTracing un Jaeger

ArÄ« atsperes komponentam var pieslēgt opentracing-spring-cloud-starter un ievieÅ”ana no Jaeger opentracing-spring-jaeger-cloud-starter kas automātiski konfigurēs izsekoÅ”anu visam, kas iet caur Å”iem komponentiem, piemēram, http pieprasÄ«jumi kontrolieriem, pieprasÄ«jumi datu bāzei, izmantojot jdbc utt.

Trases reģistrēŔana Java

Kaut kur augŔējā lÄ«menÄ« ir jāizveido pirmais Span, to var izdarÄ«t automātiski, piemēram, atsperes kontrolieris, kad tiek saņemts pieprasÄ«jums, vai manuāli, ja tāda nav. Pēc tam tas tiek pārsÅ«tÄ«ts, izmantojot tālāk norādÄ«to darbÄ«bas jomu. Ja kāda no tālāk norādÄ«tajām metodēm vēlas pievienot diapazonu, tā ņem paÅ”reizējo ActiveSpan no tvēruma, izveido jaunu diapazonu un saka, ka tā vecākais ir iegÅ«tais ActiveSpan, un padara jauno diapazonu aktÄ«vu. Izsaucot ārējos pakalpojumus, paÅ”reizējais aktÄ«vais diapazons tiek nodots tiem, un Å”ie pakalpojumi izveido jaunus diapazonus, atsaucoties uz Å”o diapazonu.
Viss darbs notiek caur Tracer gadījumu, to var iegūt, izmantojot DI mehānismu vai GlobalTracer.get () kā globālo mainīgo, ja DI mehānisms nedarbojas. Pēc noklusējuma, ja tracer nav inicializēts, NoopTracer atgriezīsies, kas neko nedara.
Tālāk paÅ”reizējais tvērums tiek iegÅ«ts no trasera caur ScopeManager, no paÅ”reizējā tiek izveidots jauns ar jaunā diapazona iesieÅ”anu, un pēc tam izveidotais tvērums tiek aizvērts, kas aizver izveidoto diapazonu un atgriež iepriekŔējo tvērumu aktÄ«vajā stāvoklÄ«. DarbÄ«bas joma ir piesaistÄ«ta pavedienam, tāpēc, programmējot vairāku pavedienu, nedrÄ«kst aizmirst pārsÅ«tÄ«t aktÄ«vo laidumu uz citu pavedienu, lai turpmāk aktivizētu cita pavediena darbÄ«bas jomu, atsaucoties uz Å”o laidumu.

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)) {
                ...
            }
        });
    }
}

Vairāku pavedienu programmÄ“Å”anai ir arÄ« TracedExecutorService un lÄ«dzÄ«gi iesaiņotāji, kas automātiski pārsÅ«ta paÅ”reizējo diapazonu uz pavedienu, kad tiek palaisti asinhronie uzdevumi:

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

Ārējiem http pieprasījumiem ir TracingHttpClient

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

Problēmas, ar kurām saskārāmies

  • Pupiņas un DI ne vienmēr darbojas, ja marÄ·ieris netiek izmantots servisā vai komponentā Autovadu savienojums Tracer var nedarboties, un jums bÅ«s jāizmanto GlobalTracer.get().
  • Anotācijas nedarbojas, ja tas nav komponents vai pakalpojums, vai ja metode tiek izsaukta no tās paÅ”as klases blakus metodes. Jums ir jābÅ«t uzmanÄ«giem, lai pārbaudÄ«tu, kas darbojas, un jāizmanto manuāla izsekoÅ”anas izveide, ja @Traced nedarbojas. Varat arÄ« pievienot papildu kompilatoru java anotācijām, tad tām vajadzētu darboties visur.
  • Vecajā atsperes un pavasara sāknÄ“Å”anas gadÄ«jumā opentraing pavasara mākoņa automātiskā konfigurācija nedarbojas DI kļūdu dēļ, tad, ja vēlaties, lai atsperes komponentos esoŔās pēdas darbotos automātiski, varat to izdarÄ«t pēc analoÄ£ijas ar 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
  • Mēģiniet ar resursiem nedarbojas groovy, jums ir jāizmanto mēģināt beidzot.
  • Katram pakalpojumam ir jābÅ«t savam spring.application.name, ar kuru tiks reÄ£istrētas pēdas. Ko dara atseviŔķs nosaukums pārdoÅ”anai un pārbaudei, lai tie netraucētu kopā.
  • Ja izmantojat GlobalTracer un runcis, tad visiem pakalpojumiem, kas darbojas Å”ajā runci, ir viens GlobalTracer, tāpēc tiem visiem bÅ«s viens un tas pats pakalpojuma nosaukums.
  • Pievienojot metodei pēdas, jums jāpārliecinās, ka tā netiek izsaukta daudzas reizes ciklā. Visiem izsaukumiem ir jāpievieno viena kopēja izsekoÅ”ana, kas garantē kopējo darba laiku. Pretējā gadÄ«jumā tiks izveidota pārmērÄ«ga slodze.
  • Reiz Jēger-ui tika izteikti pārāk lieli pieprasÄ«jumi par lielu skaitu pēdu, un, tā kā viņi negaidÄ«ja atbildi, viņi to izdarÄ«ja vēlreiz. Tā rezultātā jaeger vaicājums sāka ēst daudz atmiņas un palēnināt elastÄ«bu. PalÄ«dzēja restartēt jaeger-query

Izsekojumu paraugu ņemÅ”ana, uzglabāŔana un apskate

Ir trÄ«s veidi paraugu ņemÅ”anas pēdas:

  1. Const, kas nosūta un saglabā visas pēdas.
  2. Varbūtības, kas filtrē pēdas ar noteiktu varbūtību.
  3. RatelimitÄ“Å”ana, kas ierobežo pēdu skaitu sekundē. Å os iestatÄ«jumus var konfigurēt klientā vai nu jaeger-agent, vai savācējā. Tagad vērtētāju kaudzē mēs izmantojam const 1, jo pieprasÄ«jumu nav ļoti daudz, taču tie aizņem daudz laika. Nākotnē, ja tas radÄ«s pārmērÄ«gu slodzi sistēmai, varat to ierobežot.

Ja izmantojat cassandra, pēc noklusējuma tas saglabā pēdas tikai divas dienas. Mēs lietojam elastÄ«gā meklÄ“Å”ana un pēdas tiek saglabātas visu laiku un netiek dzēstas. Katrai dienai tiek izveidots atseviŔķs rādÄ«tājs, piemēram, jaeger-service-2019-03-04. Nākotnē jums ir jākonfigurē automātiska veco pēdu tÄ«rÄ«Å”ana.

Lai skatÄ«tu pēdas, jums ir nepiecieÅ”ams:

  • Atlasiet pakalpojumu, ar kuru vēlaties filtrēt pēdas, piemēram, tomcat7-default pakalpojumam, kas darbojas tomcat un kuram nevar bÅ«t sava nosaukuma.
  • Pēc tam atlasiet darbÄ«bu, laika intervālu un minimālo darbÄ«bas laiku, piemēram, no 10 sekundēm, lai veiktu tikai ilgas izpildes.
    Service Tracing, OpenTracing un Jaeger
  • Dodieties uz kādu no pēdām un paskatieties, kas tur palēninās.
    Service Tracing, OpenTracing un Jaeger

Turklāt, ja ir zināms kāds pieprasÄ«juma ID, varat atrast izsekoÅ”anu pēc Ŕī ID, izmantojot tagu meklÄ“Å”anu, ja Å”is ID ir reÄ£istrēts izsekoÅ”anas diapazonā.

Š”Š¾ŠŗуŠ¼ŠµŠ½Ń‚Š°Ń†Šøя

Blogs

Video

Avots: www.habr.com

Pievieno komentāru