მოკვდა მონიტორინგი? — გაუმარჯოს მონიტორინგს

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

მიმაჩნია, რომ არის პრობლემა სათანადო მონიტორინგის სისტემის ორგანიზებაში. პრობლემები რომ არ ყოფილიყო, მაშინ ჩემი გამოსვლა შედგებოდა ერთი თეზისისაგან: „გთხოვთ დააინსტალიროთ Prometheus + Grafana და დანამატები 1, 2, 3“. სამწუხაროდ, ეს ასე აღარ მუშაობს. და მთავარი პრობლემა ის არის, რომ ყველას აგრძელებს სჯერა იმისა, რაც არსებობდა 2008 წელს, პროგრამული კომპონენტების თვალსაზრისით.

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

ჩვენ ყველას შეგვხვედრია ასეთი ამბავი: გარკვეული დევოპი, გარკვეული ადმინი მუშაობს, მათთან მოდის განვითარების ჯგუფი და ამბობს - "გათავისუფლდით, ახლა დააკვირდით". მონიტორინგი რა? Როგორ მუშაობს?

ᲙᲐᲠᲒᲘ. ჩვენ ვაკვირდებით ძველმოდურ გზას. და ის უკვე იცვლება და გამოდის, რომ თქვენ აკვირდებოდით სერვისს A, რომელიც გახდა სერვისი B, რომელიც ურთიერთქმედებს C სერვისთან. მაგრამ განვითარების ჯგუფი გეუბნებათ: "დააინსტალირეთ პროგრამული უზრუნველყოფა, მან უნდა აკონტროლოს ყველაფერი!"

მაშ რა შეიცვალა? - Ყველაფერი შეიცვალა!

2008 წ Ყველაფერი კარგადაა

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

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

2010 წელი დატვირთვა იზრდება

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

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

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

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

მაგრამ სამყარო იცვლება, უფრო და უფრო რთული ხდება. დაემატა ვირტუალიზაციის ფენა და რამდენიმე ახალი სისტემა. ისინი იწყებენ ერთმანეთთან ურთიერთობას. ვინ თქვა, რომ "მიკროსსერვისის სუნი ასდის?" მაგრამ თითოეული სერვისი ინდივიდუალურად მაინც ჰგავს ვებსაიტს. ჩვენ შეგვიძლია მივმართოთ მას და გავიგოთ, რომ ის გვაწვდის საჭირო ინფორმაციას და მუშაობს თავისით. და თუ თქვენ ხართ ადმინისტრატორი მუდმივად ჩართული პროექტში, რომელიც 5-7-10 წელია ვითარდება, ეს ცოდნა გროვდება: ჩნდება ახალი დონე - თქვენ ეს გააცნობიერეთ, ჩნდება სხვა დონე - თქვენ ეს გააცნობიერეთ...

მაგრამ იშვიათად ვინმე ახლავს პროექტს 10 წლის განმავლობაში.

მონიტორინგმენის რეზიუმე

დავუშვათ, რომ მიხვედით ახალ სტარტაპთან, რომელმაც მაშინვე დაიქირავა 20 დეველოპერი, დაწერა 15 მიკროსერვისი და თქვენ ხართ ადმინი, რომელსაც ეუბნებიან: „აშენეთ CI/CD. გთხოვთ." თქვენ შექმენით CI/CD და უცებ გესმით: „გვიჭირს „კუბში“ წარმოებასთან მუშაობა, იმის გაგების გარეშე, თუ როგორ იმუშავებს აპლიკაცია მასში. გაგვაკეთე ქვიშის ყუთი იმავე "კუბში".
ამ კუბში ქვიშის ყუთს აკეთებ. ისინი მაშინვე გეუბნებიან: ”ჩვენ გვსურს სცენის მონაცემთა ბაზა, რომელიც განახლდება ყოველ დღე წარმოებიდან, რათა გავიგოთ, რომ ის მუშაობს მონაცემთა ბაზაზე, მაგრამ ამავე დროს არ გააფუჭოს წარმოების მონაცემთა ბაზა.”

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

ჩემი კოლეგები კი ჩვეულ სქემას ამოიღებენ თავიდან და ამბობენ: „აბა, აქ ყველაფერი გასაგებია! დააინსტალირეთ პროგრამა, რომელიც მონიტორინგს გაუწევს ამ ყველაფერს“. დიახ, დიახ: პრომეთე + გრაფანა + დანამატები.
და ისინი დაამატებენ: ”თქვენ გაქვთ ორი კვირა, დარწმუნდით, რომ ყველაფერი უსაფრთხოა.”

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

