კუბერნეტის კლასტერის მონიტორინგი: მიმოხილვა და შესავალი პრომეთეს შესახებ

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

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

სტატიის მასალა არის შეკუმშვა ღია ლექცია სკოლა "სლურმში". თუ გსურთ სრული კურსის გავლა - დარეგისტრირდით კურსზე მონიტორინგი და ხეების ინფრასტრუქტურა Kubernetes-ში.

რა არის მონიტორინგი Kubernetes კლასტერში

ფიზიკური სერვერები. თუ Kubernetes კლასტერი განლაგებულია მის სერვერებზე, თქვენ უნდა აკონტროლოთ მათი ჯანმრთელობა. Zabbix ასრულებს ამ ამოცანას; თუ მასთან მუშაობთ, მაშინ არ გჭირდებათ უარის თქმა, არ იქნება კონფლიქტები. ეს არის Zabbix, რომელიც აკონტროლებს ჩვენი სერვერების მდგომარეობას.

მოდით გადავიდეთ მონიტორინგზე კლასტერულ დონეზე.

საკონტროლო თვითმფრინავის კომპონენტები: API, Scheduler და სხვები. მინიმუმ, თქვენ უნდა დარწმუნდეთ, რომ სერვერების ან etcd API 0-ზე მეტია. Etcd-ს შეუძლია მრავალი მეტრიკის დაბრუნება: დისკების მიხედვით, რომლებზეც ის ტრიალებს, მისი etcd კლასტერის სიჯანსაღით და სხვა.

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

dns. თუ DNS იშლება კლასტერში, მაშინ მთელი Discovery სერვისი დაიშლება მის შემდეგ, ზარები პოდებიდან პოდებში შეწყვეტს მუშაობას. ჩემს პრაქტიკაში, ასეთი პრობლემები არ ყოფილა, მაგრამ ეს არ ნიშნავს იმას, რომ DNS-ის მდგომარეობას არ სჭირდება მონიტორინგი. მოთხოვნის შეყოვნება და ზოგიერთი სხვა მეტრიკა შეიძლება თვალყური ადევნოთ CoreDNS-ზე.

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

კლასტერის ძირითადი კომპონენტები დაიშალა - ახლა აბსტრაქციების დონეზე გადავიდეთ.

როგორც ჩანს, აპლიკაციები მუშაობს პოდებში, რაც ნიშნავს, რომ მათ კონტროლი სჭირდებათ, მაგრამ სინამდვილეში ეს ასე არ არის. პოდები ეფემერულია: დღეს ისინი მუშაობენ ერთ სერვერზე, ხვალ მეორეზე; დღეს არის 10 მათგანი, ხვალ 2. ამიტომ, წიპწებს არავინ აკონტროლებს. მიკროსერვისის არქიტექტურის ფარგლებში, უფრო მნიშვნელოვანია აპლიკაციის მთლიანობაში ხელმისაწვდომობის კონტროლი. კერძოდ, შეამოწმეთ სერვისის საბოლოო წერტილების ხელმისაწვდომობა: მუშაობს რამე? თუ აპლიკაცია ხელმისაწვდომია, მაშინ რა ხდება მის უკან, რამდენი რეპლიკაა ახლა - ეს მეორე რიგის კითხვებია. არ არის საჭირო ცალკეული შემთხვევების მონიტორინგი.

ბოლო დონეზე, თქვენ უნდა აკონტროლოთ თავად აპლიკაციის მოქმედება, აიღოთ ბიზნეს მეტრიკა: შეკვეთების რაოდენობა, მომხმარებლის ქცევა და ა.შ.

პრომეთე

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

პრომეთესთან მუშაობის დასაწყებად რამდენიმე ვარიანტი არსებობს: Helm-ის გამოყენებით შეგიძლიათ დააინსტალიროთ ჩვეულებრივი პრომეთე ან პრომეთე ოპერატორი.

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

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

Prometheus კარგად არის ინტეგრირებული Kubernetes-თან: მას შეუძლია წვდომა და ურთიერთქმედება API სერვერთან.

