Service Tracing, OpenTracing და Jaeger

ჩვენ ვიყენებთ მიკროსერვისის არქიტექტურას ჩვენს პროექტებში. როდესაც შესრულების შეფერხებები ხდება, დიდი დრო იხარჯება ჟურნალების მონიტორინგზე და ანალიზზე. ცალკეული ოპერაციების ვადების ჩაწერისას ჟურნალის ფაილში, როგორც წესი, ძნელია იმის გაგება, თუ რამ გამოიწვია ამ ოპერაციების გამოძახება, თვალყური ადევნო მოქმედებების თანმიმდევრობას ან ერთი ოპერაციის დროის ცვლას მეორესთან შედარებით სხვადასხვა სერვისებში.

ხელით შრომის შესამცირებლად, ჩვენ გადავწყვიტეთ გამოგვეყენებინა თვალის მიდევნების ერთ-ერთი ინსტრუმენტი. იმის შესახებ, თუ როგორ და რატომ შეგიძლიათ გამოიყენოთ მიკვლევა და როგორ გავაკეთეთ ეს, და განხილული იქნება ამ სტატიაში.

რა პრობლემების გადაჭრა შესაძლებელია მოკვლევით

1. იპოვნეთ შესრულების შეფერხებები როგორც ერთ სერვისში, ასევე აღსრულების მთელ ხეში ყველა მონაწილე სერვისს შორის. Მაგალითად:
   • მრავალი მოკლე თანმიმდევრული ზარი სერვისებს შორის, მაგალითად, გეოკოდირებაზე ან მონაცემთა ბაზაში.
   • ხანგრძლივი I/O ლოდინი, როგორიცაა ქსელის გადარიცხვები ან დისკის წაკითხვა.
   • გრძელი მონაცემების ანალიზი.
   • ხანგრძლივი ოპერაციები, რომლებიც საჭიროებენ პროცესორს.
   • კოდის სექციები, რომლებიც არ არის საჭირო საბოლოო შედეგის მისაღებად და შეიძლება წაიშალოს ან გადაიდოს.
2. ნათლად გაიგე რა თანმიმდევრობით რას ჰქვია და რა ხდება ოპერაციის შესრულებისას.
   
   ჩანს, რომ, მაგალითად, მოთხოვნა მოვიდა WS სერვისში -> WS სერვისმა შეავსო მონაცემები R სერვისის მეშვეობით -> შემდეგ გაუგზავნა მოთხოვნა V სერვისს -> V სერვისმა ჩატვირთა ბევრი მონაცემი R სერვისი -> გადავიდა P სერვისზე -> P სერვისი კვლავ გადავიდა სერვისზე R -> სერვისმა V უგულებელყო შედეგი და გადავიდა J სერვისზე -> და მხოლოდ ამის შემდეგ დააბრუნა პასუხი სერვისზე WS, ხოლო განაგრძო სხვა რამის გამოთვლა ფონი.
   მთელი პროცესისთვის ასეთი კვალის ან დეტალური დოკუმენტაციის გარეშე, ძალიან რთულია იმის გაგება, თუ რა ხდება კოდის პირველად დათვალიერებისას და კოდი მიმოფანტულია სხვადასხვა სერვისებში და იმალება ურნებისა და ინტერფეისების მიღმა.
3. ინფორმაციის შეგროვება შესრულების ხის შესახებ შემდგომი გადავადებული ანალიზისთვის. შესრულების თითოეულ ეტაპზე, შეგიძლიათ დაამატოთ ინფორმაცია კვალზე, რომელიც ხელმისაწვდომია ამ ეტაპზე და შემდეგ გაარკვიოთ, თუ რა შეყვანის მონაცემებმა გამოიწვია მსგავსი სცენარი. Მაგალითად:
   • მომხმარებლის იდენტიფიკაცია
   • უფლებები
   • შერჩეული მეთოდის ტიპი
   • ჟურნალის ან შესრულების შეცდომა
4. კვალის გადაქცევა მეტრიკის ქვეჯგუფად და შემდგომი ანალიზი უკვე მეტრიკის სახით.

რა კვალს შეუძლია შესვლა. სპანი

ტრასირებაში არის span-ის ცნება, ეს არის ერთი ჟურნალის ანალოგი კონსოლის. სპა აქვს:

• სახელი, ჩვეულებრივ მეთოდის სახელი, რომელიც შესრულდა
• სერვისის დასახელება, რომელშიც წარმოიქმნა სპანი
• საკუთარი უნიკალური ID
• ერთგვარი მეტა ინფორმაცია გასაღების/მნიშვნელობის სახით, რომელიც შესულია მასში. მაგალითად, მეთოდის პარამეტრები ან მეთოდი დასრულდა შეცდომით თუ არა
• დაწყების და დასრულების დროები ამ პერიოდისთვის
• მშობლის დიაპაზონის ID

თითოეული span იგზავნება span კოლექციონერში, რათა შეინახოს მონაცემთა ბაზაში შემდგომი განხილვისთვის, როგორც კი იგი დაასრულებს მის შესრულებას. სამომავლოდ, თქვენ შეგიძლიათ ააწყოთ ყველა სივრცის ხე მშობლის ID-ით დაკავშირებით. გაანალიზებისას შეგიძლიათ იპოვოთ, მაგალითად, ყველა ის მონაკვეთი ზოგიერთ სერვისში, რომელსაც გარკვეული დრო დასჭირდა. გარდა ამისა, კონკრეტულ დიაპაზონზე გადასვლით, იხილეთ მთელი ხე ამ ფართის ზემოთ და ქვემოთ.

Opentrace, Jagger და როგორ განვახორციელეთ ის ჩვენი პროექტებისთვის

არსებობს საერთო სტანდარტი ღია კვალი, რომელიც აღწერს როგორ და რა უნდა შეგროვდეს, რომელიმე ენაზე კონკრეტულ განხორციელებასთან მიბმულობის გარეშე. მაგალითად, ჯავაში, კვალთან ყველა სამუშაო ხორციელდება საერთო Opentrace API-ის საშუალებით, ხოლო მის ქვეშ, მაგალითად, Jaeger ან ცარიელი ნაგულისხმევი განხორციელება, რომელიც არაფერს აკეთებს, შეიძლება დამალული იყოს.
ჩვენ ვიყენებთ Jaeger როგორც Opentrace-ის განხორციელება. იგი შედგება რამდენიმე კომპონენტისგან:

• Jaeger-agent არის ლოკალური აგენტი, რომელიც ჩვეულებრივ დამონტაჟებულია თითოეულ მანქანაზე და სერვისები შესულია მასში ლოკალურ ნაგულისხმევ პორტზე. თუ აგენტი არ არის, მაშინ ამ აპარატზე ყველა სერვისის კვალი ჩვეულებრივ გამორთულია
• Jaeger-collector - ყველა აგენტი უგზავნის მას შეგროვებულ კვალს და ათავსებს მათ შერჩეულ მონაცემთა ბაზაში
• მონაცემთა ბაზა მათთვის სასურველი კასანდრაა, მაგრამ ჩვენ ვიყენებთ elasticsearch-ს, არის დანერგვა რამდენიმე სხვა მონაცემთა ბაზისთვის და მეხსიერებაში დანერგვა, რომელიც არაფერს ინახავს დისკზე
• Jaeger-query არის სერვისი, რომელიც მიდის მონაცემთა ბაზაში და აბრუნებს უკვე შეგროვებულ კვალს ანალიზისთვის
• Jaeger-ui არის ვებ ინტერფეისი კვალის საძიებლად და სანახავად, ის გადადის jaeger-query-ზე

ცალკე კომპონენტად შეიძლება ეწოდოს opentrace jaeger-ის იმპლემენტაცია კონკრეტული ენებისთვის, რომლის მეშვეობითაც spans იგზავნება jaeger-agent-ზე.
ჯაგერის დაკავშირება ჯავაში მოდის io.opentracing.Tracer ინტერფეისის დანერგვაზე, რის შემდეგაც მასში არსებული ყველა კვალი გადაფრინდება რეალურ აგენტამდე.

ასევე საგაზაფხულო კომპონენტისთვის, შეგიძლიათ დაკავშირება opentracing-spring-cloud-starter და განხორციელება Jaeger-ისგან opentracing-spring-jaeger-cloud-starter რომელიც ავტომატურად დააკონფიგურირებს ტრასირებას ყველაფერზე, რაც გადის ამ კომპონენტებზე, მაგალითად, http მოთხოვნები კონტროლერებისთვის, მოთხოვნა მონაცემთა ბაზაში jdbc-ის მეშვეობით და ა.შ.

ჯავაში შესვლის კვალი

