სერვერის მონიტორინგი: ოთხი შემოწმება, რომელზეც ღირს alert

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

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

ოთხი შემოწმება, რომელიც ღირს#

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

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

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

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

სია სულ ეს არის. ყველაფერი დანარჩენი - CPU-ს გრაფიკები, მეხსიერების გრაფიკები, tick rate, მოთხოვნის latency, მოთამაშეთა რაოდენობა - დიაგნოსტიკაა და არა alerting. შეინახე გრაფიკები, შეხედე მათ იმ წამს, როცა alert გაისმის, და მათზე არ გააგზავნო გაფრთხილება. განსხვავება „ახლავე უნდა ვიცოდე“-სა და „მინდა ვნახო, როცა ვუყურებ“-ს შორის მთელი დისციპლინაა.

შემოწმება მანქანის გარედან#

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

# HTTP: status code and total time, failing loudly on anything but 2xx$ curl -fsS --max-time 5 -o /dev/null \    -w '%{http_code} %{time_total}s\n' https://app.example.com/healthz200 0.184s

# Minecraft: the server list ping, which needs the game to be answering$ mcstatus play.example.com:25565 status# Any TCP port, when you have nothing else installed$ nc -z -w 3 203.0.113.10 25565 && echo open

mcstatus მოდის ამავე სახელის Python პაკეტიდან და ბეჭდავს ვერსიის სტრიქონსა და მოთამაშეთა რაოდენობას. Source engine თამაშებისთვის ექვივალენტია A2S მოთხოვნა query პორტზე, რომელსაც uptime სერვისების უმეტესობა და ყველა სერვერების სიის საიტი უკვე ლაპარაკობს. თუ შენი მონიტორი მხოლოდ „TCP port check“-ს გთავაზობს, გამოიყენე, მაგრამ იცოდე, რას არ გეუბნება - იხილე გეიმ სერვერის პორტები ახსნილი, რატომ ვარდება query პორტი და თამაშის პორტი დამოუკიდებლად.

პარამეტრები, რომლებიც წყვეტს, სანდოა თუ არა შემოწმება:

• 60 წამის ინტერვალი უმეტესი რამისთვის. ოცდაათი, თუ სერვისი მომხმარებლისკენაა მიმართული და ნამდვილად უფრო სწრაფად იმოქმედებ. ოცდაათ წამზე დაბალი ყველაფერი დატვირთვაა და არა ინფორმაცია.
• სამი თანმიმდევრული ჩავარდნა alert-მდე. ეს არის სამი წუთი აღმოჩენამდე ერთწუთიან ინტერვალზე, რაც კარგია და მონიტორის საკუთარი ქსელით გამოწვეულ თითქმის ყველა ყალბ განგაშს აქრობს.
• 5-10 წამის timeout და არა ნაგულისხმევი 30. სერვერი, რომელიც 25 წამში პასუხობს, ყველასთვის, ვინც მას იყენებს, გათიშულია.
• ორი ლოკაცია, თუ სერვისი გთავაზობს. ერთი prober-ის ცუდი წუთი outage არ უნდა იყოს.
• გააფრთხილე აღდგენაზეც. alert, რომელსაც „ისევ მუშაობს“ ხაზი არ ახლავს, გაიძულებს ხელით შეამოწმო, რაც ის ჩვევაა, რომლის მოშორებასაც ცდილობდი.

ზღვრები, რომლებიც გამოცნობა არ არის#

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

ორი მათგანი კომენტარს საჭიროებს. მეხსიერება იზომება შენი გეგმის ლიმიტთან და არა მანქანის ლიმიტთან, და რა ხდება ლიმიტზე, ჰოსტის მიხედვით განსხვავდება: აქ კონტეინერს kernel აჩერებს და სუფთად ხელახლა იწყებს და არ აძლევს swap-ში ჩავარდნის საშუალებას, ამიტომ მეხსიერებისა და restart-ის alert-ები ხშირად ერთად მოდის და ერთს ნიშნავს. CPU მკაცრი throttle-ია იმ წილზე, რომელიც იყიდე, ამიტომ 100% ნიშნავს ნელს და არა გატეხილს - ეს არასოდეს არის შეჩერების საფუძველი და საგანგებო სიტუაცია არ არის, მაგრამ სერვერს, რომელიც იქ ცხოვრობს, ან რეგულირება სჭირდება, ან უფრო დიდი გეგმა. სერვერის დატვირთვის გრაფიკის კითხვა გვასწავლის ჯანსაღი პიკისა და ბრტყელი ჭერის გარჩევას, ხოლო CPU თუ RAM გეიმ სერვერებისთვის - რომელს მეტი უნდა იყიდო.

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

# Alert if no backup larger than 1 MB has landed in the last 26 hours$ find /srv/backups -type f -mmin -1560 -size +1M | grep -q . || \    curl -fsS -H 'Content-Type: application/json' \      -d '{"content":"No backup in the last 26 hours"}' "$DISCORD_WEBHOOK"

