Íhugaðu hugmyndina um Kubernetes eftirlit, kynntu þér Prometheus tólið og talaðu um viðvörun.
Vöktunarefnið er fyrirferðarmikið, það er ekki hægt að taka það í sundur í einni grein. Tilgangur þessa texta er að veita yfirsýn yfir verkfæri, hugtök og nálganir.
Efni greinarinnar er kreista úr . Ef þú vilt taka fullt námskeið - skráðu þig á námskeið á .
Hvað er fylgst með í Kubernetes klasa
líkamlegir netþjónar. Ef Kubernetes þyrpingin er sett á netþjóna hans þarftu að fylgjast með heilsu þeirra. Zabbix sér um þetta verkefni; ef þú vinnur með honum, þá þarftu ekki að neita, það verða engin átök. Það er Zabbix sem fylgist með stöðu netþjóna okkar.
Förum yfir í vöktun á klasastigi.
Íhlutir stjórnplans: API, tímaáætlun og aðrir. Að minnsta kosti þarftu að ganga úr skugga um að API netþjóna eða etcd sé stærra en 0. Etcd getur skilað mörgum mælingum: eftir diskunum sem það snýst á, eftir heilsu etcd klasans og fleira.
Docker birtist fyrir löngu síðan og allir vita vel um vandamál þess: mikið af gámum mynda frost og önnur vandamál. Þess vegna ætti Docker sjálft, sem kerfi, einnig að vera stjórnað, að minnsta kosti fyrir framboð.
dns. Ef DNS dettur af í þyrpingunni, þá mun öll Discovery þjónustan falla af eftir það, símtöl frá belg til belg hætta að virka. Í starfi mínu voru engin slík vandamál, en þetta þýðir ekki að ekki þurfi að fylgjast með ástandi DNS. Hægt er að rekja biðtíma og nokkrar aðrar mælingar á CoreDNS.
Inngangur. Nauðsynlegt er að stjórna framboði innrása (þar á meðal inngangsstýringar) sem inngangspunkta í verkefnið.
Helstu þættir þyrpingarinnar hafa verið teknir í sundur - nú skulum við fara niður á svið abstrakt.
Það virðist sem forrit keyra í belgjum, sem þýðir að það þarf að stjórna þeim, en í raun er það ekki. Belg eru skammvinn: í dag keyra þeir á einum netþjóni, á morgun á öðrum; í dag eru þeir 10, á morgun 2. Því fylgist enginn með belgunum. Innan örþjónustuarkitektúrs er mikilvægara að stjórna framboði forritsins í heild sinni. Sérstaklega, athugaðu framboð þjónustuenda: virkar eitthvað? Ef forritið er tiltækt, hvað gerist á bak við það, hversu margar eftirlíkingar eru núna - þetta eru spurningar af annarri röð. Það er engin þörf á að fylgjast með einstökum tilvikum.
Á síðasta stigi þarftu að stjórna rekstri forritsins sjálfs, taka viðskiptamælingar: fjölda pantana, hegðun notenda og svo framvegis.
Prometheus
Besta kerfið til að fylgjast með klasa er . Ég veit ekki um neitt tól sem jafnast á við Prometheus hvað varðar gæði og auðvelda notkun. Það er frábært fyrir sveigjanlega innviði, þannig að þegar þeir segja „Kubernetes eftirlit“ meina þeir venjulega Prometheus.
Það eru nokkrir möguleikar til að byrja með Prometheus: með því að nota Helm geturðu sett upp venjulegan Prometheus eða Prometheus Operator.
- Venjulegur Prometheus. Allt er í lagi með hann, en þú þarft að stilla ConfigMap - í raun, skrifa texta-undirstaða stillingar skrár, eins og við gerðum áður, fyrir microservice arkitektúr.
- Prometheus Operator er aðeins dreifðari, aðeins flóknari hvað varðar innri rökfræði, en það er auðveldara að vinna með það: það eru aðskildir hlutir, abstraktum er bætt við þyrpinguna, þannig að það er miklu þægilegra að stjórna þeim og stilla.
Til að skilja vöruna mæli ég með því að setja upp venjulegan Prometheus fyrst. Þú verður að stilla allt í gegnum stillinguna, en þetta mun vera gagnlegt: þú munt finna út hvað tilheyrir hverju og hvernig það er stillt. Í Prometheus Operator rís þú strax upp í abstrakt hærra, þó þú getir líka kafað ofan í djúpið ef þú vilt.
Prometheus er vel samþætt Kubernetes: það getur fengið aðgang að og haft samskipti við API netþjóninn.
Prometheus er vinsælt og þess vegna styður mikill fjöldi forrita og forritunarmála það. Stuðningur er nauðsynlegur þar sem Prometheus hefur sitt eigið mælikvarðasnið og til að flytja það þarftu annað hvort bókasafn inni í forritinu eða tilbúinn útflytjanda. Og það eru allmargir slíkir útflytjendur. Til dæmis er PostgreSQL Exporter: það tekur gögn frá PostgreSQL og breytir þeim í Prometheus snið svo að Prometheus geti unnið með það.
Prometheus arkitektúr
Prometheus þjónn er afturendinn, heili Prómeþeifs. Mælingar eru geymdar og unnar hér.
Mælingarnar eru geymdar í tímaraðagagnagrunninum (TSDB). TSDB er ekki sérstakur gagnagrunnur, heldur pakki á Go tungumálinu sem er innbyggt í Prometheus. Í grófum dráttum er allt í einum tvíflokki.
Ekki geyma gögn í TSDB í langan tíma
Prometheus innviðir henta ekki til langtíma geymslu mæligilda. Sjálfgefinn varðveislutími er 15 dagar. Þú getur farið yfir þessi mörk, en hafðu í huga: því fleiri gögn sem þú geymir í TSDB og því lengur sem þú gerir það, því meira fjármagn mun það eyða. Að geyma söguleg gögn í Prometheus er talin slæm venja.
Ef þú ert með mikla umferð, fjöldi mæligilda er hundruð þúsunda á sekúndu, þá er betra að takmarka geymslu þeirra eftir plássi eða eftir tímabilum. Venjulega eru „heit gögn“ geymd í TSDB, mælingar á aðeins nokkrum klukkustundum. Fyrir lengri geymslu er ytri geymsla notuð í þeim gagnagrunnum sem henta í raun fyrir þetta, til dæmis InfluxDB, ClickHouse og svo framvegis. Ég sá fleiri góða dóma um ClickHouse.
Prometheus Server vinnur á líkaninu draga: hann fer í mælikvarða á þá endapunkta sem við gáfum honum. Þeir sögðu: „farðu á API netþjóninn“ og hann fer þangað á n. sekúndu fresti og tekur mælikvarðana.
Fyrir hluti með stuttan líftíma (starf eða cron starf) sem geta birst á milli skraptímabila, er Pushgateway hluti. Mælingum frá skammtímahlutum er ýtt inn í það: verkið hefur hækkað, framkvæmt aðgerð, sent mæligildi til Pushgateway og lokið. Eftir smá stund mun Prometheus koma niður á sínum eigin hraða og taka upp þessar mælingar frá Pushgateway.
Til að stilla tilkynningar í Prometheus er sérstakur hluti - Viðvörunarstjóri. Og viðvörunarreglurnar. Til dæmis, þú þarft að búa til viðvörun ef API netþjónsins er 0. Þegar atburðurinn kviknar er viðvörunin send til viðvörunarstjórans til frekari sendingar. Viðvörunarstjórinn hefur nokkuð sveigjanlegar leiðarstillingar: einn hóp viðvarana er hægt að senda í símskeytaspjall stjórnenda, annan í spjall þróunaraðila og þann þriðja í spjall innviðastarfsmanna. Hægt er að senda tilkynningar á Slack, Telegram, tölvupóst og aðrar rásir.
Og að lokum skal ég segja þér frá Prometheus killer eiginleikanum - Uppgötvun. Þegar þú vinnur með Prometheus þarftu ekki að tilgreina ákveðin heimilisföng hluta til að fylgjast með, það er nóg að stilla gerð þeirra. Það er, þú þarft ekki að skrifa "hér er IP vistfangið, hér er höfnin - skjár", í staðinn þarftu að ákvarða með hvaða reglum til að finna þessa hluti (markmið - markmið). Prometheus sjálfur, eftir því hvaða hlutir eru virkir um þessar mundir, dregur upp nauðsynlega og bætir þeim við eftirlit.
Þessi nálgun passar vel við Kubernetes uppbygginguna, þar sem allt svífur líka: í dag eru 10 netþjónar, á morgun 3. Til að tilgreina ekki IP tölu netþjónsins í hvert sinn skrifuðu þeir einu sinni hvernig á að finna það - og Discovering mun gera það .
Prómetheus tungumálið er kallað PromQL. Með því að nota þetta tungumál geturðu fengið gildi tiltekinna mælikvarða og síðan umbreytt þeim, byggt upp greiningarútreikninga út frá þeim.
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 vefviðmót
Prometheus hefur sitt eigið, frekar naumhyggjulegt vefviðmót. Aðeins hentugur fyrir kembiforrit eða sýnikennslu.
Í Expression línunni geturðu skrifað fyrirspurn á PromQL tungumálinu.
Viðvaranir flipinn inniheldur viðvörunarreglur og þær hafa þrjár stöður:
- óvirkt - ef viðvörunin er ekki virk í augnablikinu, það er, allt er í lagi með hana og hún virkaði ekki;
- í bið - þetta er ef viðvörunin virkaði en sendingin hefur ekki enn staðist. Töfin er stillt til að bæta upp fyrir blikkandi netkerfi: ef tilgreind þjónusta hefur hækkað innan mínútu ætti viðvörunin ekki að hljóma ennþá;
- hleypa er þriðja ástandið þegar viðvörunin kviknar og sendir skilaboð.
Í stöðuvalmyndinni finnur þú aðgang að upplýsingum um hvað Prometheus er. Það er líka skipt yfir í markmiðin (markmiðin), sem við ræddum um hér að ofan.
Fyrir nánari yfirlit yfir Prometheus viðmótið, sjá .
Samþætting við Grafana
Í Prometheus vefviðmótinu finnur þú ekki falleg og skiljanleg línurit sem hægt er að draga ályktun af um ástand klasans. Til að byggja þá er Prometheus samþætt við Grafana. Við fáum svona mælaborð.
Það er alls ekki erfitt að setja upp Prometheus og Grafana samþættingu, þú getur fundið leiðbeiningar í skjölunum: Jæja, ég ætla að enda á þessu.
Í eftirfarandi greinum munum við halda áfram með eftirlitsefnið: við munum tala um að safna og greina annála með Grafana Loki og öðrum verkfærum.
Höfundur: Marcel Ibraev, löggiltur Kubernetes stjórnandi, starfandi verkfræðingur í fyrirtækinu , ræðumaður og námskeiðshaldari Slurm.
Heimild: www.habr.com