Distributed Tracing: ჩვენ არასწორად გავაკეთეთ

Შენიშვნა. თარგმნა: ამ მასალის ავტორია სინდი შრიდჰარანი, ინჟინერი imgix-ში, რომელიც სპეციალიზირებულია API-ს შემუშავებაში და, კერძოდ, მიკროსერვისის ტესტირებაში. ამ მასალაში იგი იზიარებს თავის დეტალურ ხედვას მიმდინარე პრობლემების შესახებ განაწილებული კვალიფიკაციის სფეროში, სადაც, მისი აზრით, აქტუალური პრობლემების გადასაჭრელად ნამდვილად ეფექტური ინსტრუმენტების ნაკლებობაა.

[ილუსტრაცია აღებულია სხვა მასალა განაწილებული მოკვლევის შესახებ.]

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

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

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

ასეთი განსხვავებული კვალი

განაწილებული კვალი მოიცავს რამდენიმე განსხვავებულ კომპონენტს:

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

გავრცელებულ მოკვლევაზე ბევრი საუბარი მას განიხილავს, როგორც ერთგვარ უნივერსალურ ოპერაციას, რომლის ერთადერთი მიზანია დაეხმაროს სისტემის სრულ დიაგნოზს. ეს დიდწილად განპირობებულია იმით, თუ როგორ ჩამოყალიბდა იდეები განაწილებული მიკვლევის შესახებ ისტორიულად. IN ბლოგის ჩანაწერები, როცა ზიპკინის წყაროები გაიხსნა, აღნიშნული იყო რომ ის [Zipkin] აჩქარებს Twitter-ს. პირველი კომერციული შეთავაზებები კვალიფიკაციისთვის ასევე დაწინაურდა როგორც APM ინსტრუმენტები.

Შენიშვნა. თარგმნა: შემდგომი ტექსტის გასაგებად გასაადვილებლად, მოდით განვსაზღვროთ ორი ძირითადი ტერმინის მიხედვით OpenTracing პროექტის დოკუმენტაცია:

• Span - განაწილებული ტრასინგის ძირითადი ელემენტი. ეს არის გარკვეული სამუშაო ნაკადის აღწერა (მაგალითად, მონაცემთა ბაზის მოთხოვნა) სახელით, დაწყების და დასრულების დროებით, ტეგებით, ჟურნალებით და კონტექსტით.
• სპანები, როგორც წესი, შეიცავს ბმულებს სხვა სპინებთან, რაც საშუალებას გაძლევთ გაერთიანდეს რამდენიმე სპანში კვალი - მოთხოვნის სიცოცხლის ვიზუალიზაცია, როდესაც ის მოძრაობს განაწილებულ სისტემაში.

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

• მაგალითად, Uber იყენებს შედეგების მოკვლევა, რათა განასხვავოს სატესტო ტრაფიკი და წარმოების ტრაფიკი.
• Facebook იყენებს კვალის მონაცემები კრიტიკული ბილიკის ანალიზისთვის და ტრაფიკის გადართვისთვის კატასტროფის აღდგენის რეგულარული ტესტების დროს.
• ასევე სოციალური ქსელი ვრცელდება Jupyter-ის ნოუთბუქები, რომლებიც დეველოპერებს საშუალებას აძლევს განახორციელონ თვითნებური მოთხოვნები კვალის შედეგებზე.
• მიმდევრები LDFI (Lineage Driven Failure Injection) გამოყენება განაწილებული კვალი ტესტირებისთვის შეცდომის ინექციით.

ზემოთ ჩამოთვლილი არცერთი ვარიანტი არ ეხება სცენარს გამართვა, რომლის დროსაც ინჟინერი პრობლემის გადაჭრას კვალის დათვალიერებით ცდილობს.

Როდესაც საქმე ეხება ჯერ კიდევ აღწევს გამართვის სკრიპტს, პირველადი ინტერფეისი რჩება დიაგრამაში კვალი ხედვა (თუმცა ზოგიერთი მასაც ეძახის "Განტის დიაგრამა" ან "ჩანჩქერის დიაგრამა"). ქვეშ კვალი ხედვა я მე ვგულისხმობ ყველა დიაპაზონი და თანმხლები მეტამონაცემები, რომლებიც ერთად ქმნიან კვალს. ყველა ღია კოდის ტრასირების სისტემა, ისევე როგორც ყველა კომერციული ტრასინგის გადაწყვეტილება, გთავაზობთ ა კვალი ხედვა მომხმარებლის ინტერფეისი კვალის ვიზუალიზაციის, დეტალების და ფილტრაციისთვის.

