Apsvarstykite Kubernetes stebėjimo koncepciją, susipažinkite su Prometheus įrankiu ir pakalbėkite apie perspėjimą.
Stebėjimo tema yra didelė, jos negalima išardyti viename straipsnyje. Šio teksto tikslas – pateikti priemonių, koncepcijų ir metodų apžvalgą.
Straipsnio medžiaga yra išspausta iš . Jei norite išklausyti visą kursą - užsiregistruokite į kursus .
Kas stebima Kubernetes klasteryje
fiziniai serveriai. Jei Kubernetes klasteris yra įdiegtas jo serveriuose, turite stebėti jų būklę. Zabbix atlieka šią užduotį; jei dirbi su juo, tai nereikia atsisakyti, nebus konfliktu. Būtent „Zabbix“ stebi mūsų serverių būseną.
Pereikime prie stebėjimo klasterio lygiu.
Valdymo plokštumos komponentai: API, planuoklis ir kt. Bent jau turite įsitikinti, kad serverių arba etcd API yra didesnė nei 0. Etcd gali grąžinti daugybę metrikų: pagal diskus, kuriuose jis sukasi, pagal etcd klasterio būklę ir kt.
dokininkas atsirado seniai ir visi puikiai žino jo problemas: daug konteinerių sukelia užšalimus ir kitas problemas. Todėl pati Docker, kaip sistema, taip pat turėtų būti kontroliuojama, bent jau prieinamumo.
dns. Jei klasteryje nukrenta DNS, tada po jo nukris visa „Discovery“ paslauga, skambučiai iš „pod“ į „pods“ nustos veikti. Mano praktikoje tokių problemų nebuvo, bet tai nereiškia, kad DNS būklės nereikia stebėti. Užklausos delsą ir kai kurias kitas metrikas galima stebėti „CoreDNS“.
Ingress. Būtina kontroliuoti įėjimų (įskaitant įėjimo valdiklį) prieinamumą kaip įėjimo į projektą taškus.
Pagrindiniai klasterio komponentai buvo išmontuoti – dabar nusileiskime iki abstrakcijų lygio.
Atrodytų, kad programos veikia poduose, o tai reiškia, kad jas reikia valdyti, tačiau iš tikrųjų taip nėra. Ankštys yra trumpalaikės: šiandien jos veikia viename serveryje, rytoj – kitame; šiandien jų yra 10, rytoj 2. Todėl ankščių niekas nestebi. Mikro paslaugų architektūroje svarbiau kontroliuoti visos programos prieinamumą. Visų pirma patikrinkite paslaugų galinių taškų prieinamumą: ar kas nors veikia? Jei programa yra prieinama, kas vyksta už jos, kiek dabar yra kopijų - tai antrosios eilės klausimai. Nereikia stebėti atskirų atvejų.
Paskutiniame lygyje reikia kontroliuoti pačios aplikacijos veikimą, paimti verslo metriką: užsakymų skaičių, vartotojų elgesį ir pan.
Prometėjas
Geriausia klasterio stebėjimo sistema yra . Nežinau jokio įrankio, kuris atitiktų Prometheus kokybę ir patogumą naudoti. Tai puikiai tinka lanksčiai infrastruktūrai, todėl kai jie sako „Kubernetes monitoringas“, paprastai jie turi omenyje Prometėją.
Yra keletas variantų, kaip pradėti dirbti su „Prometheus“: naudodami „Helm“ galite įdiegti įprastą „Prometheus“ arba „Prometheus“ operatorių.
- Reguliarus Prometėjas. Su juo viskas gerai, bet reikia sukonfigūruoti „ConfigMap“ – tiesą sakant, rašyti tekstinius konfigūracijos failus, kaip darėme anksčiau, prieš mikroserviso architektūrą.
- „Prometheus Operator“ yra šiek tiek labiau išsklaidytas, šiek tiek sudėtingesnis vidinės logikos prasme, tačiau su juo dirbti lengviau: yra atskiri objektai, į klasterį pridedamos abstrakcijos, todėl jas daug patogiau valdyti ir konfigūruoti.
Norint suprasti produktą, pirmiausia rekomenduoju įdiegti įprastą Prometheus. Viską turėsite sukonfigūruoti per konfigūraciją, bet tai bus naudinga: išsiaiškinsite, kas kam priklauso ir kaip sukonfigūruota. „Prometheus Operator“ iš karto pakili į abstrakciją aukščiau, nors jei nori, gali pasinerti ir į gelmes.
„Prometheus“ yra gerai integruotas su „Kubernetes“: jis gali pasiekti ir sąveikauti su API serveriu.
„Prometheus“ yra populiarus, todėl jį palaiko daugybė programų ir programavimo kalbų. Reikalingas palaikymas, nes „Prometheus“ turi savo metrikos formatą, o norint jį perkelti, reikia arba programos viduje esančios bibliotekos, arba paruošto eksportuotojo. O tokių eksportuotojų yra nemažai. Pavyzdžiui, yra PostgreSQL Exporter: ji paima duomenis iš PostgreSQL ir konvertuoja juos į Prometheus formatą, kad Prometheus galėtų su juo dirbti.
Prometėjo architektūra
Prometėjo serveris yra užpakalinė dalis, Prometėjo smegenys. Čia saugoma ir apdorojama metrika.
Metrika saugoma laiko eilučių duomenų bazėje (TSDB). TSDB nėra atskira duomenų bazė, o paketas Go kalba, įdėtas į Prometheus. Grubiai tariant, viskas yra viename dvejetayje.
Nelaikykite duomenų TSDB ilgą laiką
„Prometheus“ infrastruktūra netinkama ilgalaikiam metrikų saugojimui. Numatytasis saugojimo laikotarpis yra 15 dienų. Galite viršyti šią ribą, tačiau atminkite: kuo daugiau duomenų saugosite TSDB ir kuo ilgiau tai darysite, tuo daugiau išteklių sunaudosite. Istorinių duomenų saugojimas „Prometheus“ laikomas bloga praktika.
Jei srautas yra didžiulis, metrikų skaičius yra šimtai tūkstančių per sekundę, tada geriau apriboti jų saugojimą pagal vietą diske arba pagal laikotarpį. Paprastai „karštieji duomenys“ saugomi TSDB, o metrika vos per kelias valandas. Ilgesniam saugojimui išorinė saugykla naudojama tose duomenų bazėse, kurios tam tikrai tinka, pavyzdžiui, InfluxDB, ClickHouse ir pan. Mačiau daugiau gerų atsiliepimų apie ClickHouse.
Modelyje veikia Prometheus serveris traukti: jis ieško metrikos tiems galutiniams taškams, kuriuos jam suteikėme. Jie pasakė: „eikite į API serverį“, o jis ten eina kas n-tą sekundžių skaičių ir paima metrikas.
Objektams, kurių eksploatavimo laikas trumpas (užduotis arba cron darbas), kurie gali atsirasti tarp grandymo laikotarpių, yra „Pushgateway“ komponentas. Į jį įstumiama metrika iš trumpalaikių objektų: darbas pakilo, atliko veiksmą, išsiuntė metriką į Pushgateway ir baigė. Po kurio laiko „Prometheus“ nusileis savo tempu ir paims šiuos duomenis iš „Pushgateway“.
Norėdami sukonfigūruoti pranešimus „Prometheus“, yra atskiras komponentas - Alert Manager. Ir įspėjimo taisyklės. Pavyzdžiui, turite sukurti įspėjimą, jei serverio API yra 0. Kai įvykis suaktyvinamas, įspėjimas perduodamas įspėjimų tvarkytuvui, kad jis būtų išsiųstas toliau. Perspėjimų tvarkyklė turi gana lanksčius maršruto nustatymus: viena įspėjimų grupė gali būti siunčiama į administratorių telegramų pokalbį, kita – į kūrėjų, trečia – į infrastruktūros darbuotojų pokalbį. Pranešimus galima siųsti „Slack“, „Telegram“, el. paštu ir kitais kanalais.
Ir galiausiai aš jums papasakosiu apie Prometėjo žudiko funkciją - Atranda. Dirbant su Prometheus nereikia nurodyti konkrečių stebėjimo objektų adresų, užtenka nustatyti jų tipą. Tai yra, jums nereikia rašyti „čia yra IP adresas, čia yra prievadas - monitorius“, o vietoj to turite nustatyti, kokiais principais reikia rasti šiuos objektus (tikslai - įvarčiai). Pats Prometėjas, priklausomai nuo to, kurie objektai šiuo metu yra aktyvūs, ištraukia reikiamus ir prideda juos prie stebėjimo.
Toks požiūris puikiai dera su Kubernetes struktūra, kur viskas taip pat plaukioja: šiandien yra 10 serverių, rytoj 3. Kad serverio IP adresas nenurodytų kiekvieną kartą, vieną kartą parašė, kaip jį rasti – ir Discovering tai padarys. .
Prometėjo kalba vadinama PromQL. Naudodami šią kalbą galite gauti konkrečių metrikų reikšmes ir jas konvertuoti bei pagal jas atlikti analitinius skaičiavimus.
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 žiniatinklio sąsaja
„Prometheus“ turi savo, gana minimalistinę žiniatinklio sąsają. Tinka tik derinimui arba demonstravimui.
Išraiškos eilutėje galite parašyti užklausą PromQL kalba.
Įspėjimų skirtuke yra įspėjimų taisyklės, kurios turi tris būsenas:
- neaktyvus - jei perspėjimas šiuo metu neaktyvus, tai yra, viskas su juo gerai ir jis neveikė;
- laukiama – tai yra, jei perspėjimas veikė, bet siuntimas dar nepraėjo. Uždelsimas nustatytas taip, kad kompensuotų tinklo mirksėjimą: jei nurodyta paslauga pakilo per minutę, signalas dar neturėtų skambėti;
- šaudymas yra trečioji būsena, kai užsidega perspėjimas ir siunčiami pranešimai.
Būsenos meniu rasite prieigą prie informacijos apie tai, kas yra Prometėjas. Taip pat yra perėjimas prie taikinių (taikinių), apie kuriuos kalbėjome aukščiau.
Išsamesnę Prometheus sąsajos apžvalgą žr .
Integracija su Grafana
„Prometheus“ žiniatinklio sąsajoje nerasite gražių ir suprantamų grafikų, iš kurių galėtumėte padaryti išvadą apie klasterio būklę. Norint juos sukurti, „Prometheus“ yra integruotas su „Grafana“. Mes gauname tokius prietaisų skydelius.
Nustatyti Prometheus ir Grafana integraciją visai nesunku, instrukcijas rasite dokumentacijoje: Na, tuo ir baigsiu.
Tolesniuose straipsniuose tęsime stebėjimo temą: kalbėsime apie žurnalų rinkimą ir analizę naudojant Grafana Loki ir alternatyvius įrankius.
Autorius: Marcel Ibraev, sertifikuotas Kubernetes administratorius, praktikuojantis inžinierius įmonėje , pranešėjas ir kursų kūrėjas Slurm.
Šaltinis: www.habr.com