რა არის OpenTelemetry და როგორ შეუძლია გააუმჯობესოს თქვენი Backend-ის ხარისხი?

წარსულში, როდესაც ჩვენ ვსაუბრობდით ბექენდზე, ჩვეულებრივ ვგულისხმობდით ერთ დიდ აპლიკაციას ერთიანი, დიდი მონაცემთა ბაზით და მონიტორინგისთვის საკმარისი იყო ლოგინგი. ახლა, ისეთი ტექნოლოგიების წყალობით, როგორიცაა , სტანდარტად იქცა. აპლიკაციები უფრო მრავალრიცხოვანი და განაწილებულია და ტრადიციული ჟურნალი აღარ არის საკმარისი ჩვენს აპლიკაციებში პრობლემების და დიაგნოსტიკისთვის. Kubernetes მიკროსერვისები გამართვისა მონიტორინგის ორგანიზებისთვის შესანიშნავი გამოსავალია OpenTelemetry - თანამედროვე ხელსაწყოების ნაკრები, რომელიც შეიძლება გამოყენებულ იქნას განაწილებული სისტემების გამართვისა და შესრულების ანალიზისთვის. ეს სტატია განკუთვნილია IT პროფესიონალებისთვის, რომლებიც ცდილობენ გააფართოვონ თავიანთი ცოდნა backend-ის ოპტიმიზაციაში. ქვემოთ, ჩვენ დეტალურად განვიხილავთ, თუ რა არის OpenTelemetry, მისი ძირითადი ცნებები და პრობლემების გადაჭრაში. თუ გაინტერესებთ, როგორ შეუძლია OpenTelemetry-ს შეცვალოს თქვენი მიდგომა უკანა სისტემების მონიტორინგისა და გამართვის მიმართ, გაზარდოს მათი საიმედოობა და ეფექტურობა - წაიკითხეთ. OpenTelemetry-ის მოკლე ისტორია მსხვილმა ტექნიკურმა კომპანიებმა პირველად 2000-იანი წლების ბოლოს წააწყდნენ ხე-ტყის განაწილებისა და მიკვლევის გამოწვევას. 2010 წელს Google-მა გამოაქვეყნა ნაშრომი, , რომელმაც საფუძველი ჩაუყარა Twitter-ის მოკვლევის ხელსაწყოს Zipkin-ს, რომელიც გამოვიდა 2012 წელს. Dapper, ფართომასშტაბიანი განაწილებული სისტემების მიკვლევის ინფრასტრუქტურა 2014 წელს გაჩნდა Kubernetes, რამაც მნიშვნელოვნად გაამარტივა მიკროსერვისების და ღრუბელში განაწილებული სხვა სისტემების განვითარება. ამან გამოიწვია ის, რომ ბევრ კომპანიას შეექმნა პრობლემები განაწილებული ხე-ტყვისა და მიკვლევით მიკროსერვისებში. განაწილებული ტრასინგის სტანდარტიზაციისთვის შეიქმნა OpenTracing სტანდარტი, მიღებული CNCF-ისა და Google-ის OpenCensus პროექტის მიერ. 2019 წელს, OpenTracing და OpenCensus პროექტებმა გამოაცხადეს შერწყმა OpenTelemetry-ის სახელწოდებით. ეს პლატფორმა აერთიანებს მრავალი წლის განმავლობაში დაგროვილ საუკეთესო პრაქტიკას, რაც საშუალებას იძლევა კვალიფიკაციის, ჟურნალის და მეტრიკის უწყვეტი ინტეგრაცია ნებისმიერ სისტემაში, მიუხედავად მათი სირთულისა. დღეს OpenTelemetry არ არის მხოლოდ პროექტი; ეს არის ინდუსტრიული სტანდარტი ტელემეტრიული მონაცემების შეგროვებისა და გადაცემისთვის. ის შემუშავებულია და მხარს უჭერს სპეციალისტთა და ბაზრის წამყვანი კომპანიების მიერ, როგორიცაა Google და Microsoft. პროექტი აგრძელებს განვითარებას, იძენს ახალ შესაძლებლობებს ინტეგრაციისა და გამოყენების პროცესის გასამარტივებლად. რა არის შიგნით? OpenTelemetry არის პრაქტიკისა და ხელსაწყოების ყოვლისმომცველი ნაკრები, რომელიც განსაზღვრავს, თუ რა სიგნალები შეიძლება გამოიმუშაოს აპლიკაციამ გარე სამყაროსთან ურთიერთობისთვის და როგორ შეიძლება ამ სიგნალების შეგროვება და ვიზუალიზაცია აპლიკაციების და მთლიანად სისტემის მდგომარეობის მონიტორინგისთვის. სიგნალების სამი ძირითადი ტიპია და . კვალიფიკაცია, აღრიცხვა მეტრიკის შეგროვება ** მოდით, უფრო დეტალურად განვიხილოთ თითოეული კომპონენტი: \ კონტექსტები OpenTelemetry წარმოგიდგენთ ოპერაციის კონტექსტების კონცეფციას. კონტექსტი ძირითადად მოიცავს ისეთ ატრიბუტებს, როგორიცაა (იდენტიფიკატორი მიმდინარე ოპერაციისთვის) და (იდენტიფიკატორი ქვემოთხოვნისთვის, ქვემოთხოვნის ყოველი ხელახალი ცდა აქვს უნიკალური ). `trace_id` `span_id` `span_id` გარდა ამისა, კონტექსტი შეიძლება შეიცავდეს სტატიკურ ინფორმაციას, როგორიცაა კვანძის სახელი, სადაც არის აპლიკაცია განლაგებული ან გარემოს სახელი (prod/qa). ეს ველები, რომლებიც ცნობილია როგორც რესურსები OpenTelemetry-ის ტერმინოლოგიაში, ერთვის ყველა ჟურნალს, მეტრულს ან კვალს უფრო ადვილი საძიებლად. კონტექსტები ასევე შეიძლება შეიცავდეს დინამიურ მონაცემებს, როგორიცაა მიმდინარე საბოლოო წერტილის იდენტიფიკატორი ( ), რომელიც შეიძლება შერჩევით დაერთოს ჟურნალების, მეტრიკის ან კვალის ჯგუფებს. `http_path: "GET /user/:id/info"` OpenTelemetry-ის კონტექსტები შეიძლება გადაეცეს სხვადასხვა აპლიკაციებს შორის კონტექსტის გამრავლების პროტოკოლების გამოყენებით. ეს პროტოკოლები შედგება სათაურის კომპლექტებისგან, რომლებიც ემატება ყველა HTTP ან gRPC მოთხოვნას ან რიგების შეტყობინებების სათაურებს. ეს საშუალებას აძლევს ქვედა დინების აპლიკაციებს აღადგინონ ოპერაციის კონტექსტი ამ სათაურებიდან. აქ მოცემულია კონტექსტის გავრცელების რამდენიმე მაგალითი: ეს არის სათაურების ნაკრები ( ), რომელიც თავდაპირველად შეიქმნა Zipkin tracing სისტემისთვის. იგი ადაპტირებული იყო OpenTracing-ში და გამოიყენებოდა მრავალი ხელსაწყოსა და ბიბლიოთეკის მიერ. B3-გავრცელება ატარებს / და დროშას, რომელიც მიუთითებს საჭიროების შემთხვევაში თუ არა ნიმუშის აღება. B3-გავრცელება x-b3-* trace_id span_id შემუშავებული W3C სამუშაო ჯგუფის მიერ, ეს სტანდარტი აერთიანებს კონტექსტის გავრცელების სხვადასხვა მიდგომებს ერთ სტანდარტში და არის ნაგულისხმევი OpenTelemetry-ში. ამ სტანდარტების გამოყენების კარგი მაგალითია მოთხოვნის შესრულების თვალყურის დევნება, რომელიც გადის სხვადასხვა ტექნოლოგიებით დანერგილი მიკროსერვისების მეშვეობით, მონიტორინგისა და გამართვის სიზუსტის კომპრომისის გარეშე. W3C Trace Context მიკვლევა ტრასირება არის მრავალჯერადი მიკროსერვისის მეშვეობით მოთხოვნის გზის ვადების ჩაწერის და შემდგომში ვიზუალიზაციის პროცესი. ვიზუალიზაციაში, თითოეულ ზოლს ეწოდება "span" და აქვს უნიკალური . root span მოიხსენიება როგორც და აქვს , რომელიც ემსახურება როგორც იდენტიფიკატორი მთელი მოთხოვნისთვის. "span_id" "კვალი" "trace_id" ამ ტიპის ვიზუალიზაცია საშუალებას გაძლევთ: გააანალიზეთ მოთხოვნების შესრულების დრო სხვადასხვა სისტემასა და მონაცემთა ბაზაში, რათა გამოავლინოთ ოპტიმიზაცია. გამოავლინეთ ციკლური დამოკიდებულებები სერვისებს შორის. იპოვეთ დუბლიკატი მოთხოვნები. კვალიფიკაციის მონაცემების გამოყენებით, თქვენ ასევე შეგიძლიათ შექმნათ დამატებითი ანალიტიკა, როგორიცაა მიკროსერვისების რუკის შექმნა ან დროის განაწილება სხვადასხვა სისტემაში ოპერაციის დამუშავების დროს. მაშინაც კი, თუ არ იყენებთ კვალის მონაცემებს ვადების ვიზუალიზაციისთვის, OpenTelemetry მაინც ქმნის და სხვა სიგნალებში გამოსაყენებლად. trace_id span_id ჟურნალები მიუხედავად მისი აშკარა სიმარტივისა, ხე-ტყე რჩება პრობლემების დიაგნოსტიკის ერთ-ერთ ყველაზე მძლავრ ინსტრუმენტად. OpenTelemetry აძლიერებს ტრადიციულ ხეს კონტექსტური ინფორმაციის დამატებით. კონკრეტულად, თუ აქტიური კვალი არსებობს, "trace_id" და "span_id" ატრიბუტები ავტომატურად ემატება ჟურნალებს, რომლებიც აკავშირებს მათ კვალის ვადებს. გარდა ამისა, ჟურნალის ატრიბუტები შეიძლება შეიცავდეს სტატიკურ ინფორმაციას OpenTelemetry კონტექსტიდან, როგორიცაა კვანძის იდენტიფიკატორი, ისევე როგორც დინამიური ინფორმაცია, როგორიცაა მიმდინარე HTTP ბოლო წერტილის იდენტიფიკატორი (`http_path: "GET /user/:id"`). `trace_id`-ის გამოყენებით, შეგიძლიათ იპოვოთ ჟურნალები ყველა მიკროსერვისიდან, რომელიც დაკავშირებულია მიმდინარე მოთხოვნასთან, ხოლო `span_id` საშუალებას გაძლევთ განასხვავოთ ქვემოთხოვნები. მაგალითად, ხელახალი ცდების შემთხვევაში, სხვადასხვა მცდელობის ჟურნალებს განსხვავებული `span_id` ექნება. ამ იდენტიფიკატორების გამოყენება საშუალებას იძლევა რეალურ დროში მთელი სისტემის ქცევის სწრაფი ანალიზი, პრობლემის დიაგნოსტიკის დაჩქარება და სტაბილურობისა და საიმედოობის გაძლიერება. მეტრიკა მეტრიკის კოლექცია უზრუნველყოფს რაოდენობრივ მონაცემებს სისტემის მუშაობის შესახებ, როგორიცაა შეყოვნება, შეცდომის სიხშირე, რესურსების გამოყენება და სხვა. მეტრიკის რეალურ დროში მონიტორინგი საშუალებას გაძლევთ სწრაფად უპასუხოთ მუშაობის ცვლილებებს, თავიდან აიცილოთ წარუმატებლობები და რესურსების ამოწურვა და უზრუნველყოთ აპლიკაციის მაღალი ხელმისაწვდომობა და საიმედოობა მომხმარებლებისთვის. მეტრულ შენახვისა და ვიზუალიზაციის სისტემებთან ინტეგრაცია, როგორიცაა Prometheus და Grafana, ამარტივებს ამ მონაცემების ვიზუალიზაციას, რაც მნიშვნელოვნად ამარტივებს მონიტორინგს. მეტრული კოლექციონერები OpenTelemetry მეტრულ კოლექტორები თავსებადია Prometheus-ისა და OpenMetrics-ის სტანდარტებთან, რაც საშუალებას იძლევა ადვილად გადავიდეს OpenTelemetry გადაწყვეტილებებზე მნიშვნელოვანი ცვლილებების გარეშე. OpenTelemetry SDK საშუალებას იძლევა trace_id მაგალითების ექსპორტირება მეტრიკასთან ერთად, რაც შესაძლებელს გახდის მეტრიკის კორელაციას ჟურნალის მაგალითებთან და კვალთან. სიგნალის კორელაცია ჟურნალები, მეტრიკა და მიკვლევა ერთად ქმნის სისტემის მდგომარეობის ყოვლისმომცველ ხედვას: ჟურნალები გვაწვდიან ინფორმაციას სისტემის მოვლენების შესახებ, რაც იძლევა შეცდომების სწრაფ იდენტიფიკაციას და გადაჭრას. მეტრიკა ასახავს სისტემის ხარისხობრივ და რაოდენობრივ შესრულების ინდიკატორებს, როგორიცაა რეაგირების დრო ან შეცდომის მაჩვენებელი. Tracing ავსებს ამ ხედვას მოთხოვნის შესრულების გზის ჩვენებით სისტემის სხვადასხვა კომპონენტების მეშვეობით, რაც ხელს უწყობს მათი ურთიერთდამოკიდებულების გაგებას. აშკარა კორელაცია ჟურნალებს, კვალსა და მეტრიკას შორის არის OpenTelemetry-ის გამორჩეული თვისება. მაგალითად, Grafana საშუალებას აძლევს მომხმარებლებს დაინახონ შესაბამისი კვალი და მოითხოვონ მეტრიკა ჟურნალის ნახვისას, რაც მნიშვნელოვნად აძლიერებს პლატფორმის გამოყენებადობას და ეფექტურობას. სამი ძირითადი კომპონენტის გარდა, OpenTelemetry მოიცავს ნიმუშის აღების, ბარგის და ოპერაციის კონტექსტის მართვის ცნებებს. სინჯის აღება მაღალი დატვირთვის სისტემებში, ჟურნალების და კვალის მოცულობა ხდება უზარმაზარი, რაც მოითხოვს მნიშვნელოვან რესურსებს ინფრასტრუქტურისა და მონაცემთა შენახვისთვის. ამ პრობლემის გადასაჭრელად, OpenTelemetry სტანდარტები მოიცავს სიგნალის სინჯს - კვალისა და ჟურნალების მხოლოდ ნაწილის ექსპორტის შესაძლებლობას. მაგალითად, შეგიძლიათ დეტალური სიგნალების ექსპორტი მოთხოვნის პროცენტიდან, გრძელვადიანი მოთხოვნებიდან ან შეცდომის მოთხოვნებიდან. ეს მიდგომა იძლევა საკმარისი შერჩევის საშუალებას სტატისტიკის შესაქმნელად, მნიშვნელოვანი რესურსების დაზოგვისას. თუმცა, თუ თითოეული სისტემა დამოუკიდებლად გადაწყვეტს, რომელი მოთხოვნების დეტალურად მონიტორინგი, ჩვენ მივიღებთ თითოეული მოთხოვნის ფრაგმენტულ ხედვას. ზოგიერთ სისტემას შეუძლია დეტალური მონაცემების ექსპორტი, ზოგი კი მხოლოდ ნაწილობრივ ან საერთოდ არ ექსპორტს. ამ პრობლემის გადასაჭრელად, OpenTelemetry-ის კონტექსტური გამრავლების მექანიზმები გადასცემს შერჩევის დროშას `trace_id`/`span_id`-თან ერთად. ეს უზრუნველყოფს, რომ თუ პირველადი სერვისი, რომელიც იღებს მომხმარებლის მოთხოვნას, გადაწყვეტს, რომ მოთხოვნა დეტალურად უნდა იყოს მონიტორინგი, ყველა სხვა სისტემა მოჰყვება მას. წინააღმდეგ შემთხვევაში, ყველა სისტემამ ნაწილობრივ ან არ უნდა გაიტანოს სიგნალები რესურსების შესანარჩუნებლად. ამ მიდგომას ეწოდება "Head Sampling" - გადაწყვეტილება, რომელიც მიიღება მოთხოვნის დამუშავების დასაწყისში, შემთხვევით ან რამდენიმე შეყვანის ატრიბუტზე დაყრდნობით. გარდა ამისა, OpenTelemetry მხარს უჭერს "Tail Sampling", სადაც ყველა აპლიკაცია ყოველთვის დეტალურად ახდენს ყველა სიგნალის ექსპორტს, მაგრამ შუალედური ბუფერი არსებობს. ყველა მონაცემის შეგროვების შემდეგ, ეს ბუფერი წყვეტს, შეინარჩუნოს სრული მონაცემები თუ შეინახოს მხოლოდ ნაწილობრივი ნიმუში. ეს მეთოდი იძლევა თითოეული მოთხოვნის კატეგორიის (წარმატებული/გრძელი/შეცდომა) უფრო წარმომადგენლობითი ნიმუშის მიღების საშუალებას, მაგრამ საჭიროებს დამატებით ინფრასტრუქტურის დაყენებას. ბარგი ბარგის მექანიზმი საშუალებას იძლევა გადაიცეს თვითნებური გასაღები-მნიშვნელობის წყვილები / თან ერთად, რომლებიც ავტომატურად გაივლის ყველა მიკროსერვისს შორის მოთხოვნის დამუშავების დროს. ეს სასარგებლოა მოთხოვნის გზაზე საჭირო დამატებითი ინფორმაციის გადასაცემად, როგორიცაა მომხმარებლის ინფორმაცია ან გაშვების გარემოს პარამეტრები. trace_id span_id W3C სტანდარტის მიხედვით ბარგის გადაცემის სათაურის მაგალითი: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5 აქ მოცემულია ბარგის გამოყენების რამდენიმე მაგალითი: , როგორიცაა , , ან შეიძლება გაიცეს ყველა მიკროსერვისში. აპლიკაციებს შეუძლიათ ავტომატურად დაარეგისტრირონ ეს ინფორმაცია, რაც შესაძლებელს გახდის მომხმარებლის კონტექსტის მოძიებას ორიგინალური მოთხოვნისთვის. ბიზნეს კონტექსტის ინფორმაციის გადაცემა userId productId deviceId პარამეტრები SDK-ებისთვის ან ინფრასტრუქტურისთვის. სპეციფიკური კონფიგურაციის პარამეტრების დროშები, რომლებიც ეხმარება დატვირთვის ბალანსერებს მარშრუტიზაციის გადაწყვეტილებების მიღებაში. ტესტირების დროს, ზოგიერთი მოთხოვნა შეიძლება საჭირო გახდეს იმიტირებული ბექენდებისთვის. იმის გამო, რომ ბარგი ავტომატურად იგზავნება ყველა სერვისით, არ არის საჭირო დამატებითი პროტოკოლების შექმნა - უბრალოდ დააწესეთ წესი დატვირთვის ბალანსერზე. Routing Flags გაითვალისწინეთ, რომ მიუხედავად იმისა, რომ ბარგის შესრულებაზე გავლენა მინიმალურია, გადაჭარბებულმა გამოყენებამ შეიძლება მნიშვნელოვნად გაზარდოს ქსელისა და სერვისის დატვირთვა. გულდასმით აირჩიეთ, რომელი მონაცემების გადატანა ნამდვილად გჭირდებათ ბარგის მეშვეობით, რათა თავიდან აიცილოთ მუშაობის პრობლემები. ინფრასტრუქტურის დანერგვა OpenTelemetry-ის დანერგვა ინფრასტრუქტურის დონეზე გულისხმობს OpenTelemetry-ის აპლიკაციის არქიტექტურაში ინტეგრირებას და ინფრასტრუქტურის კონფიგურაციას მონაცემთა აგრეგაციისთვის. პროცესი შედგება ოთხი ეტაპისგან: პირველ ეტაპზე, OpenTelemetry SDK პირდაპირ ინტეგრირებულია აპლიკაციებში, რათა შეაგროვოს მეტრიკა, ჟურნალი და კვალი, რაც უზრუნველყოფს მონაცემთა უწყვეტ ნაკადს სისტემის თითოეული კომპონენტის მუშაობის შესახებ. აპლიკაციის ინტეგრაცია შეგროვებული მონაცემები გადაიგზავნება აპლიკაციებიდან ექსპორტიორების მეშვეობით გარე სისტემებში შემდგომი დამუშავებისთვის, როგორიცაა აღრიცხვა, მონიტორინგი, მიკვლევა ან ანალიტიკური სისტემები, თქვენი საჭიროებიდან გამომდინარე. ექსპორტიორების კონფიგურაცია ეს ეტაპი შეიძლება მოიცავდეს მონაცემების ნორმალიზებას, დამატებითი ინფორმაციის გამდიდრებას და სხვადასხვა წყაროს მონაცემების გაერთიანებას სისტემის მდგომარეობის ერთიანი ხედვის შესაქმნელად. აგრეგაცია და შენახვა და ბოლოს, დამუშავებული მონაცემები წარმოდგენილია როგორც დაფები ისეთ სისტემებში, როგორიცაა Grafana (მეტრიკისა და კვალისთვის) ან Kibana (ლოგისთვის). ეს საშუალებას აძლევს გუნდებს სწრაფად შეაფასონ სისტემის ჯანმრთელობა, დაადგინონ პრობლემები და ტენდენციები და დააყენონ გაფრთხილებები გენერირებული სიგნალების საფუძველზე. მონაცემთა ვიზუალიზაცია განაცხადის განხორციელება აპლიკაციასთან ინტეგრირებისთვის, თქვენ უნდა დააკავშიროთ შესაბამისი OpenTelemetry SDK გამოყენებული პროგრამირების ენისთვის ან გამოიყენოთ ბიბლიოთეკები და ჩარჩოები, რომლებიც პირდაპირ მხარს უჭერენ OpenTelemetry-ს. OpenTelemetry ხშირად ახორციელებს ფართოდ გავრცელებულ ინტერფეისებს ცნობილი ბიბლიოთეკებიდან, რაც საშუალებას აძლევს ჩანაცვლებას. მაგალითად, Micrometer ბიბლიოთეკა ჩვეულებრივ გამოიყენება ჯავის ეკოსისტემაში მეტრიკის შეგროვებისთვის. OpenTelemetry SDK უზრუნველყოფს მიკრომეტრის ინტერფეისების დანერგვას, რაც საშუალებას აძლევს მეტრულ ექსპორტს ძირითადი აპლიკაციის კოდის შეცვლის გარეშე. უფრო მეტიც, OpenTelemetry გთავაზობთ ძველი OpenTracing და OpenCensus ინტერფეისების განხორციელებას, რაც ხელს უწყობს OpenTelemetry-ში გლუვ მიგრაციას. დასკვნა IT სისტემებში OpenTelemetry შეიძლება გახდეს საიმედო და ეფექტური ბექენდების მომავლის გასაღები. ეს ინსტრუმენტი ამარტივებს გამართვას და მონიტორინგს და ასევე ხსნის შესაძლებლობებს აპლიკაციის მუშაობისა და ოპტიმიზაციის ახალ დონეზე ღრმა გაგებისთვის. შეუერთდით OpenTelemetry საზოგადოებას, რათა დაეხმაროთ მომავლის ჩამოყალიბებას, სადაც backend-ის განვითარება უფრო მარტივი და ეფექტურია!