დაკვირვებადობა და ალერტინგი
მეტრიკები, ალერტები და SLO, რომლებიც მიზეზზე მიუთითებს: Prometheus, VictoriaMetrics, Alertmanager, Grafana და სიგნალები, რომლებიც ცრუობს.
17 სტატია
- სერტიფიკატებს ვადა გრაფიკით გაუვიდა. ალერტი ერთი კვირა ყვიროდა — სიცარიელეშიkubeadm კლასტერმა control plane დაკარგა ინსტალაციიდან ზუსტად ერთი წლის შემდეგ. ალერტი შვიდი დღე იწვოდა, მაგრამ Alertmanager-ს მხოლოდ null მიმღები ჰქონდა.
- ალერტი ჩაირთო და ვერავინ დაინახა: cluster ლეიბლი აგრეგაციაში დაიკარგანოდი ოთხი საათი 90–98% CPU-ზე იჯდა და OOM kill-ით დასრულდა. CPU ალერტი ჩაირთო, მაგრამ avg by(instance)-მა ის ლეიბლი გადააგდო, რომლითაც ყველა მარშრუტი და დაშბორდი ირჩევდა.
- რებალანსის შტორმი ჩვეულებრივი დეპლოი აღმოჩნდა: ზღვარი, რომელიც ჯგუფთან ერთად იზრდებაKafka-ს რებალანსის ალერტი ყოველ რელიზზე საათში 60-ზე ირთვებოდა. მეტრიკა 40 კონსიუმერზე ჯამდებოდა და მოცურავე საათით საშუალოვდებოდა — ალერტი წარსულს აღწერდა.
- Argo CD აჩვენებდა Synced-ს, API სერვერმა კი ჩუმად გადააგდო ჩემი შესწორებათვეობით არ იყო მეტრიკები, შესწორება უკვე git-ში იდო და სტატუსი მწვანე Synced იყო. ველი CRD-ის სქემაში არ არსებობდა, API სერვერმა მოჭრა და არავინ იჩივლა.
- ალერტინგის სამი გაუმართაობა ერთი ფესვიდან: სახელი იქ, სადაც ID უნდა ყოფილიყოვიღაცამ Slack-ის არხს სახელი გადაარქვა და პროდაქშენ-სისტემის ალერტების მიწოდება ჩუმად მოკვდა. ეს იგივე იდენტიფიკატორზე მესამე გაუმართაობა იყო.
- Kafka 94 %-ით სავსე დისკზე, 17 საათის მარაგი და retention, რომელიც ორჯერ მეტს ინახავდატრაფიკი 150-ჯერ გაიზარდა, ტომები კი არავის გადაუხედავს. უარესი: სეგმენტების ნაგულისხმევი როლინგის დროს 7-დღიანი retention სინამდვილეში 7–14 დღეს ნიშნავდა.
- Postgres-ის რეპლიკა 23 საათი pg_rewind-ის ციკლში ტრიალებდა: ხელახლა შექმენით და ნუ შეაკეთებთfailover-ის შემდეგ CloudNativePG-ის რეპლიკამ rewind ვერ გააკეთა: მისი WAL-სეგმენტები ნულოვანი ზომის იყო, მონაცემთა კატალოგი კი primary-ზე ათჯერ პატარა. 23 საათი ვერავინ შეამჩნია, რადგან ოპერატორის მეტრიკები არ გროვდებოდა.
- Error budget VictoriaMetrics-ში: recording rules, burn-rate ალერტები და ერთი პატიოსანი პანელიროგორ ავაწყეთ error budget პირველი დონის სერვისებისთვის უკვე არსებული მეტრიკებიდან: SLO-მიზნები სერვისების მიხედვით, multi-window burn-rate ალერტები, რიგი Grafana-ში — და რატომ არ იყო უარყოფითი ბიუჯეტი გაშვებისთანავე ინციდენტი.
- ერთი p99 ალერტი, ხუთი ნელი მარშრუტი, ხუთი სხვადასხვა მიზეზისერვისის დონის ლატენტობის ალერტი არც ერთ endpoint-ს არ ასახელებდა. მარშრუტების მიხედვით დაყოფამ აჩვენა გარე შლუზი, captcha-ს შემოწმება, პროვაიდერის გამოძახება — და გაზომვის ხაფანგები, რომლებიც არასწორი გზით წაგვიყვანდა.
- ლაგი ნულზე ჩამოვიდა, მაგრამ არაფერი გამოსწორებულა: Kafka-ს გაჭედილი კონსიუმერი, დამალული group.id-ის გადარქმევითკონსიუმერის ლაგი ხუთ დღეს იზრდებოდა, შემდეგ ნულზე ჩამოვიდა და იქ დარჩა. თითქოს თავისით გამოსწორდა. სინამდვილეში კონსიუმერი გაჭედილი იყო, მეტრიკა გაქრა, ალერტი კი თავისით დაიხურა.
- Python-ის მეხსიერების გაჟონვის პროფილირება პროდაქშენზე memray-ით — და ავარია, რომელიც გზაში მოვაწყვეთბექენდი ყოველ 10–15 საათში OOM-ით ეცემოდა. ცოცხალ პოდზე memray-ის საათობრივმა ანაბეჭდებმა გაჟონვა ბიბლიოთეკის middleware-ში იპოვა და არა აპლიკაციის კოდში — მას შემდეგ, რაც პირველმა მცდელობამ პროდაქშენი შვიდი წუთით გათიშა.
- ოთხი შემოწმება, რომელიც ტყუოდა, სანამ სისტემა ჯანსაღი იყოპლატფორმის მიგრაციების ერთ დღეში ოთხი შემოწმება შეცდომას აცხადებდა, თუმცა ყველაფერი რიგზე იყო. როცა ერთი სიგნალი ყველა დანარჩენს ეწინააღმდეგება, პირველ რიგში თავად სიგნალს ეჭვობდეთ.
- ალერტები, რომლებიც ვერ ამოქმედდებიან: ბრმა ServiceMonitor და მკვდარი მიწოდების არხიVault-ის პირი 32 საათი sealed იყო, საიდუმლოებები კი კვირაზე მეტი არ სინქრონიზდებოდა — რეპოზიტორიაში VaultSealed ალერტით და ჯანმრთელი Alertmanager-ით. ინციდენტი ორმა დამოუკიდებელმა შეფერხებამ დამალა.
- GitLab-ის განახლება და ორი სიგნალი, რომლებიც ტყუოდნენself-hosted GitLab-ის ჩვეულებრივი მინორული განახლება Docker-ში. წინასწარმა შემოწმებამ 32 დაუსრულებელი მიგრაცია დაითვალა, კონტეინერი კი healthy გახდა ისე, რომ არაფერს ემსახურებოდა.
- დამერჯილი, დასინქრონებული, მიმაგრებული — და მაინც არ ალერტავს: vmalert hot reload-ის გარეშეKafka-ს ახალმა წესებმა Git-ისა და Argo CD-ის გავლით ConfigMap-მდე მიაღწიეს, მაგრამ vmalert-მა მათი შეფასება ასე და ვერ დაიწყო. GitOps კონვეიერი ბოლო ნაბიჯზე გაწყდა.
- Grafana-ს პანელი, რომელიც გეუბნება, როდის დაეცემა პოდი OOM-ითროგორ ვაქციოთ მეხსიერების ტრენდი ETA-დ OOM-მდე და დისკის შევსებამდე PromQL-ით, ორი ხარვეზი, რის გამოც პანელი ცრუობდა, და გაჟონვა, რომელიც პირველივე დღეს დაიჭირა.
- ხუთი დღე 1/3-ზე მწვანე დაშბორდებით: როცა CRD-ის სტატუსი ცრუობსMySQL InnoDB Cluster ხუთი დღე HA-ს გარეშე მუშაობდა, რესურსის სტატუსი, პოდების ფაზა და readiness gate კი ჯანმრთელობას აჩვენებდნენ. სამივე სიგნალი ერთი გაჭედილი ოპერატორიდან მოდიოდა.