Zamyslite sa nad koncepciou monitorovania Kubernetes, zoznámte sa s nástrojom Prometheus a porozprávajte sa o varovaní.
Téma monitoringu je objemná, nedá sa rozobrať v jednom článku. Účelom tohto textu je poskytnúť prehľad nástrojov, konceptov a prístupov.
Materiál článku je stlačený z . Ak chcete absolvovať celý kurz - prihláste sa na kurz na .
Čo sa monitoruje v klastri Kubernetes
fyzické servery. Ak je klaster Kubernetes nasadený na jeho serveroch, musíte monitorovať ich stav. Zabbix túto úlohu zvláda; ak s ním pracujete, potom nemusíte odmietnuť, nebudú žiadne konflikty. Je to Zabbix, ktorý monitoruje stav našich serverov.
Prejdime k monitorovaniu na úrovni klastra.
Komponenty riadiacej roviny: API, plánovač a iné. Minimálne sa musíte uistiť, že API serverov alebo etcd je väčšie ako 0. Etcd môže vrátiť veľa metrík: podľa diskov, na ktorých sa točí, podľa stavu jeho klastra etcd a iných.
prístavný robotník sa objavil už dávno a každý si je dobre vedomý jeho problémov: veľa kontajnerov spôsobuje zamrznutie a iné problémy. Preto by mal byť samotný Docker ako systém tiež ovládaný, minimálne kvôli dostupnosti.
dns. Ak v klastri vypadne DNS, tak po ňom vypadne celá služba Discovery, prestanú fungovať hovory z podov do podov. V mojej praxi sa takéto problémy nevyskytli, to však neznamená, že stav DNS netreba sledovať. Latencia požiadaviek a niektoré ďalšie metriky sa dajú sledovať na CoreDNS.
Ingress. Je potrebné kontrolovať dostupnosť vstupov (vrátane Ingress Controller) ako vstupných bodov do projektu.
Hlavné komponenty klastra boli demontované – teraz poďme na úroveň abstrakcií.
Zdalo by sa, že aplikácie bežia v moduloch, čo znamená, že ich treba ovládať, no v skutočnosti to tak nie je. Moduly sú pominuteľné: dnes bežia na jednom serveri, zajtra na inom; dnes ich je 10, zajtra 2. Preto lusky nikto nemonitoruje. V rámci architektúry mikroslužieb je dôležitejšie kontrolovať dostupnosť aplikácie ako celku. Skontrolujte najmä dostupnosť koncových bodov služby: funguje niečo? Ak je aplikácia dostupná, tak čo sa za ňou deje, koľko je teraz replík – to sú otázky druhého rádu. Nie je potrebné sledovať jednotlivé prípady.
Na poslednej úrovni musíte ovládať fungovanie samotnej aplikácie, brať obchodné metriky: počet objednávok, správanie používateľov atď.
Prometheus
Najlepší systém na monitorovanie klastra je . Neviem o žiadnom nástroji, ktorý by sa vyrovnal Prometheusu z hľadiska kvality a jednoduchosti používania. Je to skvelé pre flexibilnú infraštruktúru, takže keď hovoria „monitorovanie Kubernetes“, zvyčajne majú na mysli Prometheus.
Existuje niekoľko možností, ako začať s Prometheus: pomocou Helm si môžete nainštalovať bežný Prometheus alebo Prometheus Operator.
- Pravidelný Prometheus. S ním je všetko v poriadku, ale musíte nakonfigurovať ConfigMap - v skutočnosti písať textové konfiguračné súbory, ako sme to robili predtým, pred architektúrou mikroslužieb.
- Operátor Prometheus je trochu roztiahnutý, trochu komplikovanejší z hľadiska vnútornej logiky, ale je s ním jednoduchšie pracovať: existujú samostatné objekty, do klastra sa pridávajú abstrakcie, takže sa dajú oveľa pohodlnejšie ovládať a konfigurovať.
Pre pochopenie produktu odporúčam najskôr nainštalovať bežný Prometheus. Všetko budete musieť nakonfigurovať cez konfiguráciu, ale bude to prospešné: prídete na to, čo k čomu patrí a ako je to nakonfigurované. V Prometheus Operator sa okamžite povznesiete do abstrakcie vyššie, hoci ak chcete, môžete sa ponoriť aj do hlbín.
Prometheus je dobre integrovaný s Kubernetes: môže pristupovať a interagovať s API Serverom.
Prometheus je populárny, a preto ho podporuje veľké množstvo aplikácií a programovacích jazykov. Je potrebná podpora, keďže Prometheus má svoj vlastný formát metrík a na jeho prenos potrebujete buď knižnicu v aplikácii, alebo hotový exportér. A takýchto vývozcov je pomerne dosť. Napríklad existuje PostgreSQL Exporter: berie dáta z PostgreSQL a konvertuje ich do formátu Prometheus, aby s nimi Prometheus mohol pracovať.
Architektúra Prometheus
Server Prometheus je zadný koniec, mozog Promethea. Tu sa ukladajú a spracúvajú metriky.
Metriky sú uložené v databáze časových radov (TSDB). TSDB nie je samostatná databáza, ale balík v jazyku Go, ktorý je vložený do Prometheus. Zhruba povedané, všetko je v jednej binárnej sústave.
Neukladajte údaje v TSDB na dlhú dobu
Infraštruktúra Prometheus nie je vhodná na dlhodobé ukladanie metrík. Predvolená doba uchovávania je 15 dní. Tento limit môžete prekročiť, ale majte na pamäti: čím viac údajov uložíte do TSDB a čím dlhšie to budete robiť, tým viac zdrojov spotrebuje. Ukladanie historických údajov v Prometheus sa považuje za zlý postup.
Ak máte veľkú návštevnosť, počet metrík je státisíce za sekundu, potom je lepšie obmedziť ich ukladanie podľa miesta na disku alebo podľa obdobia. „Horúce dáta“ sa zvyčajne ukladajú do TSDB, metriky za pár hodín. Pre dlhšie ukladanie sa používa externé úložisko v tých databázach, ktoré sú na to naozaj vhodné, napríklad InfluxDB, ClickHouse atď. Videl som viac dobrých recenzií o ClickHouse.
Na modeli pracuje Prometheus Server SEM: hľadá metriky k tým koncovým bodom, ktoré sme mu poskytli. Povedali: „choď na server API“ a on tam chodí každých n-tý počet sekúnd a berie metriky.
Pre objekty s krátkou životnosťou (úloha alebo úloha cron), ktoré sa môžu objaviť medzi obdobiami zoškrabovania, existuje komponent Pushgateway. Do nej sa tlačia metriky z krátkodobých objektov: úloha sa zdvihla, vykonala akciu, odoslala metriky na Pushgateway a dokončila. Po chvíli Prometheus zostúpi vlastným tempom a prevezme tieto metriky z Pushgateway.
Na konfiguráciu upozornení v Prometheus existuje samostatná súčasť - Správca výstrah. A pravidlá varovania. Napríklad musíte vytvoriť výstrahu, ak má server API hodnotu 0. Keď sa udalosť spustí, výstraha sa odošle správcovi výstrah na ďalšie odoslanie. Správca upozornení má pomerne flexibilné nastavenia smerovania: jednu skupinu upozornení je možné posielať do telegramového chatu správcov, ďalšiu do chatu vývojárov a tretiu do chatu pracovníkov infraštruktúry. Oznámenia je možné posielať na Slack, Telegram, e-mail a ďalšie kanály.
A nakoniec vám poviem o funkcii zabijaka Prometheus - Objavovanie. Pri práci s Prometheusom nemusíte špecifikovať konkrétne adresy objektov na sledovanie, stačí nastaviť ich typ. To znamená, že nemusíte písať „tu je IP adresa, tu je port - monitor“, namiesto toho musíte určiť, podľa akých princípov tieto objekty nájsť (ciele - Ciele). Samotný Prometheus v závislosti od toho, ktoré objekty sú práve aktívne, vytiahne potrebné a pridá ich do monitorovania.
Tento prístup dobre zapadá do štruktúry Kubernetes, kde tiež všetko pláva: dnes je tu 10 serverov, zajtra 3. Aby zakaždým neuvádzali IP adresu servera, raz napísali, ako ju nájsť - a Discovering to urobí .
Jazyk Prometheus je tzv PromQL. Pomocou tohto jazyka môžete získať hodnoty konkrétnych metrík a potom ich previesť, zostaviť na nich analytické výpočty.
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)webové rozhranie Prometheus
Prometheus má svoje vlastné, pomerne minimalistické webové rozhranie. Vhodné len na ladenie alebo predvádzanie.
V riadku Expression môžete napísať dotaz v jazyku PromQL.
Karta Upozornenia obsahuje pravidlá upozornení a majú tri stavy:
- neaktívne - ak upozornenie momentálne nie je aktívne, to znamená, že je s ním všetko v poriadku a nefungovalo;
- čakajúce - toto je, ak upozornenie fungovalo, ale odoslanie ešte neprebehlo. Oneskorenie je nastavené tak, aby kompenzovalo blikanie siete: ak sa špecifikovaná služba zvýšila do minúty, potom by sa ešte nemal spustiť alarm;
- spustenie je tretí stav, keď sa výstraha rozsvieti a odošle správy.
V ponuke Stav nájdete prístup k informáciám o tom, čo je Prometheus. Nechýba ani prechod na ciele (targets), o ktorých sme hovorili vyššie.
Podrobnejší prehľad rozhrania Prometheus nájdete na .
Integrácia s Grafanou
Vo webovom rozhraní Prometheus nenájdete krásne a zrozumiteľné grafy, z ktorých si môžete urobiť záver o stave klastra. Na ich vytvorenie je Prometheus integrovaný s Grafanou. Dostávame také palubné dosky.
Nastavenie integrácie Prometheus a Grafana nie je vôbec zložité, návod nájdete v dokumentácii: No a týmto skončím.
V nasledujúcich článkoch budeme pokračovať v téme monitorovania: budeme hovoriť o zbere a analýze protokolov pomocou Grafana Loki a alternatívnych nástrojov.
Autor: Marcel Ibraev, certifikovaný správca Kubernetes, praktický inžinier v spoločnosti , rečník a vývojár kurzov Slurm.
Zdroj: hab.com