• მას უნდა ესმოდეს რკინის ინფრასტრუქტურის მუშაობის მონიტორინგი და სპეციფიკა.
• მან უნდა გააცნობიეროს Kubernetes-ის მონიტორინგის სპეციფიკა (და ყველას სურს "კუბზე" წასვლა, რადგან შეგიძლიათ ყველაფრისგან აბსტრაქცია, დამალვა, რადგან ადმინი გაუმკლავდება დანარჩენს) - თავად, მისი ინფრასტრუქტურა და გაიგოს, როგორ აკონტროლოთ აპლიკაციები. შიგნით.
• მან უნდა გააცნობიეროს, რომ სერვისები ერთმანეთთან ურთიერთობენ სპეციალური გზებით და იცოდეს როგორ ურთიერთქმედებენ სერვისები ერთმანეთთან. სავსებით შესაძლებელია ნახოთ პროექტი, სადაც ზოგიერთი სერვისი სინქრონულად ურთიერთობს, რადგან სხვა გზა არ არის. მაგალითად, backend მიდის REST-ით, gRPC-ის მეშვეობით კატალოგის სერვისში, იღებს პროდუქტების სიას და აბრუნებს უკან. აქ ვერ დაელოდები. და სხვა სერვისებთან ერთად ის მუშაობს ასინქრონულად. შეკვეთის გადატანა მიტანის სამსახურში, წერილის გაგზავნა და ა.შ.
  თქვენ ალბათ უკვე გაცურეთ ამ ყველაფრისგან? და ადმინი, რომელსაც ამის მონიტორინგი სჭირდება, კიდევ უფრო დაიბნა.
• მან უნდა შეძლოს სწორად დაგეგმვა და დაგეგმვა – რაც უფრო და უფრო მეტი ხდება სამუშაო.
• ამიტომ მან უნდა შექმნას სტრატეგია შექმნილი სერვისიდან, რათა გაიგოს, თუ როგორ უნდა მოახდინონ კონკრეტულად მონიტორინგი. მას სჭირდება პროექტის არქიტექტურისა და მისი განვითარების გაგება + განვითარებაში გამოყენებული ტექნოლოგიების გაგება.

გავიხსენოთ აბსოლუტურად ნორმალური შემთხვევა: ზოგიერთი სერვისი არის PHP-ში, ზოგიერთი სერვისი არის Go-ში, ზოგიერთი სერვისი არის JS-ში. ისინი რატომღაც მუშაობენ ერთმანეთთან. აქედან მოდის ტერმინი „მიკროსერვისი“: იმდენი ინდივიდუალური სისტემაა, რომ დეველოპერებს არ შეუძლიათ პროექტის მთლიანობაში გაგება. გუნდის ერთი ნაწილი წერს სერვისებს JS-ში, რომლებიც მუშაობენ დამოუკიდებლად და არ იციან როგორ მუშაობს სისტემის დანარჩენი ნაწილი. მეორე ნაწილი წერს სერვისებს პითონში და არ ერევა სხვა სერვისების მუშაობაში; ისინი იზოლირებულნი არიან საკუთარ ტერიტორიაზე. მესამე არის სერვისების წერა PHP-ში ან სხვა რამეში.
ყველა ეს 20 ადამიანი დაყოფილია 15 სერვისად და მხოლოდ ერთი ადმინი უნდა გაიგოს ეს ყველაფერი. გაჩერდი! ჩვენ უბრალოდ დავყავით სისტემა 15 მიკროსერვისად, რადგან 20 ადამიანს არ ესმის მთელი სისტემა.

მაგრამ ამას როგორმე მონიტორინგი სჭირდება...

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

რა ვთქვა... ჰიუსტონ, პრობლემები გვაქვს.

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

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

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

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

მაშ, როგორ დავაკვირდეთ პროექტს თავიდანვე და რა უნდა გააკეთოთ, თუ მიიღებთ პროექტს, რომელსაც მონიტორინგი სჭირდება, მაგრამ არ იცით საიდან დაიწყოთ?

პირველ რიგში, თქვენ უნდა დაგეგმოთ.

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

ჯერ გადაწყვიტეთ რისი და როგორ გინდათ მონიტორინგი და შემდეგ აირჩიეთ ინსტრუმენტი, რადგან სხვა ადამიანები ვერ იფიქრებენ თქვენს მაგივრად. და უნდა? სხვა ადამიანები ფიქრობდნენ უნივერსალურ სისტემაზე - ან საერთოდ არ ფიქრობდნენ, როდესაც დაიწერა ეს დანამატი. და მხოლოდ იმიტომ, რომ ამ დანამატს ჰყავს 5 ათასი მომხმარებელი, არ ნიშნავს, რომ მას რაიმე გამოყენება აქვს. ალბათ თქვენ გახდებით 5001-ე მხოლოდ იმიტომ, რომ იქ ადრე უკვე 5000 ადამიანი იყო.

