Argo CD აჩვენებდა Synced-ს, API სერვერმა კი ჩუმად გადააგდო ჩემი შესწორება

ჩემს სახლის ლაბორატორიაში პეტ-პროექტის აპლიკაციას თვეობით არც ერთი მეტრიკა არ ჰქონდა. Postgres იქ CloudNativePG-ზე მუშაობს, ოპერატორმა PodMonitor შექმნა, GitOps რეპოში კი დაკარგული სკრეიპის შესწორება უკვე იდო. Argo CD აჩვენებდა Synced / Healthy-ს სწორედ იმ კომიტზე, სადაც შესწორება იყო. ამასობაში რეპლიკის გაუმართაობა 23 საათი შეუმჩნეველი დარჩა — მას უბრალოდ არავინ უყურებდა.

ჯერ ბრმა ლაქის გაზომვა

სანამ რამეს შევეხებოდი, დავთვალე. Prometheus-ს 46 აქტიური target ჰქონდა და ამ namespace-ში არც ერთი. არა „მოსალოდნელზე ნაკლები“, არამედ ნული. ამ ციფრმა ბუნდოვანი შეგრძნება კონკრეტულ კითხვად აქცია: რატომ არავინ სკრეიპავს PodMonitor-ს, რომელიც აშკარად არსებობს?

ორი დეფექტი, თითოეული ცალკე უწყინარად გამოიყურება

ლეიბლების შეუსაბამობა. kube-prometheus-stack ჩარტის ნაგულისხმევი პარამეტრებით მხოლოდ იმ მონიტორებს ირჩევს, რომლებსაც მისი release ლეიბლი აქვთ. CNPG ოპერატორის მიერ შექმნილ PodMonitor-ს აქვს app.kubernetes.io/* და cnpg.io/cluster — და მეტი არაფერი. ობიექტი არსებობს, დათვალიერებისას დაფარვას ჰგავს, მაგრამ მას არც ერთი Prometheus არ კითხულობს. იმავე ნაგულისხმევმა ჩუმად გამოტოვა cert-manager-ის ServiceMonitor-იც.

ველი, რომელიც არ არსებობს. git-ში არსებული შესწორება ამის გადაჭრას CNPG-ის მხრიდან ცდილობდა — ლეიბლების დამატებას spec.monitoring.podMonitorMetadata.labels-ით. ეს ველი ჩემი CNPG ვერსიის CRD სქემაში არ არის. სტრუქტურული სქემების დროს API სერვერი apply-ზე უცნობ ველებს ჭრის. არც შეცდომა, არც გაფრთხილება Argo CD-ში. Argo-მ მოჭრილი ცოცხალი ობიექტი მოჭრილ სასურველ მდგომარეობას შეადარა, ტოლად მიიჩნია და Synced თქვა.

მთავარი ნაბიჯი იყო თავად CRD-ის კითხვა, არსებობს თუ არა ასეთი ველი:

kubectl get crd clusters.postgresql.cnpg.io -o json \
  | jq -r '.spec.versions[0].schema.openAPIV3Schema.properties.spec.properties.monitoring.properties | keys[]'

podMonitorMetadata სიაში არ იყო. საქმე დახურულია.

შეაკეთე მომხმარებელი და არა ყველა მწარმოებელი

იმის ნაცვლად, რომ ყველა ოპერატორის მონიტორზე ლეიბლებს დავდევნებოდი, Prometheus შევცვალე: ჩარტში *SelectorNilUsesHelmValues ოფციები false-ზე დავაყენე, სელექტორები ცარიელი გახდა და Prometheus კლასტერის ყველა ServiceMonitor-სა და PodMonitor-ს იღებს. ერთმა ცვლილებამ შეაკეთა CNPG, cert-manager და ყველა მონიტორი, რომელსაც მომავალი ჩარტი შექმნის. სინქის შემდეგ მაშინვე გამოჩნდა cnpg_collector_up Postgres-ის ყველა პოდისთვის.

ruleSelector შეგნებულად მკაცრი დავტოვე. ზედმეტი შეგროვებული მეტრიკა უვნებელია, ზედმეტი ალერტი — ხმაური. ფასი: ყველა PrometheusRule-ს release ლეიბლი უნდა ჰქონდეს, თორემ არსად ჩაიტვირთება — იგივე ხაფანგი, ერთი ფენით ზემოთ, ამიტომ წესების დამატებისას ყოველთვის ვამოწმებ.

დაბრუნება მარტივია: ორი ხაზის წაშლა და Prometheus მკაცრ სელექტორს უბრუნდება მონაცემების დაკარგვის გარეშე.

დასკვნები

• მწვანე Synced ნიშნავს „ის, რაც API სერვერმა შეინახა, git-ს ემთხვევა — შენახვის შემდეგ“. გზაში მოჭრილ ველებზე ის არაფერს ამბობს.
• თუ GitOps ცვლილებამ არაფერზე იმოქმედა, ჯერ CRD-ის სქემას ჰკითხე, არსებობს თუ არა ველი, და მხოლოდ შემდეგ გამართე კონტროლერი.
• არსებული ობიექტი ჯერ კიდევ არ არის დაფარვა. დათვალე აქტიური target-ები.
• სჯობს ერთხელ შეასწორო სელექტორი მომხმარებლის მხარეს, ვიდრე სამუდამოდ ყველა მწარმოებელს გადაუკიდო ლეიბლები.