← ყველა სტატია

რებალანსის შტორმი ჩვეულებრივი დეპლოი აღმოჩნდა: ზღვარი, რომელიც ჯგუფთან ერთად იზრდება

Kafka-ს რებალანსის ალერტი ყოველ რელიზზე საათში 60-ზე ირთვებოდა. მეტრიკა 40 კონსიუმერზე ჯამდებოდა და მოცურავე საათით საშუალოვდებოდა — ალერტი წარსულს აღწერდა.

Gambchamp-ში ალერტი KafkaConsumerRebalanceStorm ერთ consumer ჯგუფზე აინთო: საათში 60 რებალანსი 30-იანი ზღვრისას, და ნახევარ საათზე მეტხანს წითელი რჩებოდა. იმავე კლასტერის მეზობელი ჯგუფები 8-სა და 12-ს აჩვენებდნენ. მორიგის დასკვნა აშკარაა: ჯგუფი უფრო მეტად რებალანსდება, ვიდრე მუშაობს — მოვძებნოთ ვარდნილი პოდები.

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

რა გამოვრიცხე პირველ რიგში

  • ვარდნილი პოდები: ყველას RESTARTS=0 ჰქონდა.
  • ბროკერების პრობლემა: მხოლოდ ერთი ჯგუფი იყო დაზარალებული.
  • ავტომატიზაციის მარყუჟი: reloader ექვსი დღე დუმდა.

ძველი და ახალი ReplicaSet-ის pod-შაბლონების diff-მა ზუსტად ერთი ცვლილება აჩვენა — იმიჯის ტეგი. ჩვეულებრივი რელიზი.

ციფრი ზომას ზომავდა და არა ქცევას

ზღვარი აბსოლუტური იყო, მეტრიკა კი — ჯამი მთელ ჯგუფზე.

  1. ETL სერვისი ერთ consumer ჯგუფში პოდზე 20 კონსიუმერს ინახავს — თითო ტოპიკზე, მაგრამ საერთო group.id-ით. ორი რეპლიკისას ეს 40 მონაწილეა.
  2. რებალანსის მთვლელს აქვს ჯგუფის, გარემოს, სერვისისა და ვერსიის ლეიბლები — და არც ერთი, რომელიც კონსიუმერებს ერთმანეთისგან გაარჩევს. 20-ივე ერთ სერიას ზრდის. ახლად გაშვებულ პოდზე ჩვეულებრივ ჯგუფებს 1.0 აქვთ, ამას — 20.0.
  3. Rolling update ყოველ ახალ პოდზე 20 შესვლაა და ძველებზე გადანაწილებები: დაახლოებით 60, მექანიკურად. რელიზზე ჩართვა კონსტრუქციით იყო გარანტირებული.
  4. ამას ზემოდან 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:-ზე მოკლე იმუნიტეტს იძლევა დეპლოისა და სკეილის მსგავსი პიკების მიმართ.
  • შეამოწმე შემმოწმებელი: ნეგატიური კონტროლი „მონაცემები არ არის“-ს „გაფუჭებული მოთხოვნისგან“ არჩევს.