paint-brush
რა არის OpenTelemetry და როგორ შეუძლია გააუმჯობესოს თქვენი Backend-ის ხარისხი? მიერ@ymatigoosa
39,510 საკითხავი
39,510 საკითხავი

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

მიერ Dmitrii Pakhomov8m2024/06/19
Read on Terminal Reader
Read this story w/o Javascript

Ძალიან გრძელი; Წაკითხვა

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

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - რა არის OpenTelemetry და როგორ შეუძლია გააუმჯობესოს თქვენი Backend-ის ხარისხი?
Dmitrii Pakhomov HackerNoon profile picture
0-item

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

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


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


OpenTelemetry-ის მოკლე ისტორია

მსხვილმა ტექნიკურმა კომპანიებმა პირველად 2000-იანი წლების ბოლოს წააწყდნენ ხე-ტყის განაწილებისა და მიკვლევის გამოწვევას. 2010 წელს Google-მა გამოაქვეყნა ნაშრომი, Dapper, ფართომასშტაბიანი განაწილებული სისტემების მიკვლევის ინფრასტრუქტურა , რომელმაც საფუძველი ჩაუყარა Twitter-ის მოკვლევის ხელსაწყოს Zipkin-ს, რომელიც გამოვიდა 2012 წელს.


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 მოთხოვნას ან რიგების შეტყობინებების სათაურებს. ეს საშუალებას აძლევს ქვედა დინების აპლიკაციებს აღადგინონ ოპერაციის კონტექსტი ამ სათაურებიდან.


აქ მოცემულია კონტექსტის გავრცელების რამდენიმე მაგალითი:

  1. B3-გავრცელება ეს არის სათაურების ნაკრები ( x-b3-* ), რომელიც თავდაპირველად შეიქმნა Zipkin tracing სისტემისთვის. იგი ადაპტირებული იყო OpenTracing-ში და გამოიყენებოდა მრავალი ხელსაწყოსა და ბიბლიოთეკის მიერ. B3-გავრცელება ატარებს trace_id / span_id და დროშას, რომელიც მიუთითებს საჭიროების შემთხვევაში თუ არა ნიმუშის აღება.


  2. W3C Trace Context შემუშავებული W3C სამუშაო ჯგუფის მიერ, ეს სტანდარტი აერთიანებს კონტექსტის გავრცელების სხვადასხვა მიდგომებს ერთ სტანდარტში და არის ნაგულისხმევი OpenTelemetry-ში. ამ სტანდარტების გამოყენების კარგი მაგალითია მოთხოვნის შესრულების თვალყურის დევნება, რომელიც გადის სხვადასხვა ტექნოლოგიებით დანერგილი მიკროსერვისების მეშვეობით, მონიტორინგისა და გამართვის სიზუსტის კომპრომისის გარეშე.

მიკვლევა

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


