SRE (Site Reliability Engineering) არის მიდგომა ვებ პროექტების ხელმისაწვდომობის უზრუნველსაყოფად. ის განიხილება DevOps-ის ჩარჩოდ და საუბრობს იმაზე, თუ როგორ მიაღწიოთ წარმატებას DevOps პრაქტიკის გამოყენებაში. თარგმანი ამ სტატიაში თავი 6 განაწილებული სისტემების მონიტორინგი წიგნები საიტის საიმედოობის ინჟინერია Google-ისგან. მე თვითონ მოვამზადე ეს თარგმანი და ვეყრდნობოდი საკუთარ გამოცდილებას მონიტორინგის პროცესების გაგებაში. ტელეგრამის არხზე @monitorim_it и ბლოგი საშუალოზე მე ასევე გამოვაქვეყნე ბმული იმავე წიგნის მე-4 თავის თარგმანზე მომსახურების დონის მიზნების შესახებ.

თარგმანი კატის მიერ. ისიამოვნეთ კითხვით!

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

განსაზღვრავს

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

მონიტორინგი

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

თეთრი ყუთის მონიტორინგი

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

შავი ყუთის მონიტორინგი

აპლიკაციის ქცევის ტესტირება მომხმარებლის თვალსაზრისით.

დაფა

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

გაფრთხილება (შეტყობინება)

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

Ძირეული მიზეზი

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

კვანძი და მანქანა (კვანძი და მანქანა)

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

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

დააყენებს

ნებისმიერი ცვლილება პროგრამული უზრუნველყოფის კონფიგურაციაში.

რატომ არის საჭირო მონიტორინგი?

არსებობს რამდენიმე მიზეზი, რის გამოც საჭიროა განაცხადების მონიტორინგი:

გრძელვადიანი ტენდენციების ანალიზი

რამდენად დიდია მონაცემთა ბაზა და რამდენად სწრაფად იზრდება იგი? როგორ იცვლება მომხმარებელთა ყოველდღიური რაოდენობა?

შესრულების შედარება

უფრო სწრაფია თუ არა მოთხოვნები Acme Bucket of Bytes 2.72-ზე Ajax DB 3.14-თან შედარებით? რამდენად უკეთესია მოთხოვნების ქეშირება დამატებითი კვანძის გამოჩენის შემდეგ? გასულ კვირასთან შედარებით საიტი უფრო ნელა მუშაობს?

გაფრთხილება (შეტყობინებები)

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

დაფების შექმნა

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

რეტროსპექტული ანალიზის ჩატარება (გამართვა)

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

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

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

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

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

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

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

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

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

სიმპტომები მიზეზების წინააღმდეგ

თქვენი მონიტორინგის სისტემამ უნდა უპასუხოს ორ კითხვას: „რა გაფუჭდა“ და „რატომ გაფუჭდა“.
"რა გატეხა" საუბრობს სიმპტომზე და "რატომ გატეხა" საუბრობს მიზეზზე. ქვემოთ მოყვანილი ცხრილი გვიჩვენებს ასეთი კავშირების მაგალითებს.

სიმპტომი
გამოიწვიოს

HTTP შეცდომის მიღება 500 ან 404
მონაცემთა ბაზის სერვერები უარყოფენ კავშირებს

ნელი სერვერის პასუხები
CPU მაღალი ათვისება ან დაზიანებული Ethernet კაბელი

ანტარქტიდაში მომხმარებლები არ იღებენ კატის GIF-ებს
თქვენს CDN-ს სძულს მეცნიერები და კატები, ამიტომ ზოგიერთი IP მისამართი შავ სიაში მოხვდა

პირადი შინაარსი ხელმისაწვდომი გახდა ყველგან
პროგრამული უზრუნველყოფის ახალი გამოშვების გამოშვებამ აიძულა firewall-მა დაივიწყოს ყველა ACL და ყველას შეუშვა

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

შავი ყუთი vs თეთრი ყუთი

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

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

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

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

ოთხი ოქროს სიგნალი

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

შეფერხება

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

საგზაო

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

შეცდომები

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

გაჯერება

მეტრიკა გვიჩვენებს, რამდენად ინტენსიურად გამოიყენება თქვენი სერვისი. ეს არის სისტემის მონიტორინგის ღონისძიება, რომელიც განსაზღვრავს რესურსებს, რომლებიც ყველაზე მეტად შეზღუდულია (მაგალითად, მეხსიერებით შეზღუდულ სისტემაზე, აჩვენებს მეხსიერებას, I/O-შეზღუდულ სისტემაზე, აჩვენებს I/O-ების რაოდენობას). გაითვალისწინეთ, რომ ბევრი სისტემა ამცირებს ეფექტურობას მანამ, სანამ ისინი 100%-იან გამოყენებას მიაღწევენ, ამიტომ უტილიზაციის მიზანი მნიშვნელოვანია.

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

დაბოლოს, გაჯერება ასევე ასოცირდება მოსალოდნელ გაჯერების პროგნოზებთან, მაგალითად: „როგორც ჩანს, თქვენი მონაცემთა ბაზა შეავსებს თქვენს მყარ დისკს 4 საათში“.

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

წუხილი "კუდზე" (ან ინსტრუმენტები და შესრულება)

