Razmislite o konceptu spremljanja Kubernetes, se seznanite z orodjem Prometheus in se pogovorite o alarmiranju.
Tema spremljanja je obsežna, ni je mogoče razstaviti v enem članku. Namen tega besedila je zagotoviti pregled orodij, konceptov in pristopov.
Material članka je stiskanje iz . Če želite opraviti celoten tečaj - se prijavite na tečaj na .
Kaj se spremlja v gruči Kubernetes
fizične strežnike. Če je gruča Kubernetes nameščena na njenih strežnikih, morate spremljati njihovo zdravje. Zabbix obravnava to nalogo; če delate z njim, potem vam ni treba zavrniti, ne bo konfliktov. Zabbix je tisti, ki spremlja stanje naših strežnikov.
Preidimo na spremljanje na nivoju grozda.
Komponente nadzorne ravnine: API, razporejevalnik in drugi. Prepričati se morate vsaj, da je API strežnikov ali etcd večji od 0. Etcd lahko vrne veliko meritev: po diskih, na katerih se vrti, po zdravju gruče etcd in drugih.
Lučki delavec se je pojavil že zdavnaj in vsi se dobro zavedajo njegovih težav: veliko posod povzroča zmrzovanje in druge težave. Zato je treba nadzorovati tudi sam Docker kot sistem, vsaj glede razpoložljivosti.
dns. Če DNS odpade v gruči, potem bo za njim odpadla celotna storitev Discovery, klici med podi bodo prenehali delovati. V moji praksi takih težav ni bilo, vendar to ne pomeni, da stanja DNS ni treba spremljati. Zakasnitev zahteve in nekatere druge meritve je mogoče spremljati na CoreDNS.
Ingress. Potrebno je nadzorovati razpoložljivost vhodov (vključno z vhodnim krmilnikom) kot vstopnih točk v projekt.
Glavne komponente grozda so bile razstavljene - zdaj se spustimo na raven abstrakcije.
Zdi se, da se aplikacije izvajajo v podih, kar pomeni, da jih je treba nadzorovati, vendar v resnici niso. Podi so efemerni: danes tečejo na enem strežniku, jutri na drugem; danes jih je 10, jutri 2. Pods torej nihče ne spremlja. Znotraj arhitekture mikrostoritev je bolj pomembno nadzorovati razpoložljivost aplikacije kot celote. Še posebej preverite razpoložljivost končnih točk storitev: ali kaj deluje? Če je aplikacija na voljo, kaj se dogaja za njo, koliko replik je zdaj - to so vprašanja drugega reda. Ni potrebe po spremljanju posameznih primerkov.
Na zadnji ravni morate nadzorovati delovanje same aplikacije, vzeti poslovne metrike: število naročil, vedenje uporabnikov itd.
Prometej
Najboljši sistem za spremljanje grozda je . Ne poznam nobenega orodja, ki bi se po kakovosti in enostavnosti uporabe lahko kosalo s Prometejem. Odličen je za prilagodljivo infrastrukturo, tako da, ko rečejo "Kubernetes spremljanje", običajno mislijo na Prometheus.
Obstaja nekaj možnosti za začetek uporabe Prometheusa: s Helmom lahko namestite običajni Prometheus ali Prometheus Operator.
- Običajni Prometej. Z njim je vse v redu, vendar morate konfigurirati ConfigMap - pravzaprav napisati besedilne konfiguracijske datoteke, kot smo to počeli prej, pred arhitekturo mikroservisov.
- Prometheus Operator je nekoliko bolj razširjen, nekoliko bolj zapleten v smislu notranje logike, vendar je lažje delati z njim: obstajajo ločeni predmeti, abstrakcije so dodane v gručo, zato jih je veliko bolj priročno nadzorovati in konfigurirati.
Za razumevanje izdelka priporočam, da najprej namestite običajni Prometheus. Vse boste morali konfigurirati prek konfiguracije, vendar bo to koristno: ugotovili boste, kaj k čemu pripada in kako je konfigurirano. V Prometheus Operatorju se takoj povzpnete v abstrakcijo višje, čeprav se lahko po želji poglobite tudi v globino.
Prometheus je dobro integriran s Kubernetesom: lahko dostopa do strežnika API in komunicira z njim.
Prometheus je priljubljen, zato ga podpira veliko število aplikacij in programskih jezikov. Podpora je potrebna, saj ima Prometheus svoj format metrike, za prenos pa potrebujete knjižnico znotraj aplikacije ali že pripravljen izvoznik. In takih izvoznikov je kar nekaj. Na primer, obstaja PostgreSQL Exporter: vzame podatke iz PostgreSQL in jih pretvori v format Prometheus, tako da lahko Prometheus dela z njimi.
Prometejeva arhitektura
Strežnik Prometheus je zadnji del, Prometejevi možgani. Tukaj se shranjujejo in obdelujejo meritve.
Meritve so shranjene v bazi podatkov časovnih vrst (TSDB). TSDB ni ločena zbirka podatkov, temveč paket v jeziku Go, ki je vdelan v Prometheus. Grobo rečeno, vse je v eni dvojiški obliki.
Ne shranjujte podatkov v TSDB dolgo časa
Infrastruktura Prometheus ni primerna za dolgoročno shranjevanje metrik. Privzeto obdobje hrambe je 15 dni. To omejitev lahko presežete, vendar ne pozabite: več podatkov kot shranite v TSDB in dlje kot to počnete, več virov bo porabilo. Shranjevanje zgodovinskih podatkov v Prometheusu velja za slabo prakso.
Če imate ogromen promet, je število metrik več sto tisoč na sekundo, potem je bolje, da njihovo shranjevanje omejite glede na prostor na disku ali obdobje. Običajno so "vroči podatki" shranjeni v TSDB, meritve v samo nekaj urah. Za daljše shranjevanje se uporablja zunanji pomnilnik v tistih zbirkah podatkov, ki so za to res primerne, na primer InfluxDB, ClickHouse ipd. O ClickHouse sem videl več dobrih ocen.
Prometheus Server deluje na modelu potegnite: išče meritve do tistih končnih točk, ki smo mu jih dali. Rekli so: »pojdi na strežnik API«, in on gre tja vsakih n-tih sekund in vzame meritve.
Za objekte s kratko življenjsko dobo (opravilo ali opravilo cron), ki se lahko pojavijo med obdobji strganja, obstaja komponenta Pushgateway. Vanj so potisnjene metrike iz kratkoročnih objektov: opravilo se je dvignilo, izvedlo dejanje, poslalo metrike v Pushgateway in dokončalo. Čez nekaj časa se bo Prometheus spustil s svojim tempom in pobral te meritve iz Pushgatewaya.
Za konfiguracijo obvestil v Prometheusu obstaja ločena komponenta - Alertmanager. In pravila opozarjanja. Na primer, morate ustvariti opozorilo, če je strežniški API 0. Ko se dogodek sproži, se opozorilo posreduje upravitelju opozoril za nadaljnje pošiljanje. Upravitelj opozoril ima precej prilagodljive nastavitve usmerjanja: eno skupino opozoril lahko pošljete v telegramski klepet skrbnikov, drugo v klepet razvijalcev in tretjo v klepet infrastrukturnih delavcev. Obvestila je mogoče poslati na Slack, Telegram, e-pošto in druge kanale.
In na koncu vam bom povedal o funkciji morilca Prometheus - Odkrivanje. Pri delu s Prometheusom vam ni treba določiti posebnih naslovov objektov za spremljanje, dovolj je, da nastavite njihov tip. To pomeni, da vam ni treba pisati "tukaj je naslov IP, tukaj so vrata - monitor", namesto tega morate določiti, po katerih načelih najti te predmete (Cilji - cilji). Prometheus sam, odvisno od tega, kateri objekti so trenutno aktivni, potegne potrebne in jih doda v spremljanje.
Ta pristop se dobro ujema s strukturo Kubernetes, kjer tudi vse plava: danes je 10 strežnikov, jutri 3. Da ne bi vsakič navedli naslova IP strežnika, so enkrat napisali, kako ga najti - in Discovering bo to naredil .
Prometejev jezik se imenuje PromQL. Z uporabo tega jezika lahko dobite vrednosti določenih meritev in jih nato pretvorite ter na njihovi podlagi sestavite analitične izračune.
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)Spletni vmesnik Prometheus
Prometheus ima svoj, dokaj minimalističen spletni vmesnik. Primerno samo za odpravljanje napak ali predstavitev.
V vrstici Expression lahko napišete poizvedbo v jeziku PromQL.
Zavihek Opozorila vsebuje pravila za opozarjanje in imajo tri statuse:
- neaktivno - če opozorilo trenutno ni aktivno, to pomeni, da je z njim vse v redu in ni delovalo;
- čaka - to je, če je opozorilo delovalo, vendar pošiljanje še ni minilo. Zakasnitev je nastavljena tako, da kompenzira utripanje omrežja: če je navedena storitev narasla v eni minuti, se alarm še ne sme oglasiti;
- proženje je tretje stanje, ko opozorilo zasveti in pošilja sporočila.
V meniju Status boste našli dostop do informacij o tem, kaj je Prometheus. Obstaja tudi prehod na tarče (tarče), o katerih smo govorili zgoraj.
Za podrobnejši pregled vmesnika Prometheus glejte .
Integracija z Grafano
V spletnem vmesniku Prometheus ne boste našli lepih in razumljivih grafov, iz katerih bi lahko sklepali o stanju grozda. Za njihovo izdelavo je Prometheus integriran z Grafano. Dobimo takšne nadzorne plošče.
Nastavitev integracije Prometheus in Grafana sploh ni težavna, navodila najdete v dokumentaciji: No, s tem bom končal.
V naslednjih člankih bomo nadaljevali temo spremljanja: govorili bomo o zbiranju in analizi dnevnikov z uporabo Grafana Loki in alternativnih orodij.
Avtor: Marcel Ibraev, certificirani skrbnik Kubernetes, inženir v podjetju , govornik in razvijalec tečaja Slurm.
Vir: www.habr.com