[სურათის წყარო: https://opentelemetry.io/docs/demo/screenshots/]


ვიზუალიზაციაში, თითოეულ ზოლს ეწოდება "span" და აქვს უნიკალური "span_id" . root span მოიხსენიება როგორც "კვალი" და აქვს "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, ამარტივებს ამ მონაცემების ვიზუალიზაციას, რაც მნიშვნელოვნად ამარტივებს მონიტორინგს.


[სურათის წყარო: https://grafana.com/blog/2021/06/22/grafana-dashboard-showcase-visualizations-for-prometheus-home-energy-usage-github-and-more/]


მეტრული კოლექციონერები

OpenTelemetry მეტრულ კოლექტორები თავსებადია Prometheus-ისა და OpenMetrics-ის სტანდარტებთან, რაც საშუალებას იძლევა ადვილად გადავიდეს OpenTelemetry გადაწყვეტილებებზე მნიშვნელოვანი ცვლილებების გარეშე. OpenTelemetry SDK საშუალებას იძლევა trace_id მაგალითების ექსპორტირება მეტრიკასთან ერთად, რაც შესაძლებელს გახდის მეტრიკის კორელაციას ჟურნალის მაგალითებთან და კვალთან.


სიგნალის კორელაცია

ჟურნალები, მეტრიკა და მიკვლევა ერთად ქმნის სისტემის მდგომარეობის ყოვლისმომცველ ხედვას:

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



[სურათის წყარო: https://grafana.com/blog/2020/03/31/how-to-successfully-correlate-metrics-logs-and-traces-in-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-ის აპლიკაციის არქიტექტურაში ინტეგრირებას და ინფრასტრუქტურის კონფიგურაციას მონაცემთა აგრეგაციისთვის.


პროცესი შედგება ოთხი ეტაპისგან:


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


  2. ექსპორტიორების კონფიგურაცია შეგროვებული მონაცემები გადაიგზავნება აპლიკაციებიდან ექსპორტიორების მეშვეობით გარე სისტემებში შემდგომი დამუშავებისთვის, როგორიცაა აღრიცხვა, მონიტორინგი, მიკვლევა ან ანალიტიკური სისტემები, თქვენი საჭიროებიდან გამომდინარე.


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


  4. მონაცემთა ვიზუალიზაცია და ბოლოს, დამუშავებული მონაცემები წარმოდგენილია როგორც დაფები ისეთ სისტემებში, როგორიცაა Grafana (მეტრიკისა და კვალისთვის) ან Kibana (ლოგისთვის). ეს საშუალებას აძლევს გუნდებს სწრაფად შეაფასონ სისტემის ჯანმრთელობა, დაადგინონ პრობლემები და ტენდენციები და დააყენონ გაფრთხილებები გენერირებული სიგნალების საფუძველზე.


განაცხადის განხორციელება

აპლიკაციასთან ინტეგრირებისთვის, თქვენ უნდა დააკავშიროთ შესაბამისი OpenTelemetry SDK გამოყენებული პროგრამირების ენისთვის ან გამოიყენოთ ბიბლიოთეკები და ჩარჩოები, რომლებიც პირდაპირ მხარს უჭერენ OpenTelemetry-ს. OpenTelemetry ხშირად ახორციელებს ფართოდ გავრცელებულ ინტერფეისებს ცნობილი ბიბლიოთეკებიდან, რაც საშუალებას აძლევს ჩანაცვლებას. მაგალითად, Micrometer ბიბლიოთეკა ჩვეულებრივ გამოიყენება ჯავის ეკოსისტემაში მეტრიკის შეგროვებისთვის. OpenTelemetry SDK უზრუნველყოფს მიკრომეტრის ინტერფეისების დანერგვას, რაც საშუალებას აძლევს მეტრულ ექსპორტს ძირითადი აპლიკაციის კოდის შეცვლის გარეშე. უფრო მეტიც, OpenTelemetry გთავაზობთ ძველი OpenTracing და OpenCensus ინტერფეისების განხორციელებას, რაც ხელს უწყობს OpenTelemetry-ში გლუვ მიგრაციას.

დასკვნა

IT სისტემებში OpenTelemetry შეიძლება გახდეს საიმედო და ეფექტური ბექენდების მომავლის გასაღები. ეს ინსტრუმენტი ამარტივებს გამართვას და მონიტორინგს და ასევე ხსნის შესაძლებლობებს აპლიკაციის მუშაობისა და ოპტიმიზაციის ახალ დონეზე ღრმა გაგებისთვის. შეუერთდით OpenTelemetry საზოგადოებას, რათა დაეხმაროთ მომავლის ჩამოყალიბებას, სადაც backend-ის განვითარება უფრო მარტივი და ეფექტურია!

L O A D I N G
. . . comments & more!

About Author

Dmitrii Pakhomov HackerNoon profile picture
Dmitrii Pakhomov@ymatigoosa
10 yeas of experience of building mission critical Fintech system handling extremely high load

დაკიდეთ ტეგები

ეს სტატია იყო წარმოდგენილი...