ალერტები, რომლებიც ვერ ამოქმედდებიან: ბრმა ServiceMonitor და მკვდარი მიწოდების არხი

Optimacros-ში Vault-ის ერთი პირი 32 საათი sealed მდგომარეობაში იდგა, ხოლო 55-დან 53 VaultStaticSecret ობიექტი კვირაზე მეტი არ სინქრონიზდებოდა. ალერტი არავის მისვლია. ამასთან, VaultSealed ალერტი რეპოზიტორიაში იდო, Prometheus ჯანმრთელი იყო, Alertmanager მუშაობდა.

ერთმანეთს ორი დამოუკიდებელი შეფერხება დაედო და ნებისმიერი ერთიც საკმარისი იქნებოდა ინციდენტის დასამალად.

პირველი შეფერხება: ალერტი აგებულებით ბრმა იყო

Vault-ის Helm ჩარტი აყენებს ServiceMonitor-ს, რომელიც vault-active: "true" ლეიბლიან პოდებს ირჩევს. სამნოდიან Vault-ში ეს ზუსტად ერთი პოდია — აქტიური ლიდერი. აქტიური პოდი კი განმარტებით გახსნილია: დალუქული ნოდა Raft-ის ლიდერი ვერ იქნება.

გამოდის, Prometheus მხოლოდ იმ პოდს აგროვებდა, რომელიც ვერასოდეს აღმოჩნდებოდა sealed. სარეზერვო პირებს — სწორედ მათ, რომლებიც გადატვირთვის შემდეგ დალუქულნი ბრუნდებიან — საერთოდ არ აგროვებდა. vault_core_unsealed == 0 გამოსათვლელი არაფერი ჰქონდა.

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

მეორე შეფერხება: მიწოდება ორი დღე მკვდარი იყო

Alertmanager-ის ყოველი შეტყობინება connect: connection timed out-ით ვარდებოდა. Telegram-ის API ჰოსტი ამ კლასტერიდან ისეთ მისამართზე იხსნებოდა, რომელიც მიუწვდომელი იყო, Telegram-ის სხვა მონაცემთა ცენტრის მისამართი კი ნორმალურად და ვალიდური სერტიფიკატით პასუხობდა. საერთო გასასვლელი გარეთ მუშაობდა — სხვა გარე სერვისები პასუხობდნენ, — ესე იგი, ეს კონკრეტული მისამართის ბლოკირება იყო და არა ფაიერვოლის პოლიტიკა. იმავე API-ზე პატარა სტატუს-ბოტიც ჩუმად ვარდებოდა.

ალერტები ამოქმედდებოდა. ისინი უბრალოდ კლასტერს ვერ ტოვებდნენ.

გამოსწორება

1. ServiceMonitor ყველა პირზე მივმართეთ: სელექტორი headless სერვისის ლეიბლზე შევცვალეთ, რომლის უკანაც Vault-ის ყველა პოდია. ჩარტი ამის საშუალებას values-ით იძლევა, შაბლონების შეცვლა საჭირო არ არის.
2. დავამატეთ ალერტი ჭეშმარიტებაზე, რომელიც Vault-ის ტელემეტრიაზე არ არის დამოკიდებული: დალუქული პოდი არასოდეს არის Ready, kube-state-metrics კი მზადყოფნას ყოველთვის აბრუნებს. ალერტი kube_pod_status_ready == 0-ზე Vault-ის პოდებისთვის seal-ს იჭერს მაშინაც, როცა Vault-ის საკუთარი მეტრიკები არ არის.
3. ალერტი არარსებობაზე: absent(vault_core_unsealed). == 0 სახის წესი არასოდეს ამოქმედდება რიგზე, რომელიც არ არსებობს.
4. მიწოდება აღვადგინეთ: Telegram-ის ხელმისაწვდომი მისამართი hostAliases-ით დავამაგრეთ Alertmanager-სა და სტატუს-ბოტში.

მოუხერხებელი შენიშვნები

• IP-ის დამაგრება შემოვლითი გზაა. თუ ამ მისამართსაც დაბლოკავენ, მიწოდება ისევ ჩუმად მოკვდება. საიმედო პასუხი მეორე, დამოუკიდებელი არხია (ფოსტა კრიტიკული ალერტებისთვის) ან egress პროქსი.
• AlertmanagerFailedToSendAlerts არსებობს, მაგრამ იმავე გაფუჭებული არხით მიეწოდება. შეფერხებების ამ კლასს მხოლოდ dead man’s switch იჭერს — გარე მიმღები, რომელიც რეგულარულ heartbeat-ს ელოდება და ხმაურს ტეხს, როცა ის ქრება.
• Telegram-ის კლიენტური ბიბლიოთეკა ლოგში მოთხოვნის სრულ URL-ს წერდა ბოტის ტოკენთან ერთად, ღია ტექსტად. ლოგებზე წვდომის მქონე ნებისმიერი ბოტს ფლობდა. ტოკენი ხელახლა გამოვეცით.

დასკვნები

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