Konsideroni konceptin e monitorimit të Kubernetes, njihuni me mjetin Prometheus dhe flisni për sinjalizimin.
Tema e monitorimit është voluminoze, nuk mund të çmontohet në një artikull. Qëllimi i këtij teksti është të ofrojë një pasqyrë të mjeteve, koncepteve dhe qasjeve.
Materiali i artikullit është një shtrydhje nga . Nëse dëshironi të merrni një kurs të plotë - regjistrohuni për një kurs në .
Çfarë monitorohet në një grup Kubernetes
serverët fizikë. Nëse grupi Kubernetes është vendosur në serverët e tij, ju duhet të monitoroni shëndetin e tyre. Zabbix merret me këtë detyrë; nëse punoni me të, atëherë nuk keni nevojë të refuzoni, nuk do të ketë konflikte. Është Zabbix ai që monitoron gjendjen e serverëve tanë.
Le të kalojmë te monitorimi në nivel grupi.
Komponentët e planit të kontrollit: API, Scheduler dhe të tjerë. Së paku, duhet të siguroheni që API-ja e serverëve ose etcd është më e madhe se 0. Etcd mund të kthejë shumë metrika: nga disqet në të cilat po rrotullohet, nga shëndeti i grupit të tij etcd dhe të tjera.
prerës u shfaq shumë kohë më parë dhe të gjithë janë të vetëdijshëm për problemet e tij: shumë kontejnerë gjenerojnë ngrirje dhe probleme të tjera. Prandaj, vetë Docker, si sistem, duhet gjithashtu të kontrollohet, të paktën për disponueshmërinë.
DNS Nëse DNS bie në grup, atëherë i gjithë shërbimi Discovery do të bjerë pas tij, thirrjet nga pods në pods do të ndalojnë së punuari. Në praktikën time, nuk kishte probleme të tilla, por kjo nuk do të thotë që gjendja e DNS nuk ka nevojë të monitorohet. Vonesa e kërkesës dhe disa metrika të tjera mund të gjurmohen në CoreDNS.
Hyrja. Është e nevojshme të kontrollohet disponueshmëria e hyrjeve (përfshirë kontrolluesin e hyrjes) si pika hyrëse në projekt.
Komponentët kryesorë të grupimit janë çmontuar - tani le të zbresim në nivelin e abstraksioneve.
Duket se aplikacionet funksionojnë në pods, që do të thotë se ato duhet të kontrollohen, por në realitet nuk janë. Pods janë kalimtare: sot ato funksionojnë në një server, nesër në një tjetër; sot janë 10 prej tyre, nesër 2. Prandaj, askush nuk monitoron pods. Brenda një arkitekture mikroservice, është më e rëndësishme të kontrollohet disponueshmëria e aplikacionit në tërësi. Në veçanti, kontrolloni disponueshmërinë e pikave fundore të shërbimit: a funksionon ndonjë gjë? Nëse aplikacioni është i disponueshëm, atëherë çfarë ndodh pas tij, sa kopje janë tani - këto janë pyetje të rendit të dytë. Nuk ka nevojë të monitorohen rastet individuale.
Në nivelin e fundit, ju duhet të kontrolloni funksionimin e vetë aplikacionit, të merrni matjet e biznesit: numrin e porosive, sjelljen e përdoruesit, etj.
Prometeu
Sistemi më i mirë për monitorimin e një grupi është . Unë nuk di ndonjë mjet që mund të përputhet me Prometheus për nga cilësia dhe lehtësia e përdorimit. Është i shkëlqyeshëm për infrastrukturën fleksibël, kështu që kur thonë "Monitorimi i Kubernetes", ata zakonisht nënkuptojnë Prometheun.
Ka disa opsione për të filluar me Prometheus: duke përdorur Helm, mund të instaloni një Operator të rregullt Prometheus ose Prometheus.
- Prometeu i rregullt. Gjithçka është në rregull me të, por ju duhet të konfiguroni ConfigMap - në fakt, shkruani skedarë konfigurimi të bazuar në tekst, siç bëmë më parë, përpara arkitekturës së mikroservisit.
- Operatori Prometheus është pak më i përhapur, pak më i ndërlikuar për sa i përket logjikës së brendshme, por është më e lehtë të punosh me të: ka objekte të veçanta, abstraksione shtohen në grup, kështu që ato janë shumë më të përshtatshme për t'u kontrolluar dhe konfiguruar.
Për të kuptuar produktin, rekomandoj fillimisht instalimin e Prometheus-it të rregullt. Do të duhet të konfiguroni gjithçka përmes konfigurimit, por kjo do të jetë e dobishme: do të kuptoni se çfarë i përket asaj dhe si është konfiguruar. Në Operatorin Prometheus, ju ngriheni menjëherë në një abstraksion më të lartë, megjithëse mund të gërmoni edhe në thellësi nëse dëshironi.
Prometheus është i integruar mirë me Kubernetes: ai mund të hyjë dhe të ndërveprojë me serverin API.
Prometheus është i popullarizuar, kjo është arsyeja pse një numër i madh i aplikacioneve dhe gjuhëve të programimit e mbështesin atë. Mbështetja është e nevojshme, pasi Prometheus ka formatin e vet të metrikës, dhe për ta transferuar atë, ju duhet ose një bibliotekë brenda aplikacionit ose një eksportues i gatshëm. Dhe ka mjaft eksportues të tillë. Për shembull, ekziston PostgreSQL Exporter: merr të dhëna nga PostgreSQL dhe i konverton në formatin Prometheus në mënyrë që Prometheus të mund të punojë me të.
Arkitektura e Prometeut
Serveri Prometheus është fundi i pasëm, truri i Prometeut. Metrikat ruhen dhe përpunohen këtu.
Metrikat ruhen në bazën e të dhënave të serive kohore (TSDB). TSDB nuk është një bazë të dhënash e veçantë, por një paketë në gjuhën Go që është e ngulitur në Prometheus. Përafërsisht, gjithçka është në një binar.
Mos ruani të dhëna në TSDB për një kohë të gjatë
Infrastruktura Prometheus nuk është e përshtatshme për ruajtjen afatgjatë të metrikës. Periudha e paracaktuar e ruajtjes është 15 ditë. Ju mund ta tejkaloni këtë kufi, por mbani në mend: sa më shumë të dhëna të ruani në TSDB dhe sa më gjatë ta bëni atë, aq më shumë burime do të konsumojë. Ruajtja e të dhënave historike në Prometeu konsiderohet praktikë e keqe.
Nëse keni trafik të madh, numri i metrikës është qindra mijëra në sekondë, atëherë është më mirë të kufizoni ruajtjen e tyre sipas hapësirës në disk ose sipas periudhës. Zakonisht, "të dhënat e nxehta" ruhen në TSDB, metrikë në vetëm disa orë. Për ruajtje më të gjatë, ruajtja e jashtme përdoret në ato baza të të dhënave që janë vërtet të përshtatshme për këtë, për shembull, InfluxDB, ClickHouse, etj. Pashë më shumë komente të mira për ClickHouse.
Serveri Prometheus punon në model tërheq: ai shkon për metrikë në ato pika fundore që i dhamë. Ata thanë: "shkoni te serveri API", dhe ai shkon atje çdo n-të numër sekondash dhe merr matjet.
Për objektet me jetëgjatësi të shkurtër (punë ose cron job) që mund të shfaqen midis periudhave të gërvishtjes, ekziston një komponent Pushgateway. Metrikat nga objektet afatshkurtra futen në të: puna është ngritur, ka kryer një veprim, ka dërguar metrikë në Pushgateway dhe ka përfunduar. Pas një kohe, Prometheus do të zbresë me ritmin e vet dhe do të marrë këto metrika nga Pushgateway.
Për të konfiguruar njoftimet në Prometheus ekziston një komponent i veçantë - Menaxher Alert. Dhe rregullat e alarmit. Për shembull, duhet të krijoni një sinjalizim nëse API i serverit është 0. Kur ngjarja ndizet, sinjalizimi i kalohet menaxherit të sinjalizimeve për dërgim të mëtejshëm. Menaxheri i sinjalizimeve ka cilësime mjaft fleksibël të rrugëtimit: një grup sinjalizimesh mund të dërgohen në bisedën e telegramit të administratorëve, një tjetër në bisedën e zhvilluesve dhe një të tretë në bisedën e punonjësve të infrastrukturës. Njoftimet mund të dërgohen në Slack, Telegram, email dhe kanale të tjera.
Dhe së fundi, do t'ju tregoj për tiparin e vrasësve të Prometheut - Zbulimi. Kur punoni me Prometheus, nuk keni nevojë të specifikoni adresa specifike të objekteve për monitorim, mjafton të vendosni llojin e tyre. Kjo do të thotë, nuk keni nevojë të shkruani "këtu është adresa IP, këtu është porti - monitor", përkundrazi, duhet të përcaktoni se me cilat parime t'i gjeni këto objekte (objektivat - qëllimet). Vetë Prometeu, në varësi të objekteve që janë aktualisht aktive, tërheq ato të nevojshme dhe i shton ato në monitorim.
Kjo qasje përshtatet mirë me strukturën Kubernetes, ku gjithçka noton gjithashtu: sot ka 10 serverë, nesër 3. Për të mos specifikuar adresën IP të serverit çdo herë, ata shkruan një herë se si ta gjenin atë - dhe Discovering do ta bëjë atë .
Gjuha e Prometeut quhet PromQL. Duke përdorur këtë gjuhë, ju mund të merrni vlerat e metrikave specifike dhe më pas t'i konvertoni ato, të ndërtoni llogaritje analitike bazuar në to.
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)Ndërfaqja e internetit Prometheus
Prometheus ka ndërfaqen e vet, mjaft minimaliste në internet. I përshtatshëm vetëm për korrigjim ose demonstrim.
Në linjën Expression, mund të shkruani një pyetje në gjuhën PromQL.
Skeda Alert përmban rregulla sinjalizuese dhe ato kanë tre statuse:
- joaktiv - nëse alarmi nuk është aktiv për momentin, domethënë, gjithçka është në rregull me të dhe nuk funksionoi;
- në pritje - kjo është nëse sinjalizimi ka funksionuar, por dërgimi nuk ka kaluar ende. Vonesa është caktuar për të kompensuar pulsimin e rrjetit: nëse shërbimi i specifikuar është ngritur brenda një minute, atëherë alarmi nuk duhet të bjerë ende;
- shkrepja është statusi i tretë kur alarmi ndizet dhe dërgon mesazhe.
Në menynë Status do të gjeni akses në informacione se çfarë është Prometheus. Ekziston edhe një kalim në objektivat (objektivat), për të cilat folëm më lart.
Për një përmbledhje më të detajuar të ndërfaqes Prometheus, shih .
Integrimi me Grafanën
Në ndërfaqen e internetit Prometheus, nuk do të gjeni grafikë të bukur dhe të kuptueshëm nga të cilët mund të nxirrni një përfundim për gjendjen e grupit. Për t'i ndërtuar ato, Prometeu është integruar me Grafanën. Ne marrim panele të tilla.
Vendosja e integrimit Prometheus dhe Grafana nuk është aspak e vështirë, mund të gjeni udhëzime në dokumentacion: Epo, do të përfundoj me këtë.
Në artikujt e mëposhtëm do të vazhdojmë temën e monitorimit: do të flasim për mbledhjen dhe analizimin e regjistrave duke përdorur Grafana Loki dhe mjete alternative.
Autori: Marcel Ibraev, administrator i certifikuar i Kubernetes, inxhinier praktikues në kompani , folës dhe zhvillues kursi Slurm.
Burimi: www.habr.com