სადღაც ზედა დონეზე, პირველი Span უნდა შეიქმნას, ეს შეიძლება გაკეთდეს ავტომატურად, მაგალითად, ზამბარის კონტროლერის მიერ მოთხოვნის მიღებისას, ან ხელით, თუ არ არის. შემდეგ ის გადაიცემა ქვემოთ მოცემული სკოპით. თუ ქვემოთ მოცემულ რომელიმე მეთოდს სურს დაამატოთ Span, ის იღებს მიმდინარე activeSpan-ს Scope-დან, ქმნის ახალ Span-ს და ამბობს, რომ მისი მშობელი არის მიღებული activeSpan და ააქტიურებს ახალ Span-ს. გარე სერვისების გამოძახებისას, მიმდინარე აქტიური დიაპაზონი გადაეცემა მათ და ეს სერვისები ქმნიან ახალ სპანებს ამ დიაპაზონის მითითებით.
ყველა სამუშაო გადის Tracer ინსტანციაზე, შეგიძლიათ მიიღოთ ის DI მექანიზმით, ან GlobalTracer.get () როგორც გლობალური ცვლადი, თუ DI მექანიზმი არ მუშაობს. ნაგულისხმევად, თუ ტრასერი არ არის ინიციალიზებული, NoopTracer დაბრუნდება, რომელიც არაფერს აკეთებს.
გარდა ამისა, მიმდინარე სკოპი მიიღება ტრასერისგან ScopeManager-ის მეშვეობით, იქმნება ახალი სკოპი ამჟამინდელიდან ახალი სპანის შეკვრით, შემდეგ კი შექმნილი Scope იხურება, რომელიც ხურავს შექმნილ დიაპაზონს და აბრუნებს წინა Scope-ს. აქტიური მდგომარეობა. ფარგლები მიბმულია ძაფზე, ასე რომ, როდესაც პროგრამირება მრავალ ძაფზეა, არ უნდა დაგვავიწყდეს აქტიური სპანის სხვა ძაფზე გადატანა, სხვა ძაფის არეალის შემდგომი გააქტიურებისთვის ამ დიაპაზონის მითითებით.

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

მრავალ ძაფიანი პროგრამირებისთვის, ასევე არის TracedExecutorService და მსგავსი შეფუთვები, რომლებიც ავტომატურად აგზავნიან მიმდინარე სპანს თემაში, როდესაც ასინქრონული ამოცანები გაშვებულია:

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

გარე http მოთხოვნებისთვის არის TracingHttpClient

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

პრობლემები, რომლებიც შეგვხვდა

• ლობიო და DI ყოველთვის არ მუშაობს, თუ ტრასერი არ გამოიყენება სერვისში ან კომპონენტში, მაშინ ავტომატური გაყვანილობა Tracer შეიძლება არ იმუშაოს და მოგიწევთ გამოიყენოთ GlobalTracer.get().
• ანოტაციები არ მუშაობს, თუ ის არ არის კომპონენტი ან სერვისი, ან თუ მეთოდი გამოიძახება იმავე კლასის მეზობელი მეთოდიდან. ფრთხილად უნდა იყოთ, შეამოწმოთ რა მუშაობს და გამოიყენოთ ხელით კვალის შექმნა, თუ @Traced არ მუშაობს. თქვენ ასევე შეგიძლიათ დაურთოთ დამატებითი შემდგენელი ჯავას ანოტაციებისთვის, შემდეგ ისინი ყველგან უნდა მუშაობდნენ.
• ძველ გაზაფხულზე და ზამბარის ჩატვირთვაში, opentraing გაზაფხულზე ღრუბლის ავტოკონფიგურაცია არ მუშაობს DI-ში შეცდომების გამო, მაშინ თუ გსურთ, რომ ზამბარის კომპონენტებში კვალი ავტომატურად იმუშაოს, შეგიძლიათ ამის გაკეთება ანალოგიით. 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-ში, თქვენ უნდა გამოიყენოთ try საბოლოოდ.
• თითოეულ სერვისს უნდა ჰქონდეს თავისი spring.application.name, რომლის მიხედვითაც მოხდება კვალი აღრიცხვა. რას ნიშნავს ცალკე სახელი გაყიდვა და ტესტი, რათა არ ჩაერიოს მათ ერთად.
• თუ იყენებთ GlobalTracer-ს და tomcat-ს, მაშინ ამ ტომკატში გაშვებულ ყველა სერვისს აქვს ერთი GlobalTracer, ასე რომ მათ ექნებათ ერთი და იგივე სერვისის სახელი.
• მეთოდზე კვალის დამატებისას, დარწმუნებული უნდა იყოთ, რომ ის ბევრჯერ არ არის გამოძახებული მარყუჟში. აუცილებელია ყველა ზარისთვის ერთი საერთო კვალის დამატება, რაც მთლიანი სამუშაო დროის გარანტიას იძლევა. წინააღმდეგ შემთხვევაში, შეიქმნება ზედმეტი დატვირთვა.
• ერთხელ ჯეგერ-უიში, ძალიან დიდი მოთხოვნა იყო დიდი რაოდენობით კვალის შესახებ და რადგან პასუხს არ დაელოდნენ, ისევ გააკეთეს. შედეგად, jaeger-query-მ დაიწყო ბევრი მეხსიერების ჭამა და ელასტიური შენელება. დაეხმარა jaeger-query-ის გადატვირთვით