პრომეთე პოპულარულია, რის გამოც მას მხარს უჭერს უამრავი აპლიკაცია და პროგრამირების ენა. მხარდაჭერაა საჭირო, რადგან პრომეთეს აქვს საკუთარი მეტრიკის ფორმატი და მის გადასატანად გჭირდებათ ბიბლიოთეკა აპლიკაციის შიგნით ან მზა ექსპორტიორი. და ასეთი ექსპორტიორები საკმაოდ ბევრია. მაგალითად, არის PostgreSQL Exporter: ის იღებს მონაცემებს PostgreSQL-დან და აკონვერტებს პრომეთეს ფორმატში, რათა პრომეთემ შეძლოს მასთან მუშაობა.

პრომეთეს არქიტექტურა

პრომეთეს სერვერი არის უკანა ბოლო, პრომეთეს ტვინი. მეტრიკა ინახება და მუშავდება აქ.

მეტრიკა ინახება დროის სერიების მონაცემთა ბაზაში (TSDB). TSDB არ არის ცალკე მონაცემთა ბაზა, არამედ პაკეტი Go ენაზე, რომელიც ჩართულია Prometheus-ში. უხეშად რომ ვთქვათ, ყველაფერი ერთ ბინარშია.

არ შეინახოთ მონაცემები TSDB-ში დიდი ხნის განმავლობაში

პრომეთეს ინფრასტრუქტურა არ არის შესაფერისი მეტრიკის გრძელვადიანი შენახვისთვის. ნაგულისხმევი შენახვის ვადა 15 დღეა. თქვენ შეგიძლიათ გადააჭარბოთ ამ ლიმიტს, მაგრამ გაითვალისწინეთ: რაც უფრო მეტ მონაცემს შეინახავთ TSDB-ში და რაც უფრო დიდხანს გააკეთებთ ამას, მით მეტ რესურსს მოიხმარს იგი. პრომეთეში ისტორიული მონაცემების შენახვა ცუდ პრაქტიკად ითვლება.

თუ თქვენ გაქვთ უზარმაზარი ტრაფიკი, მეტრიკის რაოდენობა წამში ასობით ათასია, მაშინ უმჯობესია შეზღუდოთ მათი შენახვა დისკის სივრცით ან პერიოდის მიხედვით. ჩვეულებრივ, "ცხელი მონაცემები" ინახება TSDB-ში, მეტრიკა სულ რამდენიმე საათში. უფრო გრძელი შენახვისთვის, გარე მეხსიერება გამოიყენება იმ მონაცემთა ბაზებში, რომლებიც ნამდვილად შესაფერისია ამისათვის, მაგალითად, InfluxDB, ClickHouse და ა.შ. უფრო მეტი კარგი მიმოხილვა ვნახე ClickHouse-ის შესახებ.

მოდელზე მუშაობს პრომეთე სერვერი გაიყვანოს: ის მიდის მეტრიკაზე იმ ბოლო წერტილებზე, რომლებიც ჩვენ მივეცით. მათ თქვეს: „გადადით API სერვერზე“ და ის მიდის იქ ყოველ n-ე წამში და იღებს მეტრიკას.

მოკლე სიცოცხლის ხანგრძლივობის მქონე ობიექტებისთვის (სამუშაო ან კრონ სამუშაო), რომლებიც შეიძლება გამოჩნდეს გახეხვის პერიოდებს შორის, არსებობს Pushgateway კომპონენტი. მოკლევადიანი ობიექტების მეტრიკა შეყვანილია მასში: სამუშაო გაიზარდა, შეასრულა მოქმედება, გაგზავნა მეტრიკა Pushgateway-ში და დასრულდა. გარკვეული პერიოდის შემდეგ, პრომეთე ჩამოვა თავისი ტემპით და აიღებს ამ მაჩვენებლებს Pushgateway-დან.

პრომეთეში შეტყობინებების კონფიგურაციისთვის არის ცალკე კომპონენტი - ალერტმენეჯერი. და გაფრთხილების წესები. მაგალითად, თქვენ უნდა შექმნათ გაფრთხილება, თუ სერვერის API არის 0. მოვლენის გაშვებისას, გაფრთხილება გადაეცემა გაფრთხილების მენეჯერს შემდგომი გაგზავნისთვის. გაფრთხილების მენეჯერს აქვს საკმაოდ მოქნილი მარშრუტიზაციის პარამეტრები: გაფრთხილებების ერთი ჯგუფი შეიძლება გაიგზავნოს ადმინისტრატორების ტელეგრამის ჩატში, მეორე - დეველოპერების ჩატში და მესამე - ინფრასტრუქტურის მუშაკთა ჩატში. შეტყობინებების გაგზავნა შესაძლებელია Slack-ზე, Telegram-ზე, ელფოსტაზე და სხვა არხებზე.

