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

Gambchamp-ში T0 დონის პროდაქშენ-სისტემის ალერტების მიწოდება მთლიანად მკვდარი იყო და ამის შესახებ არაფერი გვამცნობდა. ვიღაცამ Slack-ის არხს სახელი გადაარქვა. Alertmanager ძველ სახელზე აგრძელებდა გაგზავნას, Slack კი ყოველ ათ წამში channel_not_found-ით პასუხობდა. მთელი ამ დროის განმავლობაში რიგში ორი ცოცხალი ალერტი იდგა. ერთადერთი გარეგანი ნიშანი იყო alertmanager_notifications_failed_total — მთვლელი, რომელსაც არავინ უყურებდა.

მესამედ იმავე იდენტიფიკატორზე

ეს ზედიზედ მესამე გაუმართაობა იყო ერთსა და იმავეზე:

• ჯერ საერთო incoming webhook channel ველს უგულებელყოფდა და ალერტები საერთო არხში ცვიოდა. გამოსწორება — ცალკე Alertmanager;
• შემდეგ bot-ტოკენი channel-ს პატივს სცემდა და მიწოდება ამუშავდა — მაგრამ არხის სახელზე იყო მიბმული. გადაწყვეტილს ჰგავდა;
• ბოლოს არხს სახელი გადაარქვეს და მიწოდება მოკვდა.

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

ეტიკეტი იდენტიფიკატორი არ არის

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

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

გამოსწორება

1. არხის ID-ით დამაგრება receiver-ში. არხი პირადია და ბოტს მისი ჩამოთვლის უფლება არ აქვს, ამიტომ API-ს ID-ის მხოლოდ წაკითხვით შემოწმება არ შეუძლია. შევამოწმე დაგეგმილი შეტყობინებით, რომელიც მიწოდებამდე წავშალე — ცდა, რომელიც ID-ს ხსნის და არაფერს აქვეყნებს.
2. მარშრუტიზაცია ცალსახა ლეიბლით და არა სახელით. როცა იმავე სისტემის ალერტები გამოყენებით და ინფრასტრუქტურულ არხებად გავყავით, ალერტის სახელის პრეფიქსზე აშკარა regex RDS-ის ხუთ guardrail-ს — რეპლიკაციის სლოტებს, საცავს — გამოყენებით არხში გაგზავნიდა. წესების ჯგუფში დაყენებული signal ლეიბლი ყოველ წესს საშუალებას აძლევს, თავად გამოაცხადოს თავისი ფენა და არ იყოს დამოკიდებული იმაზე, როგორ დაარქვა მას ვინმემ სახელი.

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

დასკვნები

• ყველაფერი, რისი გადარქმევაც ადამიანს შეუძლია, ეტიკეტია და არა იდენტიფიკატორი. მიებით უცვლელ ჰენდლს — ID-ს — ან ცალსახა დეკლარაციას, მაგალითად ლეიბლს, რომელსაც ავტორი განზრახ აყენებს.
• შეამოწმეთ მიწოდების გზა და არა მხოლოდ კომპონენტი. ჯანმრთელი Alertmanager, რომელიც ვერ აწვდის, ალერტების არარსებობისგან არ განსხვავდება.
• დაამატეთ ალერტი increase(alertmanager_notifications_failed_total[5m]) > 0-ზე. ეს ყველაზე იაფი dead-man switch-ია, რასაც ოდესმე დაამატებთ.
• შეამოწმეთ იგივე კლასი სხვაგან: პოდების სახელებიდან აწყობილი consumer group ID-ები, დასახელების კონვენციით გაფილტრული ექსპორტერები, ობიექტებს სახელით დამთხვეული პოლიტიკები.