მისი შებრუნებული ვერსია ჯერ კიდევ უკეთესია და სწორედ ის არის, რასაც ჰოსტირებული „cron monitoring“ სერვისები ყიდიან: backup სამუშაო წარმატებით დასრულებისას URL-ს იძახებს და მონიტორი აფრთხილებს, როცა ზარები აღარ მოდის. Dead man's switch იჭერს იმ შემთხვევას, რომელსაც find ვერასოდეს დაიჭერს, კერძოდ - როცა სამუშაო საერთოდ არ გაეშვა, რადგან scheduler თავად არის გატეხილი.

გრაფიკების კითხვა alert-მდე#

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

სამი ფორმა ღირს, რომ ერთი შეხედვით ამოიცნო:

• ხერხისებრი მეხსიერება, რომელიც ყოველ restart-ზე ნულდება და ყოველდღე ოდნავ უფრო ადრე აღწევს ჭერს. ეს გაჟონვაა, ხოლო ღამის restart ნახვევია და არა გამოსწორება. Restart-ის განრიგები, რომლებიც გვეხმარება განიხილავს, როდის არის ნახვევი სწორი არჩევანი.
• საფეხურისებრი ცვლილება, რომელიც კონკრეტულ საათზე იწყება და აღარასოდეს ბრუნდება. რაღაც დაინსტალირდა, ჩაირთო ან დაიგეგმა იმ დროს. სხვა რამის დათვალიერებამდე შეადარე შენი deploy-ების ან plugin-ების ისტორიას.
• ბრტყელი ჭერი CPU-ში მხოლოდ პიკის საათებში. ეს გეგმაა ლიმიტი და არა კოდი და არანაირი რეგულირება იმდენს არ ცვლის, რამდენსაც კიდევ ერთი ბირთვი.

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

სად უნდა მოვიდეს alert#

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

1. ერთი არხი და არა ხუთი. Discord არხი ან ერთი ელფოსტის მისამართი, რომელიც მხოლოდ alert-ებს იღებს. თუ ის deploy შეტყობინებებსაც, ჩატსა და ყოველდღიურ digest-საც იღებს, ის ჩატის არხია და მას გააჩუმებ.
2. ადამიანისთვის წასაკითხი სათაურები. „app.example.com returned 502 for 3 minutes“ სჯობს „CHECK_HTTP CRITICAL“-ს. ამას ტელეფონზე წაიკითხავ.
3. აღდგენის შეტყობინებები იმავე ადგილას, რათა არხი თავისით იხურებოდეს და ერთი შეხედვით გეტყობოდეს, გატეხილია თუ არა ახლა რამე.
4. არანაირი დაუთანხმებელი escalation. ადამიანის ღამით გაფრთხილება ჰობი Minecraft სერვერის გამო ის გზაა, რომლითაც ხალხი Minecraft სერვერების ჰოსტინგს ანებებს თავს.

Webhook-ები ყველაზე იაფი გზაა: uptime სერვისების უმეტესობა პირდაპირ Discord ან Slack webhook-ზე აგზავნის, ხოლო ყველაფერს, რასაც shell ბრძანების გაშვება შეუძლია, მისი curl-ით გამოძახებაც შეუძლია. Discord webhook-ები სერვერის სტატუსისთვის შეიცავს მოწყობასა და payload-ის ფორმატს. webhook URL credential-ად მიიჩნიე - ვისაც ის უჭირავს, შენი სახელით გამოაქვეყნებს - და შეინახე გარემოს ცვლადში სკრიპტის ნაცვლად, როგორც გარემოს ცვლადები და საიდუმლოები-შია.

რას აკვირდება პანელი უკვე#

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

მაყურებელი ყოველ ორ წუთში ამოწმებს სერვერს, რომელიც გაითიშა ან რომლის uptime უკან წავიდა, რაც crash-ისა და restart-ის ნიშანია. შენ მიერ მოთხოვნილი restart-ები არ ითვლება. საათში სამი დაუგეგმავი restart სერვერის გვერდზე გაფრთხილებას ამატებს და ავტომატურად ხსნის ticket-ს; ექვსი სერვერს აჩერებს, რომ node-ს აღარ აწუხებდეს და ვინმეს დაენახოს. ეს ზემოთ ცხრილში „დაუგეგმავი restart-ების“ მწკრივს ფარავს შენი კონფიგურაციის გარეშე, ხოლო რატომ ხდება შენი გეიმ სერვერის განმეორებით restart მიზეზის გასარკვევად თანმხლებია.