და ბოლოს, მე გეტყვით პრომეთეს მკვლელის თვისებაზე - Discovering. პრომეთესთან მუშაობისას მონიტორინგისთვის არ გჭირდებათ ობიექტების კონკრეტული მისამართების მითითება, საკმარისია მათი ტიპის დაყენება. ანუ, თქვენ არ გჭირდებათ დაწეროთ "აქ არის IP მისამართი, აქ არის პორტი - მონიტორი", ამის ნაცვლად, თქვენ უნდა დაადგინოთ რა პრინციპებით უნდა იპოვოთ ეს ობიექტები (სამიზნე - მიზნები). თავად პრომეთე, იმისდა მიხედვით, თუ რომელი ობიექტებია ამჟამად აქტიური, ამოიყვანს საჭიროებს და ამატებს მათ მონიტორინგს.

ეს მიდგომა კარგად ჯდება Kubernetes-ის სტრუქტურასთან, სადაც ყველაფერი ასევე ცურავს: დღეს არის 10 სერვერი, ხვალ 3. იმისათვის, რომ არ დაზუსტდეს სერვერის IP მისამართი ყოველ ჯერზე, ერთხელ დაწერეს როგორ უნდა იპოვონ ის - და Discovering ამას გააკეთებს. .

პრომეთეს ენას ეძახიან PromQL. ამ ენის გამოყენებით შეგიძლიათ მიიღოთ კონკრეტული მეტრიკის მნიშვნელობები და შემდეგ გადაიყვანოთ ისინი, შექმნათ ანალიტიკური გამოთვლები მათზე დაყრდნობით.

https://prometheus.io/docs/prometheus/latest/querying/basics/

Простой запрос

    container_memory_usage_bytes

Математические операции

    container_memory_usage_bytes / 1024 / 1024

Встроенные функции

    sum(container_memory_usage_bytes) / 1024 / 1024

Уточнение запроса

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

პრომეთეს ვებ ინტერფეისი

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

Expression ხაზში შეგიძლიათ დაწეროთ შეკითხვა PromQL ენაზე.

გაფრთხილების ჩანართი შეიცავს გაფრთხილების წესებს და მათ აქვთ სამი სტატუსი:

1. არააქტიური - თუ გაფრთხილება არ არის აქტიური ამ მომენტში, ანუ ყველაფერი კარგად არის და არ მუშაობდა;
2. მომლოდინე - ეს არის თუ გაფრთხილება მუშაობდა, მაგრამ გაგზავნა ჯერ არ გასულა. დაყოვნება დაყენებულია ქსელის მოციმვის კომპენსაციისთვის: თუ მითითებული სერვისი ერთ წუთში გაიზარდა, მაშინ განგაში ჯერ არ უნდა გაისმა;
3. გასროლა არის მესამე სტატუსი, როდესაც გაფრთხილება ანათებს და აგზავნის შეტყობინებებს.

სტატუსის მენიუში ნახავთ ინფორმაციას იმის შესახებ, თუ რა არის პრომეთე. ასევე ხდება მიზნებზე (სამიზნეებზე) გადასვლა, რაზეც ზემოთ ვისაუბრეთ.

პრომეთეს ინტერფეისის უფრო დეტალური მიმოხილვისთვის იხ Slurm-ის ლექციაში Kubernetes კლასტერის მონიტორინგის შესახებ.

ინტეგრაცია გრაფანასთან

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

პრომეთესა და გრაფანას ინტეგრაციის დაყენება საერთოდ არ არის რთული, ინსტრუქციები შეგიძლიათ იხილოთ დოკუმენტაციაში: GRAFANA მხარდაჭერა პრომეთესთვისკარგი, ამით დავამთავრებ.

შემდეგ სტატიებში გავაგრძელებთ მონიტორინგის თემას: ვისაუბრებთ ჟურნალების შეგროვებასა და ანალიზზე Grafana Loki-სა და ალტერნატიული ინსტრუმენტების გამოყენებით.

ავტორი: მარსელ იბრაევი, კუბერნეტესის სერტიფიცირებული ადმინისტრატორი, პრაქტიკოსი ინჟინერი კომპანიაში Southbridge, სპიკერი და კურსის შემქმნელი Slurm.

წყარო: www.habr.com