თუ დაიწყებთ ინფრასტრუქტურის მონიტორინგს და თქვენი აპლიკაციის ბექენდი შეწყვეტს რეაგირებას, ყველა მომხმარებელი დაკარგავს კავშირს მობილურ აპლიკაციასთან. გამოჩნდება შეცდომა. მოვლენ თქვენთან და გეტყვიან: "აპლიკაცია არ მუშაობს, აქ რას აკეთებ?" - ჩვენ ვაკვირდებით. — „როგორ ახორციელებთ მონიტორინგს, თუ ვერ ხედავთ, რომ აპლიკაცია არ მუშაობს?!“

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

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

ყველაფერი დონეების მიხედვით

მე ასე ვხედავ მონიტორინგის სისტემის ორგანიზებას.

1) განაცხადის დონე:

• აპლიკაციის ბიზნეს ლოგიკის მონიტორინგი;
• სერვისების ჯანმრთელობის მეტრიკის მონიტორინგი;
• ინტეგრაციის მონიტორინგი.

2) ინფრასტრუქტურის დონე:

• საორკესტრო დონის მონიტორინგი;
• სისტემის პროგრამული მონიტორინგი;
• რკინის დონის მონიტორინგი.

3) ისევ განაცხადის დონე - მაგრამ როგორც საინჟინრო პროდუქტი:

• განაცხადის ჟურნალების შეგროვება და მონიტორინგი;
• APM;
• მიკვლევა.

4) გაფრთხილება:

• გამაფრთხილებელი სისტემის ორგანიზება;
• სამორიგეო სისტემის ორგანიზება;
• „ცოდნის ბაზის“ ორგანიზება და ინციდენტების დამუშავების სამუშაო პროცესი.

მნიშვნელოვანია: გაფრთხილებამდე მივდივართ არა მას შემდეგ, არამედ მაშინვე! არ არის საჭირო მონიტორინგის დაწყება და „რაღაც მოგვიანებით“ გაერკვია, ვინ მიიღებს სიგნალებს. ბოლოს და ბოლოს, რა არის მონიტორინგის ამოცანა: იმის გაგება, თუ სად მუშაობს სისტემაში რაღაც არასწორად და აცნობოს სწორ ადამიანებს ამის შესახებ. თუ ამას ბოლომდე დატოვებთ, მაშინ სწორმა ადამიანებმა გაიგებენ, რომ რაღაც არასწორედ მიდის მხოლოდ დარეკვით „არაფერი არ გვეშველება“.

განაცხადის ფენა - ბიზნეს ლოგიკის მონიტორინგი

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

ეს დონე უნდა გაკეთდეს განვითარების ეტაპზე. მაგალითად, ჩვენ გვაქვს პირობითი პრომეთე: ის მიდის სერვერზე, რომელიც ამოწმებს, ამოიღებს ბოლო წერტილს და ბოლო წერტილი მიდის და ამოწმებს API-ს.

როდესაც ხშირად სთხოვენ საწყისი გვერდის მონიტორინგს, რათა დარწმუნდნენ, რომ საიტი მუშაობს, პროგრამისტები აძლევენ სახელურს, რომლის ამოღებაც შესაძლებელია ყოველ ჯერზე, როცა საჭიროა დარწმუნდნენ, რომ API მუშაობს. და პროგრამისტები ამ მომენტში მაინც იღებენ და წერენ /api/test/helloworld
ერთადერთი გზა, რათა დავრწმუნდეთ, რომ ყველაფერი მუშაობს? -არა!

• ასეთი ჩეკების შექმნა არსებითად დეველოპერების ამოცანაა. ერთეულის ტესტები უნდა დაიწეროს პროგრამისტებმა, რომლებიც წერენ კოდს. იმის გამო, რომ თუ ადმინისტრატორს გაჟონავთ, „მეგობარო, აქ არის API პროტოკოლების სია 25-ვე ფუნქციისთვის, გთხოვთ, აკონტროლოთ ყველაფერი!“ - არაფერი გამოვა.
• თუ თქვენ დაბეჭდავთ "hello world", ვერავინ ვერასოდეს გაიგებს, რომ API უნდა და მუშაობს. API-ს ყველა ცვლილებამ უნდა გამოიწვიოს ჩეკების ცვლილება.
• თუ უკვე გაქვთ ასეთი პრობლემა, შეაჩერეთ ფუნქციები და გამოყავით დეველოპერები, რომლებიც დაწერენ ამ ჩეკებს, ან მიიღებენ დანაკარგებს, აღიარეთ, რომ არაფერი არ არის შემოწმებული და წარუმატებელი იქნება.

ტექნიკური რჩევები:

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

აპლიკაციის ფენა - ჯანმრთელობის მეტრიკის მონიტორინგი

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

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

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

