Le të shqyrtojmë konceptin e monitorimit të Kubernetes, të njihemi me mjetin Prometheus dhe të flasim për alarmin.
Tema e monitorimit është e gjerë; nuk mund të shqyrtohet në një artikull të vetëm. Qëllimi i këtij teksti është të ofrojë një pasqyrë të përgjithshme mbi veglat, konceptet dhe qasjet.
Materiali i artikullit Ă«shtĂ« njĂ« pĂ«rmbledhje nga . NĂ«se dĂ«shironi tĂ« ndiqni njĂ« trajnim tĂ« plotĂ« â regjistrohuni nĂ« kursin mbi .
ĂfarĂ« monitorohet nĂ« klasterin Kubernetes
Serverat fizikë. Nëse klasteri i Kubernetes është instaluar në serverat tuaj, duhet të monitoroni shëndetin e tyre. Kjo detyrë përmbushet nga Zabbix; nëse punoni me të, nuk duhet të heqni dorë, nuk do të ketë konflikte. Zabbix e monitoron gjendjen e serverëve tanë.
Le të kalojmë në monitorimin në nivelin e klasterit.
Komponentët e Control Plane: API, Planifikuesi dhe të tjerë. Të paktën, duhet të monitoroni që numri i serverëve API ose etcd të jetë më shumë se 0. Etcd është në gjendje të ofrojë shumë metrika: për diskët që ai operon, për shëndetin e vet të klasterit etcd dhe të tjera.
Docker ka lindur prej kohe dhe problemet e tij janë të njohura për të gjithë: shumë konteinerë shkaktojnë ngadalësime dhe probleme të tjera. Prandaj, duhet gjithashtu të monitoroni vetë Dockerin, edhe për nga disponueshmëria.
DNS. Nëse në klaster dështon DNS, atëherë do të dështojë gjithashtu e gjithë shërbimi i Discovery, dhe komunikimet midis konteinerëve do të ndalojnë. Në praktiken time nuk kam hasur në probleme të tilla, por kjo nuk do të thotë se nuk duhet të monitoroni gjendjen e DNS. Mund të monitoroni vonesat në kërkesa dhe disa metrika të tjera në CoreDNS.
Ingress. Duhet të monitoroni disponueshmërinë e ingress-ëve (përfshirë Ingress Controller) si pika hyrëse në projekt.
NĂ« kemi shqyrtuar komponentĂ«t kryesorĂ« tĂ« klasterit â tani le tĂ« zhytemi mĂ« thellĂ«, nĂ« nivelin e abstraksioneve.
Duket se aplikacionet ekzekutohen nĂ« konteinerĂ«, prandaj duhet t'i kontrollojmĂ«, por nĂ« tĂ« vĂ«rtetĂ« jo. KonteinerĂ«t janĂ« efemerĂ«: sot punojnĂ« nĂ« njĂ« server, nesĂ«r nĂ« njĂ« tjetĂ«r; sot janĂ« 10, nesĂ«r 2. Prandaj, askush nuk monitoron thjesht konteinerĂ«t. Brenda arkitekturĂ«s mikro-shĂ«rbimesh, Ă«shtĂ« mĂ« e rĂ«ndĂ«sishme tĂ« monitoroni disponueshmĂ«rinĂ« e aplikacionit si njĂ« tĂ«rĂ«si. Konkretisht, tĂ« kontrolloni disponueshmĂ«rinĂ« e endpoint-eve tĂ« shĂ«rbimit: a funksionon ndonjĂ« gjĂ«? NĂ«se aplikacioni Ă«shtĂ« i aksesueshĂ«m, atĂ«herĂ« çfarĂ« ndodh pas tij, sa replikat ka tani â kĂ«to janĂ« pyetje tĂ« natyrave tĂ« dyta. TĂ« monitorosh instancat e veçanta nuk Ă«shtĂ« e nevojshme.
Në nivelin e fundit, duhet të kontrolloni funksionimin e aplikacionit vetë, të merren metrikat e biznesit: numri i porosive, sjellja e përdoruesve dhe të tjera.
Prometheus
Sistemi më i mirë për monitorimin e klasterit është . Nuk di asnjë mjet që mund të krahasohet me Prometheus për cilësi dhe lehtësi përdorimi. Ai është i përshtatshëm për infrastrukturë fleksibël, prandaj kur flitet për «monitorimin e Kubernetes», zakonisht nënkupton Prometheus.
Ka disa opsione për të filluar punën me Prometheus: me ndihmën e Helm mund të instaloni Prometheus tradicional ose Prometheus Operator.
- Prometheus tradicional. Ai funksionon mirë, por duhet të konfigurohet ConfigMap - në thelb, të shkruhen skedarë konfigurimi tekstual, siç bënim më parë, para arkitekturës mikroshërbimesh.
- Prometheus Operator është pak më kompleks, pak më i ndërlikuar në logjikën e brendshme, por është më e lehtë të punosh me të: ka objekte të veçanta, abstraksione që shtohen në klaster, prandaj është shumë më e lehtë t'i kontrollosh dhe t'i konfigurosh.
Për të kuptuar produktin, ju rekomandoj fillimisht të instaloni Prometheus tradicional. Do të duhet të gjithë ta konfiguroni përmes konfigurimit, por kjo do t'ju ndihmojë: do të kuptoni se çfarë lidhet me çfarë dhe si të konfigurohet. Në Prometheus Operator ju menjëherë ngjiteni në një abstraksion më të lartë, megjithatë, nëse dëshironi të thelloheni në thellësi, kjo gjithashtu do të jetë e mundur.
Prometheus është shumë i integruar me Kubernetes: mund të qaset në API Server dhe të ndërveprojë me të.
Prometheus është popullor, prandaj mbështetet nga shumë aplikacione dhe gjuhë programuese. Mbështetje nevojitet, pasi Prometheus ka formatin e vet të metrikave, dhe për ta dërguar atë nevojitet ose një bibliotekë brenda aplikacionit, ose një eksportues i gatshëm. Dhe ka shumë eksportues të tillë. Për shembull, ka një PostgreSQL Exporter: ai merr të dhënat nga PostgreSQL dhe i konverton ato në formatin Prometheus, në mënyrë që Prometheus të mund të punojë me to.
Arkitektura e Prometheus
Prometheus Server â Ă«shtĂ« pjesa serverike, truri i Prometheus. KĂ«tu ruhen dhe pĂ«rpunohen metrikat.
Metrikat ruhen në një bazë të të dhënave të serive të kohës (TSDB). TSDB nuk është një bazë e veçantë të dhënash, por një paketë në gjuhën Go, e cila është e integruar në Prometheus. Thënë thjesht, gjithçka ndodhet në një binar të vetëm.
Mos e ruhni të dhënat në TSDB për një kohë të gjatë
Infrastruktura Prometheus nuk është e përshtatshme për ruajtjen afatgjatë të metrikave. Sipas parazgjedhjes, periudha e ruajtjes është 15 ditë. Ky kufizim mund të tejkalohet, por duhet të keni parasysh: sa më shumë të dhëna të ruani në TSDB dhe sa më gjatë ta bëni këtë, aq më shumë burime do të konsumoni. Ruajtja e të dhënave historike në Prometheus konsiderohet praktikë e keqe.
Nëse keni trafik të madh, numri i metrikave matet me qindra mijëra në sekondë, atëherë është më mirë të kufizoni ruajtjen sipas volumit të diskut ose sipas kohës. Zakonisht në TSDB ruhen "të dhëna të nxehta", metrikat për disa orë. Për ruajtje më të gjatë përdoren depozita të jashtme në ato databaza që vërtet janë të përshtatshme për këtë, si InfluxDB, ClickHouse etj. Kam dëgjuar shumë komente pozitive për ClickHouse.
Prometheus Server punon sipas modelit pull: ai vetë shkon për metrikat në ato endpoint-e që i kemi dhënë. I thamë: «shko në API Server», dhe ai shkon aty çdo n sekonda dhe merr metrikat.
Për objektet me jetëgjatësi të shkurtër (job ose cron job), të cilat mund të shfaqen në mes të periudhave të skrapimit, ka një komponent Pushgateway. Në të dërgohen metrikat nga objektet afatshkurtra: job u ngrit, kryen veprimin, dërgon metrikat në Pushgateway dhe përfundohet. Pas një kohe, Prometheus në ritmin e tij shkon dhe merr këto metrikat nga Pushgateway.
PĂ«r konfiguracionin e njoftimeve nĂ« Prometheus ka njĂ« komponent tĂ« veçantĂ« â Alertmanager. Dhe rregullat e alĂ«rtimit â rregullat e alerting. PĂ«r shembull, duhet tĂ« krijoni njĂ« alert nĂ« rast se API serverĂ«t janĂ« 0. Kur ngjarja ndodh, alerti dĂ«rgohet nĂ« menaxherin e alerteve pĂ«r dĂ«rgim tĂ« mĂ«tejshĂ«m. NĂ« alert manager ka gjithashtu konfigurime tĂ« mira pĂ«r rotimin: njĂ« grup alertrash mund tĂ« dĂ«rgohet nĂ« bisedĂ«n Telegram tĂ« adminĂ«ve, njĂ« tjetĂ«r nĂ« bisedĂ«n e zhvilluesve, njĂ« e tretĂ« nĂ« bisedĂ«n e infrastrukturĂ«s. Njoftimet mund tĂ« vijnĂ« nĂ« Slack, Telegram, me email dhe nĂ« kanale tĂ« tjera.
Dhe pĂ«rfundimisht, do tĂ« flas pĂ«r karakteristikĂ«n kryesore tĂ« Prometheus â Discovering. Kur punoni me Prometheus, nuk Ă«shtĂ« e nevojshme tĂ« tregoni adresat specifike tĂ« objekteve pĂ«r monitorim, Ă«shtĂ« e mjaftueshme tĂ« pĂ«rcaktoni tipin e tyre. KĂ«shtu, nuk Ă«shtĂ« e nevojshme tĂ« shkruani «ja IP-adresa, ja porti â monitoroni», pĂ«rkundrazi duhet tĂ« pĂ«rcaktoni se sipas cilave parime duhet tĂ« gjenden kĂ«to objekte (targetet â qĂ«llimet). Prometheus vetĂ«, nĂ« varĂ«si tĂ« objekteve qĂ« janĂ« aktualisht aktive, tĂ«rheq ato tĂ« nevojshme dhe i shton nĂ« monitorim.
Ky kyq i pĂ«rshtatet mirĂ« strukturĂ«s sĂ« Kubernetes, ku gjithçka gjithashtu lĂ«viz: sot 10 serverĂ«, nesĂ«r 3. NĂ« mĂ«nyrĂ« qĂ« tĂ« mos tregoni çdo herĂ« adresĂ«n IP tĂ« serverit, shkruani njĂ« herĂ« se si ta gjeni â dhe Discovering do ta bĂ«jĂ« kĂ«tĂ«.
Gjuha Prometheus quhet PromQL. Me këtë gjuhë mund të merrni vlera të metrikeve të caktuara dhe më pas t'i procesoni ato, duke ndërtuar analiza në bazë të tyre.
https://prometheus.io/docs/prometheus/latest/querying/basics/
Kërkesë e thjeshtë
container_memory_usage_bytes
Operacione matematikore
container_memory_usage_bytes / 1024 / 1024
Funksione të integruara
sum(container_memory_usage_bytes) / 1024 / 1024
Sqarimi i kërkesës
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Ndërfaqja e web-it të Prometheus
Prometheus ka një ndërfaqe web-i mjaft minimaliste. Ajo është mëse e përshtatshme për debug ose demonstruar.
Në rreshtin Expression mund të shkruani kërkesë në gjuhën PromQL.
NĂ« skedĂ«n Alerts ndodhen rregullat e alerteve â rregullat e alerteve, tĂ« cilat kanĂ« tre status:
- inactive â nĂ«se nĂ« momentin e tanishĂ«m alerta nuk Ă«shtĂ« aktiv, d.m.th. gjithçka Ă«shtĂ« nĂ« rregull dhe nuk ka ndodhur;
- pending â kjo ndodh nĂ« rast se alerta ka ndodhur, por dĂ«rgimi ende nuk Ă«shtĂ« kryer. Ka njĂ« vonesĂ«, e cila vendoset pĂ«r tĂ« kompensuar dridhjet e rrjetit: nĂ«se nĂ« njĂ« minutĂ« shĂ«rbimi i caktuar Ă«shtĂ« rikthyer, atĂ«herĂ« alarmi nuk duhet tĂ« aktivizohet pĂ«r momentin;
- firing â ky Ă«shtĂ« statusi i tretĂ«, kur alerta ndizet dhe dĂ«rgon njoftime.
Në menunë Status do të gjeni informacion mbi atë çfarë përfaqëson Prometheus. Aty ka gjithashtu kalime në qëllimet (targets), për të cilat folëm më sipër.
Për një shikim më të hollësishëm të ndërfaqes së Prometheus, shihni .
Integrimi me Grafana
Në ndërfaqen web të Prometheus nuk do të gjeni grafike të bukura dhe të kuptueshme, nga të cilat mund të nxirrni përfundime mbi gjendjen e klasterit. Për t'i ndërtuar ato, Prometheus integrohet me Grafana. Kështu krijohen këto tablo.
Të konfigurosh integrimin midis Prometheus dhe Grafana nuk është aspak e komplikuar, udhëzimet do t'i gjeni në dokumentacion: , dhe unë do ta përfundoj këtu.
Në artikujt e ardhshëm do të vazhdojmë temën e monitorimit: do të flasim për mbledhjen dhe analizën e logeve duke përdorur Grafana Loki dhe mjete alternative.
Autor: Marsel Ibraev, administrator i certifikuar Kubernetes, inxhinier praktik në kompaninë , folës dhe zhvillues kursesh të Slërm.
Burimi: habr.com