მონიტორინგის სისტემის ნულიდან შექმნისას, არსებობს ცდუნება განავითაროს სისტემა, რომელიც დაფუძნებულია საშუალო მნიშვნელობებზე: საშუალო შეყოვნება, საშუალო CPU კვანძების გამოყენება ან მონაცემთა ბაზის საშუალო სისრულე. ბოლო ორი მაგალითის საშიშროება აშკარაა: პროცესორები და მონაცემთა ბაზები განადგურდება ძალიან არაპროგნოზირებადი გზით. იგივე ეხება დაგვიანებას. თუ თქვენ აწარმოებთ ვებ სერვისს საშუალო შეყოვნებით 100ms წამში 1000 მოთხოვნით, მოთხოვნის 1%-ს შეიძლება დასჭირდეს 5 წამი. თუ მომხმარებლები დამოკიდებულნი არიან მრავალ ასეთ ვებ სერვისზე, ერთი ბექენდის 99-ე პროცენტული ადვილად შეიძლება გახდეს ფრონტენდის პასუხის მედიანური დრო.

მოთხოვნის ნელი საშუალო და ძალიან ნელი კუდის დიფერენცირების უმარტივესი გზაა სტატისტიკაში გამოხატული მოთხოვნების გაზომვების შეგროვება (კარგი ინსტრუმენტია ჰისტოგრამები საჩვენებლად) და არა რეალური შეყოვნება: რამდენ მოთხოვნას მოემსახურა სერვისმა, რომელსაც დასჭირდა 0 ms შორის. და 10 ms, 10 ms-დან 30 ms-მდე, 30 ms-დან 100 ms-მდე, 100 ms-დან 300 ms-მდე და ა.შ. ჰისტოგრამის საზღვრების გაფართოება დაახლოებით ექსპონენციალურად (დაახლოებით 3 კოეფიციენტით) ხშირად მარტივი გზაა განაწილების ვიზუალიზაციისთვის. თხოვნების.

დეტალების შესაბამისი დონის შერჩევა გაზომვებისთვის

სისტემის სხვადასხვა ელემენტები უნდა გაიზომოს დეტალების სხვადასხვა დონეზე. Მაგალითად:

• CPU-ის გამოყენების გარკვეული პერიოდის განმავლობაში მონიტორინგი არ აჩვენებს გრძელვადიან სპიკებს, რაც იწვევს მაღალ შეყოვნებას.
• მეორეს მხრივ, ვებ სერვისისთვის, რომელიც მიზნად ისახავს არაუმეტეს 9 საათის შეფერხებას წელიწადში (99,9% წლიური ამოქმედების დრო), HTTP 200 პასუხის შემოწმება წუთში ერთხელ ან ორჯერ, სავარაუდოდ, ზედმეტად ხშირი იქნება.
• ანალოგიურად, მყარ დისკზე 99,9% ხელმისაწვდომობის შემოწმება 1-2 წუთში ერთხელ ალბათ არ არის საჭირო.

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

1. გაზომეთ CPU დატვირთვა ყოველ წამში.
2. დეტალების შემცირება 5%-მდე.
3. შეაგროვეთ მეტრიკა ყოველ წუთში.

ეს სტრატეგია საშუალებას მოგცემთ შეაგროვოთ მონაცემები მაღალი სიზუსტით, მაღალი ანალიზისა და შენახვის ხარჯების გარეშე.

რაც შეიძლება მარტივი, მაგრამ არა მარტივი

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

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

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

ამიტომ, შეიმუშავეთ თქვენი მონიტორინგის სისტემა, რომ მაქსიმალურად გაამარტივოთ იგი. არჩევისას, თუ რა უნდა აკონტროლოთ, გაითვალისწინეთ შემდეგი:

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

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

პრინციპების ერთმანეთთან დაკავშირება

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

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

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

ეს კითხვები ასახავს ფუნდამენტურ ფილოსოფიას გაფრთხილებისა და გაფრთხილების სისტემების შესახებ:

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

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

გრძელვადიანი მონიტორინგი

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

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

Bigtable SRE: ზღაპარი ზედმეტად გაფრთხილების შესახებ

Google-ის შიდა ინფრასტრუქტურა, როგორც წესი, უზრუნველყოფილია და იზომება მომსახურების დონის მიხედვით (SLO). მრავალი წლის წინ, Bigtable-ის სერვისი SLO ეფუძნებოდა ცოცხალი კლიენტის სიმულაციის სინთეზური ტრანზაქციის საშუალო შესრულებას. Bigtable-ში და საცავის სტეკის ქვედა დონეებთან დაკავშირებული პრობლემების გამო, საშუალო შესრულება განპირობებული იყო „დიდი“ კუდით: მოთხოვნების ყველაზე ცუდი 5% ხშირად მნიშვნელოვნად ნელი იყო, ვიდრე დანარჩენი.

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

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

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

Gmail: პროგნოზირებადი, ალგორითმული ადამიანის პასუხები

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

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

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

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

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

გრძელვადიან პერსპექტივაში

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

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

დასკვნა

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

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

გმადლობთ, რომ თარგმანი ბოლომდე წაიკითხეთ. გამოიწერეთ ჩემი ტელეგრამის არხი მონიტორინგის შესახებ @monitorim_it и ბლოგი საშუალოზე.

წყარო: www.habr.com