• API-ს ყველა ცვლილებამ უნდა გამოიწვიოს ჩეკების ცვლილება.
• დაუყოვნებლივ შექმენით ახალი სერვისი ჯანმრთელობის მეტრიკებით.
• ადმინისტრატორს შეუძლია მივიდეს დეველოპერებთან და სთხოვოს „დამამატე რამდენიმე ფუნქცია, რათა ყველაფერი გავიგო და ამის შესახებ ინფორმაცია დავამატო ჩემს მონიტორინგის სისტემას“. მაგრამ დეველოპერები ჩვეულებრივ პასუხობენ: "ჩვენ არაფერს დავამატებთ გამოშვებამდე ორი კვირით ადრე."
  აცნობეთ დეველოპმენტის მენეჯერებს, რომ იქნება ასეთი დანაკარგები, აცნობეთ დეველოპმენტის მენეჯერების ხელმძღვანელობასაც. იმიტომ რომ, როცა ყველაფერი დაეცემა, ვიღაც მაინც დარეკავს და მოითხოვს „მუდმივი დაცემის სერვისის“ მონიტორინგი (გ)
• სხვათა შორის, გამოყავით დეველოპერები Grafana-სთვის დანამატების დასაწერად - ეს კარგი დახმარება იქნება ადმინებს.

განაცხადის ფენა - ინტეგრაციის მონიტორინგი

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

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

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

რის გაკეთებას გირჩევ:

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

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

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

ინფრასტრუქტურის დონე

ინფრასტრუქტურის მონიტორინგი არის ის, რაც დიდი ხანია განიხილება თავად მონიტორინგად.

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

განაცხადის დონე, როგორც ბიზნეს ერთეული

ძირითადი პუნქტები:

• ELK. ეს არის ინდუსტრიის სტანდარტი. თუ რაიმე მიზეზით არ აგროვებთ ჟურნალებს, დაიწყეთ ამის გაკეთება დაუყოვნებლივ.
• APM. გარე APM-ები, როგორც აპლიკაციის მონიტორინგის სწრაფად დახურვის საშუალება (NewRelic, BlackFire, Datadog). შეგიძლიათ დროებით დააინსტალიროთ ეს ნივთი, რომ როგორმე მაინც გაიგოთ რა ხდება თქვენთან.
• მიკვლევა. ათეულობით მიკროსერვისში თქვენ უნდა ადევნოთ თვალი ყველაფერს, რადგან მოთხოვნა თავისით აღარ ცხოვრობს. მოგვიანებით მისი დამატება ძალიან რთულია, ამიტომ უმჯობესია დაუყოვნებლივ დაგეგმოთ კვალიფიკაცია განვითარებაში - ეს არის დეველოპერების სამუშაო და სასარგებლო. თუ ჯერ არ დაგინერგავთ, განახორციელეთ! იხილეთ Jaeger/Zipkin

გაფრთხილება

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

ტექნოლოგიის დასტა

წარმოვიდგინოთ, რომ ჩვენი დასტა ასეთია:

• მონაცემთა შეგროვება - პრომეთე + გრაფანა;
• ჟურნალის ანალიზი - ELK;
• APM ან Tracing-ისთვის - Jaeger (Zipkin).

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

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

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

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

დასკვნები

• განვითარების მონიტორინგი არ არის კომუნალური საშუალებების დაყენება, არამედ პროგრამული პროდუქტის შემუშავება. დღევანდელი მონიტორინგის 98% არის კოდირება. სერვისებში კოდირება, გარე შემოწმებების კოდირება, გარე სერვისების შემოწმება და ეს ყველაფერია.
• ნუ დაკარგავთ დეველოპერების დროს მონიტორინგზე: ამას შეიძლება დასჭირდეს მათი მუშაობის 30%, მაგრამ ღირს.
• დევოპს, არ ინერვიულო, რომ რაღაცის მონიტორინგს ვერ ახერხებ, რადგან ზოგიერთი რამ სრულიად განსხვავებული აზროვნებაა. თქვენ არ იყავით პროგრამისტი და მონიტორინგის სამუშაო სწორედ მათი საქმეა.
• თუ პროექტი უკვე მიმდინარეობს და არ არის მონიტორინგი (და თქვენ ხართ მენეჯერი), გამოყავით რესურსები მონიტორინგისთვის.
• თუ პროდუქტი უკვე წარმოებაშია და თქვენ ხართ დევოპი, რომელსაც უთხრეს „დააყენეთ მონიტორინგი“ - შეეცადეთ აუხსნათ მენეჯმენტს, რაზე დავწერე ეს ყველაფერი.

ეს არის მოხსენების გაფართოებული ვერსია Saint Highload++ კონფერენციაზე.

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

წყარო: www.habr.com