კონსოლის გრაფიკები მეხსიერებას, CPU-სა და დისკს შენს ლიმიტებთან აჩვენებს. Schedules ჩანართი backup სამუშაოს cron გამოხატულებით უშვებს, დალაგებული ამოცანებითა და დაყოვნებებით, ამიტომ „გააკეთე backup, შემდეგ restart“ ერთი განრიგია და არა ორი რამ, რომლებიც იმედია სწორი თანმიმდევრობით მოხდება - იხილე /guides#schedules. სტატუსის გვერდი იმავე ხელმისაწვდომობის მონაცემებს აჩვენებს, რასაც ჩვენ ვაკვირდებით, ყოველ ხუთ წუთში ნიმუშად აღებულს, და არა მისგან განცალკევებულ სარეკლამო ვერსიას.

რაც შენ მაგივრად არ კეთდება, არის გარე შემოწმება და backup-ის ასაკის შემოწმება. არავინ შენი ანგარიშის გარეთ არ იცის, რა უნდა დააბრუნოს შენმა აპლიკაციამ, და არავინ შენ გარდა არ იცის, რომ გუშინდელი backup უნდა ყოფილიყო 4 GB და არა 40 KB.

ლოგები და შემოწმებები, რომლებიც მათ კითხულობს#

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

გააფრთხილე ხაზებზე, რომლებიც კონკრეტულ რამეს ნიშნავს და რომელზეც იმოქმედებდი. OutOfMemoryError, database is locked, Address already in use, permission denied მონაცემთა დირექტორიაზე, plugin-ის საკუთარი „failed to load“ ხაზი. სიტყვა ERROR-ზე ნუ გააფრთხილებ, რადგან მსოფლიოს პროგრამების ნახევარი აღდგენად მდგომარეობებს error დონეზე წერს და ფილტრის დარეგულირებაში ორი კვირა გაივლის, სანამ მას გამორთავ.

# The last hour of a log, only the lines you decided matter$ grep -nE 'OutOfMemory|Address already in use|Can.t connect to' latest.log | tail -20

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

წესი, რომელიც სიას მოკლეს ინახავს#

თუ alert გაისმის და გასაკეთებელი არაფერია, ის არ უნდა გაისმოდეს. ან გახადე ის მოქმედებადი, ან წაშალე.

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

გამოიყენე ყოველთვიურად, თითო alert-ზე სამი კითხვით:

1. გაისმა თუ არა ამ თვეში? თუ არასოდეს გაისმის, შეამოწმე, რომ ის ისევ მუშაობს - შემოწმება, რომელიც hostname-ზე მიუთითებს, რომელსაც აღარ იყენებ, შემოწმებაა, რომელიც აღარასოდეს გაისმის. გამოსცადე რამის განზრახ გატეხვით.
2. როცა გაისმა, მართალი იყო? ყველაფერს, რომლის ყალბი დადებითის მაჩვენებელი დაახლოებით ათიდან ერთს აჭარბებს, ზღვრის გადატანა ან retry-ების გაზრდა სჭირდება დღესვე, სანამ მის იგნორირებას ისწავლი.
3. რა გააკეთე? თუ პასუხია „შევხედე და არაფერი გამიკეთებია“, alert გრაფიკია. გადაიტანე დაშბორდზე.

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

FAQ#

რამდენად ხშირად უნდა გაეშვას uptime შემოწმება?

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

რას უნდა ამოწმებდეს health endpoint სინამდვილეში?

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

მჭირდება Prometheus და Grafana ერთი სერვერისთვის?

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

რატომ თქვა ჩემმა მონიტორმა, რომ სერვერი გათიშული იყო, როცა კარგად იყო?

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

უნდა გავაფრთხილო თუ არა მაღალ CPU-ზე?

პიკებზე არა. ფიქსირებული წილის მქონე გეგმაზე CPU მკაცრი throttle-ია, ამიტომ 100%-ს მისვლა სერვერს ნელს ხდის და არა გატეხილს, ხოლო ხანმოკლე პიკები სამყაროს შენახვისას ან restart-ისას ნორმალურია. გააფრთხილე მხოლოდ მაშინ, როცა ჭერი თხუთმეტი წუთით ან მეტით ჰყავს დაკავებული, და ეს მიიჩნიე როგორც „შეხედე ამას დღეს“ და არა როგორც outage.

როგორ გავიგო, რომ backup ნამდვილად იმუშავა?

შეამოწმე დასაჯერი ზომის ახალი ფაილი და არა სამუშაო, რომელმაც წარმატება დააფიქსირა. ასაკი და ზომა ერთად იჭერს ორ გავრცელებულ ჩავარდნას: სამუშაო, რომელიც არ გაეშვა, და სამუშაო, რომელიც ცარიელ დირექტორიაზე გაეშვა და 40 KB არქივი დაწერა. კვარტალში ერთხელ აღადგინე ერთი უვნებელ ადგილას და გახსენი. ეს ერთადერთი შემოწმებაა, რომელიც ამტკიცებს, რომ backup backup-ია.