Kubernetes monitorinqi konsepsiyasını nəzərdən keçirin, Prometheus aləti ilə tanış olun və xəbərdarlıq haqqında danışın.
Monitorinq mövzusu həcmlidir, onu bir məqalədə sökmək olmaz. Bu mətnin məqsədi alətlər, anlayışlar və yanaşmalar haqqında ümumi məlumat verməkdir.
Məqalənin materialı bir sıxılmadır . Tam kurs keçmək istəyirsinizsə - üzrə kursa yazın .
Kubernetes klasterində nə nəzarət olunur
fiziki serverlər. Kubernetes klasteri öz serverlərində yerləşdirilibsə, onların sağlamlığına nəzarət etməlisiniz. Zabbix bu vəzifəni yerinə yetirir; onunla işləyirsənsə, o zaman imtina etmək lazım deyil, heç bir münaqişə olmayacaq. Serverlərimizin vəziyyətinə nəzarət edən Zabbixdir.
Gəlin klaster səviyyəsində monitorinqə keçək.
İdarəetmə təyyarəsinin komponentləri: API, Scheduler və s. Ən azı, serverlərin və ya etcd-lərin API-nin 0-dan böyük olduğuna əmin olmalısınız. Etcd çoxlu ölçüləri qaytara bilər: fırlandığı disklərə görə, etcd klasterinin sağlamlığına görə və s.
yükvuran uzun müddət əvvəl ortaya çıxdı və hər kəs onun problemlərini yaxşı bilir: bir çox konteyner donma və digər problemlər yaradır. Buna görə də, Docker özü də bir sistem olaraq, ən azı əlçatanlıq baxımından idarə edilməlidir.
dns. Əgər klasterdə DNS düşərsə, ondan sonra bütün Discovery xidməti sıradan çıxacaq, podlardan podlara zənglər fəaliyyətini dayandıracaq. Mənim praktikamda belə problemlər yox idi, lakin bu o demək deyil ki, DNS-in vəziyyətinə nəzarət etmək lazım deyil. Sorğunun gecikmə müddəti və bəzi digər ölçülər CoreDNS-də izlənilə bilər.
Giriş. Layihəyə giriş nöqtələri kimi daxilolmaların (Giriş Nəzarətçisi daxil olmaqla) mövcudluğuna nəzarət etmək lazımdır.
Klasterin əsas komponentləri sökülüb - indi abstraksiyalar səviyyəsinə keçək.
Belə görünür ki, proqramlar podlarda işləyir, yəni onlara nəzarət etmək lazımdır, amma əslində belə deyil. Podlar efemerdir: bu gün bir serverdə, sabah başqa serverdə işləyirlər; bu gün 10-dur, sabah 2. Buna görə də heç kim podlara nəzarət etmir. Mikroservis arxitekturasında bütövlükdə tətbiqin mövcudluğuna nəzarət etmək daha vacibdir. Xüsusilə, xidmətin son nöqtələrinin mövcudluğunu yoxlayın: bir şey işləyirmi? Tətbiq mövcuddursa, onun arxasında nə baş verir, indi neçə replika var - bunlar ikinci dərəcəli suallardır. Fərdi hallara nəzarət etməyə ehtiyac yoxdur.
Son səviyyədə, proqramın özünün işinə nəzarət etməli, biznes ölçülərini götürməlisiniz: sifarişlərin sayı, istifadəçi davranışı və s.
Prometey
Klasterin monitorinqi üçün ən yaxşı sistemdir . Keyfiyyət və istifadə rahatlığı baxımından Prometheus-a uyğun ola biləcək hər hansı bir alət bilmirəm. Çevik infrastruktur üçün əladır, buna görə də “Kubernetes monitorinqi” deyəndə adətən Prometey nəzərdə tutulur.
Prometheus ilə işə başlamaq üçün bir neçə variant var: Helm-dən istifadə edərək adi Prometheus və ya Prometheus Operatorunu quraşdıra bilərsiniz.
- Adi Prometey. Onunla hər şey qaydasındadır, lakin ConfigMap-ı konfiqurasiya etməlisiniz - əslində, mikroservis arxitekturasından əvvəl əvvəllər etdiyimiz kimi mətn əsaslı konfiqurasiya fayllarını yazın.
- Prometheus Operatoru bir az daha yayılmışdır, daxili məntiq baxımından bir az daha mürəkkəbdir, lakin onunla işləmək daha asandır: ayrı-ayrı obyektlər var, klasterə abstraksiyalar əlavə olunur, ona görə də onları idarə etmək və konfiqurasiya etmək daha rahatdır.
Məhsulu başa düşmək üçün əvvəlcə adi Prometheus quraşdırmağı məsləhət görürəm. Siz konfiqurasiya vasitəsilə hər şeyi konfiqurasiya etməli olacaqsınız, lakin bu faydalı olacaq: nəyin nəyə aid olduğunu və necə konfiqurasiya olunduğunu anlayacaqsınız. Prometey Operatorunda siz dərhal daha yüksək abstraksiyaya qalxırsınız, baxmayaraq ki, istəsəniz dərinliklərə də girə bilərsiniz.
Prometheus Kubernetes ilə yaxşı inteqrasiya olunub: o, API Serverinə daxil ola və onunla qarşılıqlı əlaqədə ola bilər.
Prometheus populyardır, buna görə də çox sayda proqram və proqramlaşdırma dilləri onu dəstəkləyir. Dəstək lazımdır, çünki Prometey öz ölçü formatına malikdir və onu ötürmək üçün sizə ya proqram daxilində kitabxana, ya da hazır ixracatçı lazımdır. Belə ixracatçılar da az deyil. Məsələn, PostgreSQL Exporter var: o, PostgreSQL-dən məlumatları götürür və Prometheus formatına çevirir ki, Prometheus onunla işləyə bilsin.
Prometey memarlığı
Prometheus Server arxa tərəf, Prometeyin beynidir. Metriklər burada saxlanılır və işlənir.
Ölçülər zaman seriyası verilənlər bazasında (TSDB) saxlanılır. TSDB ayrıca verilənlər bazası deyil, Prometheus-a daxil edilmiş Go dilində bir paketdir. Kobud desək, hər şey bir binardadır.
Məlumatları TSDB-də uzun müddət saxlamayın
Prometheus infrastrukturu metriklərin uzunmüddətli saxlanması üçün uyğun deyil. Standart saxlama müddəti 15 gündür. Siz bu həddi keçə bilərsiniz, lakin unutmayın: TSDB-də nə qədər çox məlumat saxlasanız və bunu nə qədər uzun müddət etsəniz, o, bir o qədər çox resurs sərf edəcək. Prometeydə tarixi məlumatların saxlanması pis təcrübə hesab olunur.
Böyük trafikiniz varsa, ölçülərin sayı saniyədə yüz minlərlədir, onda onların saxlanmasını disk sahəsi və ya dövrlə məhdudlaşdırmaq daha yaxşıdır. Adətən, “qaynar məlumatlar” TSDB-də saxlanılır, ölçülər cəmi bir neçə saat ərzində. Daha uzun saxlama üçün xarici yaddaş bunun üçün həqiqətən uyğun olan verilənlər bazalarında istifadə olunur, məsələn, InfluxDB, ClickHouse və s. ClickHouse haqqında daha yaxşı rəylər gördüm.
Prometheus Server model üzərində işləyir dartmaq: o, ona verdiyimiz son nöqtələrə ölçülər götürür. Dedilər: "APİ Serverinə gedin" və o, hər n-ci saniyədən bir ora gedir və ölçüləri götürür.
Qırıntı dövrləri arasında görünə bilən qısa ömürlü (iş və ya cron işi) obyektlər üçün Pushgateway komponenti var. Qısamüddətli obyektlərin göstəriciləri onun içərisinə itələnir: iş yüksəldi, hərəkət etdi, Pushgateway-ə ölçülər göndərildi və tamamlandı. Bir müddət sonra Prometey öz sürəti ilə enəcək və Pushgateway-dən bu ölçüləri götürəcək.
Prometheus-da bildirişləri konfiqurasiya etmək üçün ayrıca bir komponent var - Siqnal meneceri. Və xəbərdarlıq qaydaları. Məsələn, server API-si 0 olarsa, siz xəbərdarlıq yaratmalısınız. Hadisə baş verəndə xəbərdarlıq sonrakı göndərilmə üçün xəbərdarlıq menecerinə ötürülür. Xəbərdarlıq menecerinin kifayət qədər çevik marşrut parametrləri var: xəbərdarlıqların bir qrupu adminlərin teleqram çatına, digəri tərtibatçıların söhbətinə, üçüncüsü isə infrastruktur işçilərinin söhbətinə göndərilə bilər. Bildirişlər Slack, Telegram, e-poçt və digər kanallara göndərilə bilər.
Və nəhayət, sizə Prometey qatil xüsusiyyəti haqqında məlumat verəcəyəm - Canlılar. Prometey ilə işləyərkən monitorinq üçün obyektlərin konkret ünvanlarını göstərməyə ehtiyac yoxdur, onların növünü təyin etmək kifayətdir. Yəni “burada IP ünvanı, bura port - monitor” yazmağa ehtiyac yoxdur, bunun əvəzinə bu obyektləri hansı prinsiplərlə tapmaq lazım olduğunu müəyyən etməlisiniz (hədəfləri - məqsədlər). Prometey özü, hazırda hansı obyektlərin aktiv olmasından asılı olaraq, lazım olanları çəkir və monitorinqə əlavə edir.
Bu yanaşma hər şeyin də üzdüyü Kubernetes strukturuna yaxşı uyğun gəlir: bu gün 10 server var, sabah 3. Serverin IP ünvanını hər dəfə göstərməmək üçün onu necə tapmaq lazım olduğunu bir dəfə yazdılar – və Discovering bunu edəcək. .
Prometey dili adlanır PromQL. Bu dildən istifadə edərək, xüsusi ölçülərin dəyərlərini əldə edə və sonra onları çevirə, onların əsasında analitik hesablamalar qura bilərsiniz.
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)Prometheus veb interfeysi
Prometheus-un özünəməxsus, kifayət qədər minimalist veb interfeysi var. Yalnız debug və ya nümayiş üçün uyğundur.
İfadə xəttində siz PromQL dilində sorğu yaza bilərsiniz.
Siqnallar tabında xəbərdarlıq qaydaları var və onların üç statusu var:
- qeyri-aktiv - xəbərdarlıq hazırda aktiv deyilsə, yəni onunla hər şey qaydasındadır və işləməyib;
- gözlənilən - bu, əgər xəbərdarlıq işləyirsə, lakin göndərilmə hələ keçməyibsə. Gecikmə şəbəkənin yanıb-sönməsini kompensasiya etmək üçün təyin edilmişdir: əgər göstərilən xidmət bir dəqiqə ərzində artıbsa, o zaman həyəcan hələ çalınmamalıdır;
- atəş siqnalı yanıb mesaj göndərəndə üçüncü statusdur.
Status menyusunda siz Prometeyin nə olduğu haqqında məlumat əldə edəcəksiniz. Yuxarıda bəhs etdiyimiz hədəflərə (hədəflərə) keçid də var.
Prometheus interfeysi haqqında daha ətraflı məlumat üçün baxın .
Grafana ilə inteqrasiya
Prometheus veb interfeysində klasterin vəziyyəti haqqında nəticə çıxara biləcəyiniz gözəl və başa düşülən qrafiklər tapa bilməzsiniz. Onları qurmaq üçün Prometey Grafana ilə inteqrasiya olunur. Biz belə tablolar alırıq.
Prometheus və Grafana inteqrasiyasını qurmaq heç də çətin deyil, təlimatları sənədlərdə tapa bilərsiniz: Yaxşı, bununla bitirəcəm.
Növbəti məqalələrdə biz monitorinq mövzusunu davam etdirəcəyik: Grafana Loki və alternativ alətlərdən istifadə edərək logların toplanması və təhlili haqqında danışacağıq.
Müəllif: Marcel Ibraev, sertifikatlı Kubernetes administratoru, şirkətdə praktik mühəndis , spiker və kurs tərtibatçısı Slurm.
Mənbə: www.habr.com