რებალანსის შტორმი ჩვეულებრივი დეპლოი აღმოჩნდა: ზღვარი, რომელიც ჯგუფთან ერთად იზრდება
Kafka-ს რებალანსის ალერტი ყოველ რელიზზე საათში 60-ზე ირთვებოდა. მეტრიკა 40 კონსიუმერზე ჯამდებოდა და მოცურავე საათით საშუალოვდებოდა — ალერტი წარსულს აღწერდა.
Gambchamp-ში ალერტი KafkaConsumerRebalanceStorm ერთ consumer ჯგუფზე აინთო: საათში 60 რებალანსი 30-იანი ზღვრისას, და ნახევარ საათზე მეტხანს წითელი რჩებოდა. იმავე კლასტერის მეზობელი ჯგუფები 8-სა და 12-ს აჩვენებდნენ. მორიგის დასკვნა აშკარაა: ჯგუფი უფრო მეტად რებალანსდება, ვიდრე მუშაობს — მოვძებნოთ ვარდნილი პოდები.
ხაფანგი: ასე ყოველ რელიზზე ხდებოდა და არხის იგნორირებას თანდათან მიეჩვივნენ. ალერტისთვის ეს ყველაზე ცუდი შედეგია.
რა გამოვრიცხე პირველ რიგში
- ვარდნილი პოდები: ყველას
RESTARTS=0ჰქონდა. - ბროკერების პრობლემა: მხოლოდ ერთი ჯგუფი იყო დაზარალებული.
- ავტომატიზაციის მარყუჟი: reloader ექვსი დღე დუმდა.
ძველი და ახალი ReplicaSet-ის pod-შაბლონების diff-მა ზუსტად ერთი ცვლილება აჩვენა — იმიჯის ტეგი. ჩვეულებრივი რელიზი.
ციფრი ზომას ზომავდა და არა ქცევას
ზღვარი აბსოლუტური იყო, მეტრიკა კი — ჯამი მთელ ჯგუფზე.
- ETL სერვისი ერთ consumer ჯგუფში პოდზე 20 კონსიუმერს ინახავს — თითო ტოპიკზე, მაგრამ საერთო
group.id-ით. ორი რეპლიკისას ეს 40 მონაწილეა. - რებალანსის მთვლელს აქვს ჯგუფის, გარემოს, სერვისისა და ვერსიის ლეიბლები — და არც ერთი, რომელიც კონსიუმერებს ერთმანეთისგან გაარჩევს. 20-ივე ერთ სერიას ზრდის. ახლად გაშვებულ პოდზე ჩვეულებრივ ჯგუფებს
1.0აქვთ, ამას —20.0. - Rolling update ყოველ ახალ პოდზე 20 შესვლაა და ძველებზე გადანაწილებები: დაახლოებით 60, მექანიკურად. რელიზზე ჩართვა კონსტრუქციით იყო გარანტირებული.
- ამას ზემოდან
increase(...[1h])დაემატა — მოცურავე ფანჯარა. პიკი მასში მთელი საათი რჩებოდა მას შემდეგაც, რაც ჯგუფი დასტაბილურდა. ალერტი წარსულს აღწერდა.
შესწორება: ნორმალიზება და for-ზე მოკლე ფანჯარა
(
sum by(cluster, consumer_group)(rate(kafka_consumer_rebalances_total[10m])) * 3600
/
clamp_min(sum by(cluster, consumer_group)(kafka_consumer_task_alive), 1)
) > 10
for: 15m-ით. ერთეული ახლა „რებალანსი ერთ კონსიუმერზე საათში“.
მთავარი ხრიკი: 10-წუთიანი ფანჯარა 15-წუთიან for-ზე მოკლეა. დეპლოის პიკი ფანჯარაში ზუსტად ათ წუთს ცოცხლობს და გადის; თხუთმეტ წუთს ვერ გაძლებს. დეპლოი კონსტრუქციით არის გამორიცხული და არა ზღვრის შერჩევით.
გამოსახულება ცოცხალ ძრავზე შევამოწმე, ნეგატიური კონტროლის ჩათვლით: განზრახ გაფუჭებულმა მოთხოვნამ 422 უნდა დააბრუნოს, რომ ცარიელი შედეგი „მონაცემები არ არის“-ში არ აგვერიოს.
დასკვნები
- მთვლელი მოცურავე ფანჯარაში „ახლა“ არ არის.
increase[1h]პიკს მისი დასრულებიდან საათს ინახავს. - აბსოლუტური ზღვარი აგრეგატზე მხოლოდ თანაბარი კარდინალობისას არის სამართლიანი. ნორმალიზება გააკეთე.
rate-ის ფანჯარაfor:-ზე მოკლე იმუნიტეტს იძლევა დეპლოისა და სკეილის მსგავსი პიკების მიმართ.- შეამოწმე შემმოწმებელი: ნეგატიური კონტროლი „მონაცემები არ არის“-ს „გაფუჭებული მოთხოვნისგან“ არჩევს.