წარსულში, როდესაც ჩვენ ვსაუბრობდით ბექენდზე, ჩვეულებრივ ვგულისხმობდით ერთ დიდ აპლიკაციას ერთიანი, დიდი მონაცემთა ბაზით და მონიტორინგისთვის საკმარისი იყო ლოგინგი. ახლა, ისეთი ტექნოლოგიების წყალობით, როგორიცაა Kubernetes , მიკროსერვისები სტანდარტად იქცა. აპლიკაციები უფრო მრავალრიცხოვანი და განაწილებულია და ტრადიციული ჟურნალი აღარ არის საკმარისი ჩვენს აპლიკაციებში პრობლემების გამართვისა და დიაგნოსტიკისთვის.
მონიტორინგის ორგანიზებისთვის შესანიშნავი გამოსავალია OpenTelemetry - თანამედროვე ხელსაწყოების ნაკრები, რომელიც შეიძლება გამოყენებულ იქნას განაწილებული სისტემების გამართვისა და შესრულების ანალიზისთვის.
ეს სტატია განკუთვნილია IT პროფესიონალებისთვის, რომლებიც ცდილობენ გააფართოვონ თავიანთი ცოდნა backend-ის ოპტიმიზაციაში. ქვემოთ, ჩვენ დეტალურად განვიხილავთ, თუ რა არის OpenTelemetry, მისი ძირითადი ცნებები და პრობლემების გადაჭრაში. თუ გაინტერესებთ, როგორ შეუძლია OpenTelemetry-ს შეცვალოს თქვენი მიდგომა უკანა სისტემების მონიტორინგისა და გამართვის მიმართ, გაზარდოს მათი საიმედოობა და ეფექტურობა - წაიკითხეთ.
მსხვილმა ტექნიკურმა კომპანიებმა პირველად 2000-იანი წლების ბოლოს წააწყდნენ ხე-ტყის განაწილებისა და მიკვლევის გამოწვევას. 2010 წელს Google-მა გამოაქვეყნა ნაშრომი,
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 მოთხოვნას ან რიგების შეტყობინებების სათაურებს. ეს საშუალებას აძლევს ქვედა დინების აპლიკაციებს აღადგინონ ოპერაციის კონტექსტი ამ სათაურებიდან.
აქ მოცემულია კონტექსტის გავრცელების რამდენიმე მაგალითი:
B3-გავრცელება ეს არის სათაურების ნაკრები ( x-b3-*
), რომელიც თავდაპირველად შეიქმნა Zipkin tracing სისტემისთვის. იგი ადაპტირებული იყო OpenTracing-ში და გამოიყენებოდა მრავალი ხელსაწყოსა და ბიბლიოთეკის მიერ. B3-გავრცელება ატარებს trace_id
/ span_id
და დროშას, რომელიც მიუთითებს საჭიროების შემთხვევაში თუ არა ნიმუშის აღება.
W3C Trace Context შემუშავებული W3C სამუშაო ჯგუფის მიერ, ეს სტანდარტი აერთიანებს კონტექსტის გავრცელების სხვადასხვა მიდგომებს ერთ სტანდარტში და არის ნაგულისხმევი OpenTelemetry-ში. ამ სტანდარტების გამოყენების კარგი მაგალითია მოთხოვნის შესრულების თვალყურის დევნება, რომელიც გადის სხვადასხვა ტექნოლოგიებით დანერგილი მიკროსერვისების მეშვეობით, მონიტორინგისა და გამართვის სიზუსტის კომპრომისის გარეშე.
ტრასირება არის მრავალჯერადი მიკროსერვისის მეშვეობით მოთხოვნის გზის ვადების ჩაწერის და შემდგომში ვიზუალიზაციის პროცესი.
ვიზუალიზაციაში, თითოეულ ზოლს ეწოდება "span" და აქვს უნიკალური "span_id" . root span მოიხსენიება როგორც "კვალი" და აქვს "trace_id" , რომელიც ემსახურება როგორც იდენტიფიკატორი მთელი მოთხოვნისთვის.
ამ ტიპის ვიზუალიზაცია საშუალებას გაძლევთ:
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 მაგალითების ექსპორტირება მეტრიკასთან ერთად, რაც შესაძლებელს გახდის მეტრიკის კორელაციას ჟურნალის მაგალითებთან და კვალთან.
ჟურნალები, მეტრიკა და მიკვლევა ერთად ქმნის სისტემის მდგომარეობის ყოვლისმომცველ ხედვას:
სამი ძირითადი კომპონენტის გარდა, 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-ის განვითარება უფრო მარტივი და ეფექტურია!