ყველა ტრასირების სისტემის პრობლემა, რაც აქამდე მინახავს, ​​არის ის, რომ შედეგად ვიზუალიზაცია (კვალი) თითქმის მთლიანად ასახავს კვალი გენერირების პროცესის თავისებურებებს. მაშინაც კი, როდესაც შემოთავაზებულია ალტერნატიული ვიზუალიზაცია: სითბოს რუქები, სერვისის ტოპოლოგიები, ლატენტური ჰისტოგრამები, ისინი მაინც საბოლოოდ ჩამოდიან კვალი ხედვა.

წარსულში მე დაიჩივლა რომ UI/UX ტრასინგის "ინოვაციების" უმეტესობა, როგორც ჩანს, შემოიფარგლება ჩართვა დამატებითი მეტამონაცემების კვალი, მათში ინვესტირებას ინფორმაციის მაღალი კარდინალურობა (მაღალი კარდინალობა) ან უზრუნველყოფს კონკრეტულ სპექტაკლებში გაბურღვის ან შეკითხვის გაშვების შესაძლებლობას ინტერ- და შიდა კვალი. ამ შემთხვევაში, კვალი ხედვა რჩება ვიზუალიზაციის ძირითად ინსტრუმენტად. სანამ ეს მდგომარეობა გაგრძელდება, განაწილებული მიკვლევა (საუკეთესო შემთხვევაში) დაიკავებს მე-4 ადგილს, როგორც გამართვის ხელსაწყო, მეტრიკის, ჟურნალების და სტეკის კვალის შემდეგ, და უარეს შემთხვევაში, ეს იქნება ფულისა და დროის ფუჭად კარგვა.

პრობლემა traceview-სთან დაკავშირებით

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

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

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

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

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

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

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

შპალერები ძალიან დაბალი დონეა

Traceview-ის ფუნდამენტური პრობლემა ისაა მოიცავს ძალიან დაბალი დონის პრიმიტივებია როგორც ლატენტური ანალიზისთვის, ასევე ძირეული მიზეზის ანალიზისთვის. ეს ჰგავს ცალკეული პროცესორის ბრძანებების გაანალიზებას გამონაკლისის გადაჭრის მცდელობისას, იმის ცოდნა, რომ არსებობს ბევრად უფრო მაღალი დონის ინსტრუმენტები, როგორიცაა backtrace, რომლებთან მუშაობა ბევრად უფრო მოსახერხებელია.