კვალის აღება, შენახვა და დათვალიერება

არსებობს სამი ტიპი სინჯის კვალი:

1. Const რომელიც აგზავნის და ინახავს ყველა კვალს.
2. სავარაუდო, რომელიც ფილტრავს კვალს გარკვეული ალბათობით.
3. რატელიმიტირება, რომელიც ზღუდავს კვალის რაოდენობას წამში. ამ პარამეტრების კონფიგურაცია შეგიძლიათ კლიენტზე, jaeger-agent-ზე ან კოლექციონერზე. ახლა ჩვენ ვიყენებთ const 1-ს შემფასებლის დასტაში, რადგან არც თუ ისე ბევრი მოთხოვნაა, მაგრამ მათ დიდი დრო სჭირდება. მომავალში, თუ ეს სისტემაზე ზედმეტ დატვირთვას მოახდენს, შეგიძლიათ შეზღუდოთ იგი.

თუ იყენებთ კასანდრას, მაშინ ნაგულისხმევად ის ინახავს კვალს მხოლოდ ორი დღის განმავლობაში. ჩვენ ვიყენებთ ელასტიური და კვალი ინახება ყველა დროის განმავლობაში და არ იშლება. თითოეული დღისთვის იქმნება ცალკე ინდექსი, მაგალითად jaeger-service-2019-03-04. მომავალში, თქვენ უნდა დააკონფიგურიროთ ძველი კვალის ავტომატური გაწმენდა.

კვალის სანახავად გჭირდებათ:

• აირჩიეთ სერვისი, რომლითაც გსურთ კვალის გაფილტვრა, მაგალითად, tomcat7-default სერვისისთვის, რომელიც მუშაობს tomcat-ში და არ შეიძლება ჰქონდეს საკუთარი სახელი.
• შემდეგ აირჩიეთ ოპერაცია, დროის ინტერვალი და მინიმალური ოპერაციის დრო, მაგალითად, 10 წამიდან, მხოლოდ ხანგრძლივი შესრულებისთვის.
  
• მიდი ერთ-ერთ კვალზე და ნახე რა ანელებდა იქ.
  

ასევე, თუ ზოგიერთი მოთხოვნის id ცნობილია, მაშინ შეგიძლიათ იპოვოთ კვალი ამ id-ით თეგის ძიების საშუალებით, თუ ეს id არის შესული ტრასის დიაპაზონში.

დოკუმენტაცია

• opentracing დოკუმენტაცია opentracing.io/docs/overview/what-is-tracing
• ჯეგერის დოკუმენტაცია www.jaegertracing.io/docs/1.10
• Jaeger java კავშირი github.com/jaegertracing/jaeger-client-java
• გაზაფხულზე ღია ტრასირების კავშირი
  github.com/jaegertracing/jaeger-client-java
  github.com/opentracing-contrib/java-spring-cloud

სტატიები

• habr.com/ru/company/carprice/blog/340946 Jaeger Opentracing და Microservices რეალურ PHP და Golang პროექტში
• www.uber.com/distributed-tracing განვითარებადი განაწილებული კვალი Uber Engineering-ში
• opentracing.io/guides/java
• medium.com/jaegertracing/running-jaeger-agent-on-bare-metal-d1fc47d31fab Jaeger Agent-ის გაშვება შიშველ მეტალზე

ვიდეო

• www.youtube.com/watch?v=qg0ENOdP1Lo როგორ გამოვიყენეთ იაგერი და პრომეთე ელვისებური სწრაფი მომხმარებლის მოთხოვნების მისაწოდებლად - ბრაიან ბორეჰემი
• www.youtube.com/watch?v=WRntQsUajow შესავალი: Jaeger - იური შკურო, Uber & Pavol Loffay, Red Hat
• www.youtube.com/watch?v=fsHb0qK37bc სერგეი იაკოვლევი, "დიდი გამარჯვების პატარა ისტორია: OpenTracing, AWS და Jaeger"

წყარო: www.habr.com