Razmotrite koncept Kubernetes monitoringa, upoznajte se sa alatom Prometheus i razgovarajte o uzbunjivanju.
Tema praćenja je obimna, ne može se rastaviti u jednom članku. Svrha ovog teksta je da pruži pregled alata, koncepata i pristupa.
Materijal članka je iscijeđen . Ako želite da pohađate kompletan kurs - prijavite se za kurs na .
Šta se prati u Kubernetes klasteru
fizički serveri. Ako je Kubernetes klaster raspoređen na svojim serverima, morate pratiti njihovo zdravlje. Zabbix rješava ovaj zadatak; ako radite s njim, onda ne morate odbiti, neće biti sukoba. Zabbix je taj koji prati stanje naših servera.
Pređimo na praćenje na nivou klastera.
Komponente upravljačkog plana: API, Scheduler i drugi. U najmanju ruku, morate biti sigurni da je API servera ili etcd veći od 0. Etcd može vratiti mnogo metrika: prema diskovima na kojima se okreće, prema zdravlju njegovog etcd klastera i drugih.
doker pojavio se davno i svi su svjesni njegovih problema: puno kontejnera stvara zamrzavanje i druge probleme. Stoga i sam Docker, kao sistem, također treba biti kontroliran, barem u pogledu dostupnosti.
dns. Ako DNS padne u klasteru, onda će cijeli Discovery servis otpasti nakon njega, pozivi od podova prema podovima će prestati raditi. U mojoj praksi takvih problema nije bilo, ali to ne znači da stanje DNS-a ne treba pratiti. Latencija zahtjeva i neke druge metrike mogu se pratiti na CoreDNS-u.
Ingress. Neophodno je kontrolisati dostupnost ulaza (uključujući Ingress Controller) kao ulaznih tačaka u projekat.
Glavne komponente klastera su demontirane - sada idemo dolje na nivo apstrakcija.
Čini se da aplikacije rade u podovima, što znači da ih treba kontrolisati, ali u stvarnosti nisu. Podovi su efemerni: danas rade na jednom serveru, sutra na drugom; danas ih je 10, sutra 2. Dakle, niko ne prati mahune. Unutar mikroservisne arhitekture, važnije je kontrolirati dostupnost aplikacije u cjelini. Konkretno, provjerite dostupnost krajnjih tačaka usluge: radi li nešto? Ako je aplikacija dostupna, šta se onda dešava iza nje, koliko replika je sada - to su pitanja drugog reda. Nema potrebe za praćenjem pojedinačnih instanci.
Na posljednjoj razini, trebate kontrolirati rad same aplikacije, uzimati poslovne metrike: broj narudžbi, ponašanje korisnika i tako dalje.
Prometej
Najbolji sistem za praćenje klastera je . Ne znam za alat koji bi mogao parirati Prometeju po kvaliteti i jednostavnosti upotrebe. Odličan je za fleksibilnu infrastrukturu, pa kada kažu „Kubernetes monitoring“, obično misle na Prometeja.
Postoji nekoliko opcija za početak rada s Prometheusom: koristeći Helm, možete instalirati običan Prometheus ili Prometheus Operator.
- Regular Prometheus. Sve je u redu s njim, ali morate konfigurirati ConfigMap - zapravo, pisati konfiguracijske datoteke zasnovane na tekstu, kao što smo radili prije, prije mikroservisne arhitekture.
- Prometheus Operator je malo rašireniji, malo složeniji u smislu interne logike, ali je lakše raditi s njim: postoje zasebni objekti, apstrakcije se dodaju u klaster, tako da ih je mnogo praktičnije kontrolirati i konfigurirati.
Da biste razumjeli proizvod, preporučujem da prvo instalirate obični Prometheus. Moraćete sve da konfigurišete kroz konfiguraciju, ali ovo će biti od koristi: shvatićete šta čemu pripada i kako je konfigurisano. U Prometheus Operatoru, odmah se uzdižete do apstrakcije više, iako možete zaroniti i u dubine ako želite.
Prometheus je dobro integrisan sa Kubernetesom: može pristupiti API serveru i komunicirati sa njim.
Prometheus je popularan, zbog čega ga podržava veliki broj aplikacija i programskih jezika. Podrška je potrebna, pošto Prometheus ima svoj format metrike, a da biste ga prenijeli, potrebna vam je ili biblioteka unutar aplikacije ili gotov eksporter. A takvih izvoznika ima dosta. Na primjer, postoji PostgreSQL Exporter: uzima podatke iz PostgreSQL-a i pretvara ih u Prometheus format tako da Prometheus može raditi s njima.
Prometejeva arhitektura
Prometheus Server je zadnji kraj, Prometejev mozak. Ovdje se pohranjuju i obrađuju metrika.
metrika se pohranjuje u bazi podataka vremenskih serija (TSDB). TSDB nije zasebna baza podataka, već paket na Go jeziku koji je ugrađen u Prometheus. Grubo govoreći, sve je u jednoj binarnoj verziji.
Nemojte pohranjivati podatke u TSDB dugo vremena
Infrastruktura Prometheus nije pogodna za dugotrajno skladištenje metrike. Standardni period zadržavanja je 15 dana. Možete prekoračiti ovo ograničenje, ali imajte na umu: što više podataka pohranite u TSDB i što duže to radite, više resursa će potrošiti. Čuvanje istorijskih podataka u Prometeju smatra se lošom praksom.
Ako imate ogroman promet, broj metrika je stotine hiljada u sekundi, onda je bolje ograničiti njihovu pohranu prostorom na disku ili periodom. Obično se „vrući podaci“ pohranjuju u TSDB, metrika za samo nekoliko sati. Za dužu pohranu, eksterna pohrana se koristi u onim bazama podataka koje su za to zaista prikladne, na primjer, InfluxDB, ClickHouse i tako dalje. Vidio sam još dobrih recenzija o ClickHouseu.
Prometheus Server radi na modelu povući: on ide na metriku do onih krajnjih tačaka koje smo mu dali. Rekli su: “idi na API server”, a on ide tamo svaki n-ti broj sekundi i uzima metriku.
Za objekte s kratkim životnim vijekom (posao ili cron posao) koji se mogu pojaviti između perioda scrapinga, postoji Pushgateway komponenta. U njega se guraju metrike iz kratkoročnih objekata: posao je pokrenut, izvršio radnju, poslao metriku na Pushgateway i završio. Nakon nekog vremena, Prometheus će se spustiti svojim tempom i preuzeti ove metrike sa Pushgatewaya.
Za konfiguriranje obavijesti u Prometheusu postoji posebna komponenta - Alertmanager. I pravila uzbunjivanja. Na primjer, trebate kreirati upozorenje ako je API servera 0. Kada se događaj pokrene, upozorenje se prosljeđuje upravitelju upozorenja radi daljeg slanja. Menadžer upozorenja ima prilično fleksibilne postavke rutiranja: jedna grupa upozorenja se može poslati u telegram chat administratora, druga u chat programera, a treća u chat radnika infrastrukture. Obavještenja se mogu slati na Slack, Telegram, e-poštu i druge kanale.
I na kraju, reći ću vam o ubici Prometeja - otkrivanje. Kada radite sa Prometheusom, ne morate specificirati određene adrese objekata za praćenje, dovoljno je podesiti njihov tip. Odnosno, ne morate pisati "ovdje je IP adresa, ovdje je port - monitor", umjesto toga morate odrediti po kojim principima pronaći ove objekte (meta - ciljevi). Sam Prometheus, ovisno o tome koji su objekti trenutno aktivni, izvlači one potrebne i dodaje ih u praćenje.
Ovaj pristup se dobro uklapa u Kubernetes strukturu, gdje sve također pluta: danas ima 10 servera, sutra 3. Da ne bi svaki put specificirali IP adresu servera, jednom su napisali kako da je pronađu - i Discovering će to učiniti .
Prometejev jezik se zove PromQL. Koristeći ovaj jezik, možete dobiti vrijednosti specifičnih metrika, a zatim ih pretvoriti, napraviti analitičke proračune na osnovu njih.
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 web interfejs
Prometheus ima svoj, prilično minimalistički web interfejs. Pogodno samo za otklanjanje grešaka ili demonstraciju.
U liniji Expression možete napisati upit na PromQL jeziku.
Kartica Upozorenja sadrži pravila upozorenja i imaju tri statusa:
- neaktivan - ako upozorenje trenutno nije aktivno, odnosno sve je u redu s njim i nije radilo;
- na čekanju - ovo je ako je upozorenje uspjelo, ali slanje još nije prošlo. Kašnjenje je podešeno da se nadoknadi treptanje mreže: ako je određena usluga porasla u roku od jedne minute, alarm se još ne bi trebao oglasiti;
- paljenje je treći status kada se pali upozorenje i šalje poruke.
U meniju Status ćete pronaći pristup informacijama o tome šta je Prometej. Postoji i prelazak na mete (targetove), o kojima smo gore govorili.
Za detaljniji pregled Prometheus interfejsa, pogledajte .
Integracija sa Grafanom
U web sučelju Prometheus nećete pronaći lijepe i razumljive grafikone iz kojih možete izvući zaključak o stanju klastera. Da bi ih izgradio, Prometheus je integriran s Grafanom. Dobijamo takve kontrolne table.
Postavljanje integracije Prometheusa i Grafane nije nimalo teško, upute možete pronaći u dokumentaciji: Pa, završiću sa ovim.
U sljedećim člancima nastavit ćemo s temom praćenja: govorit ćemo o prikupljanju i analizi dnevnika korištenjem Grafana Loki i alternativnih alata.
Autor: Marcel Ibraev, certificirani Kubernetes administrator, praktičan inženjer u kompaniji , govornik i programer kursa Slurm.
izvor: www.habr.com