დამერჯილი, დასინქრონებული, მიმაგრებული — და მაინც არ ალერტავს: vmalert hot reload-ის გარეშე
Kafka-ს ახალმა წესებმა Git-ისა და Argo CD-ის გავლით ConfigMap-მდე მიაღწიეს, მაგრამ vmalert-მა მათი შეფასება ასე და ვერ დაიწყო. GitOps კონვეიერი ბოლო ნაბიჯზე გაწყდა.
Gambchamp-ში მთელი პლატფორმის ალერტების წესები Git რეპოზიტორიაში ცხოვრობს. მერჯი Argo CD-ის გავლით auto-sync-ით ConfigMap-ში ხვდება, ხოლო vmalert — VictoriaMetrics-ზე აგებული ცენტრალური observability ჰაბის ნაწილი — მათ აფასებს. ერთ დღეს Kafka-ს ახალი წესების ნაკრები დავმერჯე: დაცემული ბროკერები, under-replicated პარტიციები, კონსიუმერების lag და rebalance-ების შტორმი.
Argo CD-მ დაასინქრონა. კლასტერში ConfigMap ახალ წესებს შეიცავდა. და არაფერი მომხდარა.
მტკიცება, რომ წესები არ მუშაობს
მნიშვნელოვანია არა შემოწმება „წესი Git-შია“, არამედ „ძრავა მას აფასებს“. მეტრიკა ALERTS, რომელსაც vmalert ყოველი pending და firing ალერტისთვის წერს, alertname=~"Kafka.*"-ზე ნულ რიგს აბრუნებდა. ამავდროულად, წესის ნედლი გამოსახულება, ხელით გაშვებული, 18 შესაბამის consumer group-ს აბრუნებდა. პირობა ჭეშმარიტი იყო, უბრალოდ წესი არ იყო ჩატვირთული.
მიზეზი
ამ vmalert-ს, სტანდარტული ჩარტიდან გაშლილს, არ ჰქონდა config-reloader sidecar და -rule.configCheckInterval ფლაგი. წესების ConfigMap volume-ად არის მიმაგრებული. Kubelet ამ volume-ის ფაილებს ConfigMap-ის ცვლილებისას ანახლებს, მაგრამ vmalert წესების ფაილებს მხოლოდ პროცესის გაშვებისას კითხულობს. reloader-ის ან შემოწმების ინტერვალის გარეშე არავინ ატყობინებს მას, რომ ფაილები შეიცვალა.
კონვეიერი „მერჯი, სინქრონიზაცია, ConfigMap“ უნაკლოდ იმუშავა და ფინიშამდე ერთი ნაბიჯით ადრე გაჩერდა. ახალი წესები პოდის დისკზე იდო და ძრავამდე ვერ აღწევდა.
დაუყოვნებელი გამოსწორება
vmalert-ის Deployment გადავტვირთე. გაშვებისას მან წესების ყველა ფაილი წაიკითხა, ახალი ჯგუფების ჩათვლით. rebalance შტორმის 18 ალერტი მაშინვე pending-ში გადავიდა, ხოლო for: 15m ფანჯრის შემდეგ — firing-ში, და დაშბორდის ალერტების პანელმა ისინი მაშინვე აჩვენა.
გადატვირთვას აქვს ფასი, რომელიც უნდა იცოდე: ის ფლოტის ყველა წესის for: ტაიმერებს ანულებს და არა მხოლოდ ახლებისას. მოგვიანებით უფრო რბილი გზა ვიპოვე. vmalert იღებს აშკარა POST /-/reload-ს, რომელიც წესების ფაილებს პროცესის გადატვირთვის გარეშე თავიდან კითხულობს. თავიდან იკითხება მხოლოდ შეცვლილი ჯგუფები; ხელუხლებელი ინარჩუნებენ მდგომარეობას და უკვე ანთებული ალერტები ანთებული რჩება. წესების შესწორებისთვის ეს სწორი ინსტრუმენტია.
გრძელვადიანი გამოსწორება
ორი ცვლილებიდან ნებისმიერი იწვევს იმას, რომ GitOps ალერტები თავად აქტიურდება:
-rule.configCheckInterval=30s-ის დამატება, რომ vmalert-მა თავისი ფაილები პერიოდულად თავიდან წაიკითხოს, ან- config-reloader sidecar, რომელიც ConfigMap-ის ყოველი ცვლილებისას reload-ს იძახებს.
სანამ არც ერთი არ არის, ალერტების რეპოზიტორიაში ყოველი მერჯი ხელით reload-ს მოითხოვს.
რა უნდა დავიმახსოვროთ
- „წესი დამერჯილია“ არ ნიშნავს „წესი მუშაობს“.
ALERTS{alertname="X"}-ით დაადასტურე, რომ ძრავა მას ხედავს — pending-ში ან firing-ში. - volume-ად მიმაგრებული ConfigMap ფაილებს ანახლებს და არა პროცესს. შეამოწმე, ადევნებს თუ არა მომხმარებელი მათ თვალს.
- წესების შესწორებისთვის აშკარა reload გადატვირთვას ამჯობინე: გადატვირთვა ყველა
for:ტაიმერს ანულებს. - მთვლელებზე დაფუძნებული ალერტების ზღვრები მერჯამდე ცოცხალ მონაცემებზე დააკალიბრე, რომ ახალი წესი არც მკვდარი იყოს და არც ხმაურიანი.