უფრო მეტიც, მე ვიქნები თავისუფლება განვაცხადო შემდეგი: იდეალურ შემთხვევაში, ჩვენ არ გვჭირდება სრული სურათი მოხდა მოთხოვნის სასიცოცხლო ციკლის დროს, რომელიც წარმოდგენილია თანამედროვე მიკვლევის ხელსაწყოებით. ამის ნაცვლად, საჭიროა უფრო მაღალი დონის აბსტრაქციის რაიმე ფორმა, რომელიც შეიცავს ინფორმაციას იმის შესახებ, თუ რა არასწორად წავიდა (უკანასკნელის მსგავსი), გარკვეულ კონტექსტთან ერთად. იმის ნაცვლად, რომ მთელი კვალი ვუყურო, მირჩევნია მისი ნახვა часть, სადაც რაღაც საინტერესო ან უჩვეულო ხდება. ამჟამად ძებნა ხორციელდება ხელით: ინჟინერი იღებს კვალს და დამოუკიდებლად აანალიზებს სპექტაკლებს რაიმე საინტერესოს მოსაძებნად. ადამიანების მიდგომა, რომლებიც ინდივიდუალურ კვალს ათვალიერებენ, საეჭვო აქტივობის აღმოჩენის იმედით, საერთოდ არ არის მასშტაბური (განსაკუთრებით მაშინ, როდესაც მათ უნდა გააცნობიერონ ყველა მეტამონაცემები, რომლებიც დაშიფრულია სხვადასხვა დიაპაზონში, როგორიცაა span ID, RPC მეთოდის სახელი, დაფარვის ხანგრძლივობა. 'a, ჟურნალები, ტეგები და ა.შ.).

Traceview-ის ალტერნატივები

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

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

ფოკუსირება კონკრეტულ სერვისებზე

იმ დროს, როდესაც ინდუსტრია იდეების ირგვლივ კონსოლიდირებულია SLO (მომსახურების დონის მიზნები) და SLI (მომსახურების დონის ინდიკატორები), მიზანშეწონილია, რომ ცალკეულმა გუნდებმა პრიორიტეტად უნდა მიიჩნიონ თავიანთი სერვისების ამ მიზნებთან შესაბამისობის უზრუნველყოფა. Აქედან გამომდინარეობს, რომ სერვისზე ორიენტირებული ვიზუალიზაცია საუკეთესოდ შეეფერება ასეთ გუნდებს.

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

1. შეყოვნების განაწილების დიაგრამები მხოლოდ ძალიან თვალსაჩინო მოთხოვნებისთვის (გარეშე მოთხოვნები);
2. დაგვიანების განაწილების დიაგრამები იმ შემთხვევებისთვის, როდესაც სერვისის SLO მიზნები არ არის მიღწეული;
3. ყველაზე ხშირად "საერთო", "საინტერესო" და "უცნაური" ტეგები შეკითხვებში მეორდებიან;
4. შეყოვნების დაშლა იმ შემთხვევებისთვის, როდესაც დამოკიდებულებები სერვისები ვერ აღწევენ SLO მიზნებს;
5. შეყოვნების დაშლა სხვადასხვა ქვედა დინების სერვისებისთვის.

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

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

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

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

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

ტოპოლოგიის აგება

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

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

ავიღოთ მაგალითი. წარმოვიდგინოთ ჰიპოთეტური ახალი ამბების საიტი. მთავარი გვერდის სერვისი (წინა გვერდი) ცვლის მონაცემებს Redis-თან, სარეკომენდაციო სერვისით, სარეკლამო სერვისით და ვიდეო სერვისით. ვიდეო სერვისი იღებს ვიდეოებს S3-დან და მეტამონაცემებს DynamoDB-დან. სარეკომენდაციო სერვისი იღებს მეტამონაცემებს DynamoDB-დან, ატვირთავს მონაცემებს Redis-დან და MySQL-დან და წერს შეტყობინებებს კაფკას. სარეკლამო სერვისი იღებს მონაცემებს MySQL-დან და წერს შეტყობინებებს კაფკას.

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

ჰიპოთეტური ახალი ამბების საიტის სერვისის დიაგრამა

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

დინამიური ტოპოლოგია აჩვენებს მხოლოდ "საინტერესო" სერვისებს

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

შედარებითი ჩვენება

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

ორი კვალის შედარება არ საჭიროებს ფუნდამენტურად ახალ ვიზუალიზაციას. ფაქტობრივად, ჰისტოგრამის მსგავსი რამ, რომელიც წარმოადგენს იგივე ინფორმაციას, როგორც traceview, საკმარისია. გასაკვირია, რომ ამ მარტივ მეთოდსაც კი შეუძლია ბევრად მეტი ნაყოფის მოტანა, ვიდრე უბრალოდ ორი კვალის ცალკე შესწავლა. კიდევ უფრო ძლიერი იქნება შესაძლებლობა ვიზუალიზაცია კვალის შედარება Მთლიანობაში. უაღრესად სასარგებლო იქნებოდა იმის დანახვა, თუ როგორ იმოქმედებს ბოლო დროს განლაგებული მონაცემთა ბაზის კონფიგურაციის ცვლილება GC-ის (ნაგვის შეგროვების) გასააქტიურებლად, ქვემოთ მოყვანილი სერვისის რეაგირების დროზე რამდენიმე საათის მასშტაბით. თუ ის, რასაც მე აქ აღვწერ, ჟღერს ინფრასტრუქტურის ცვლილებების გავლენის A/B ანალიზს ბევრ სერვისში კვალის შედეგების გამოყენებით, თქვენ არც თუ ისე შორს ხართ სიმართლისგან.

დასკვნა

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

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

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

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

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «kubectl-debug დანამატი Kubernetes pods-ში გამართვისთვის";
• «მიკროსერვისები: ზომა მნიშვნელოვანია, მაშინაც კი, თუ თქვენ გაქვთ Kubernetes";
• «მონიტორინგი და Kubernetes (მიმოხილვა და ვიდეო ანგარიში)".

წყარო: www.habr.com