Kontuan hartu Kubernetesen monitorizazioaren kontzeptua, ezagutu Prometheus tresna eta hitz egin alertari buruz.
Jarraipenaren gaia bolumena da, ezin da artikulu batean desmuntatu. Testu honen helburua tresnen, kontzeptuen eta planteamenduen ikuspegi orokorra eskaintzea da.
Artikuluaren materiala estutu bat da . Ikastaro osoa egin nahi baduzu, eman izena ikastaro batean .
Kubernetes kluster batean kontrolatzen dena
zerbitzari fisikoak. Kubernetes klusterra bere zerbitzarietan zabaltzen bada, haien osasuna kontrolatu behar duzu. Zabbix arduratzen da zeregin hori; berarekin lan egiten baduzu, orduan ez duzu uko egin beharrik, ez da gatazkarik izango. Zabbix da gure zerbitzarien egoera kontrolatzen duena.
Goazen jarraipenera kluster mailan.
Kontrol-planoaren osagaiak: API, Scheduler eta beste. Gutxienez, zerbitzarien edo etcd-en APIa 0 baino handiagoa dela ziurtatu behar duzu. Etcd-k metrika asko itzul ditzake: biraka egiten ari den diskoen arabera, bere etcd klusterren osasunaren arabera eta beste batzuk.
Docker aspaldi agertu zen eta denek ondo dakite bere arazoak: ontzi askok izozketak eta bestelako arazoak sortzen dituzte. Horregatik, Docker bera, sistema gisa, ere kontrolatu beharko litzateke, erabilgarritasunagatik behintzat.
DNSa. DNS klusterrean erortzen bada, aurkikuntza-zerbitzu osoa desagerraraziko da ondoren, podetatik podetara deiak funtzionatzeari utziko dio. Nire praktikan, ez zegoen horrelako arazorik, baina horrek ez du esan nahi DNSren egoera kontrolatu behar ez denik. Eskaeraren latentzia eta beste zenbait neurketa jarraitu daitezke CoreDNS-en.
Sarrera. Sarrerak (Ingress Controller barne) eskuragarritasuna kontrolatu behar da proiekturako sarrera puntu gisa.
Klusterraren osagai nagusiak desegin dira - orain abstrakzioen mailara jaitsi gaitezen.
Badirudi aplikazioak podetan exekutatzen direla, hau da, kontrolatu behar dira, baina errealitatean ez daude. Podak iragankorrak dira: gaur zerbitzari batean exekutatzen dira, bihar beste batean; gaur 10 dira, bihar 2. Horregatik, inork ez ditu lekak kontrolatzen. Mikrozerbitzuen arkitektura baten barruan, garrantzitsuagoa da aplikazioaren erabilgarritasuna bere osotasunean kontrolatzea. Bereziki, egiaztatu zerbitzuaren amaierako puntuen erabilgarritasuna: ezerk funtzionatzen du? Aplikazioa eskuragarri badago, zer gertatzen den haren atzean, zenbat erreplika dauden orain - bigarren ordenako galderak dira. Ez dago instantzia indibidualak kontrolatu beharrik.
Azken mailan, aplikazioaren beraren funtzionamendua kontrolatu behar duzu, negozio-neurriak hartu: eskaera kopurua, erabiltzailearen portaera, eta abar.
Prometeo
Kluster bat monitorizatzeko sistema onena da . Ez dut ezagutzen Prometheus-ek kalitate eta erraztasun aldetik pareka dezakeen tresnarik. Azpiegitura malguetarako bikaina da, beraz, "Kubernetesen jarraipena" esaten dutenean, normalean Prometheus esan nahi dute.
Prometheus-ekin hasteko aukera pare bat daude: Helm erabiliz, ohiko Prometheus edo Prometheus Operator bat instala dezakezu.
- Prometeo arrunta. Berarekin dena ondo dago, baina ConfigMap konfiguratu behar duzu; hain zuzen ere, idatzi testuan oinarritutako konfigurazio fitxategiak, lehen egin genuen bezala, mikrozerbitzuen arkitekturaren aurretik.
- Prometheus Operator apur bat zabalduago dago, apur bat konplikatuagoa barne-logikari dagokionez, baina errazagoa da horrekin lan egitea: objektu bereiziak daude, abstrakzioak gehitzen zaizkio clusterra, beraz, askoz erosoagoak dira kontrolatzeko eta konfiguratzeko.
Produktua ulertzeko, lehenik eta behin Prometheus arrunta instalatzea gomendatzen dut. Konfigurazioaren bidez dena konfiguratu beharko duzu, baina hau onuragarria izango da: zerri dagokion eta nola konfiguratuta dagoen jakingo duzu. Prometheus Operator-en, berehala igotzen zara goragoko abstrakzio batera, nahiz eta nahi izanez gero sakonean sakondu dezakezun.
Prometheus Kubernetes-ekin ondo integratuta dago: API zerbitzariarekin atzitu eta elkarreragin dezake.
Prometheus ezaguna da, horregatik aplikazio eta programazio lengoaia ugarik onartzen dute. Laguntza behar da, Prometheus-ek bere metrika formatua duelako, eta transferitzeko, aplikazioaren barruan liburutegi bat edo prest egindako esportatzaile bat behar duzu. Eta horrelako esportatzaile dezente daude. Adibidez, PostgreSQL Exporter dago: PostgreSQL-tik datuak hartzen ditu eta Prometheus formatura bihurtzen ditu, Prometheus-ek harekin lan egin dezan.
Prometeo arkitektura
Prometheus zerbitzaria atzeko muturra da, Prometeoren garuna. Metrikoak hemen gordetzen eta prozesatzen dira.
Neurketak denbora serieen datu-basean (TSDB) gordetzen dira. TSDB ez da datu-base bereizia, Prometheus-en txertatutako Go hizkuntzan dagoen pakete bat baizik. Gutxi gorabehera, dena bitar batean dago.
Ez gorde datuak TSDBn denbora luzez
Prometheus azpiegitura ez da epe luzerako metrikak biltegiratzeko egokia. Atxikipen-epe lehenetsia 15 egunekoa da. Muga hori gaindi dezakezu, baina kontuan izan: zenbat eta datu gehiago gorde TSDBn eta zenbat eta denbora gehiago egin, orduan eta baliabide gehiago kontsumituko ditu. Prometheus-en datu historikoak gordetzea praktika txartzat hartzen da.
Trafiko handia baduzu, neurketa kopurua ehunka mila segundoko da, orduan hobe da haien biltegiratzea diskoko espazioaren edo aldiaren arabera mugatzea. Normalean, "datu beroak" TSDBn gordetzen dira, metrikak ordu gutxitan. Biltegiratze luzeagorako, kanpoko biltegiratzea erabiltzen da horretarako benetan egokiak diren datu-base horietan, adibidez, InfluxDB, ClickHouse, etab. ClickHouseri buruzko iritzi on gehiago ikusi nituen.
Prometheus Server ereduan lan egiten du tira: metrikak bilatzen ditu guk eman dizkiogun puntu horietara. Esan zuten: "joan API zerbitzarira", eta hara joaten da n-garren segundoz behin eta neurketak hartzen ditu.
Scraping-aldien artean ager daitezkeen bizitza laburra (job edo cron lana) duten objektuentzat, Pushgateway osagai bat dago. Epe laburreko objektuen neurketak sartzen dira bertan: lana igo egin da, ekintza bat egin du, Pushgateway-ra neurketak bidali eta amaitu da. Pixka bat igaro ondoren, Prometheus bere erritmoan jaitsiko da eta Pushgateway-ko metrika hauek jasoko ditu.
Prometheus-en jakinarazpenak konfiguratzeko osagai bereizi bat dago - Alerta-kudeatzailea. Eta alerta arauak. Adibidez, alerta bat sortu behar duzu zerbitzariaren APIa 0 bada. Gertaera pizten denean, alerta alerta-kudeatzaileari pasatzen zaio gehiago bidal dezan. Alerta-kudeatzaileak bideratze-ezarpen nahiko malguak ditu: alerta talde bat administratzaileen telegram txatera bidal daiteke, beste bat garatzaileen txatera eta hirugarren bat azpiegiturako langileen txatera. Jakinarazpenak Slack, Telegram, posta elektronikora eta beste kanaletara bidal daitezke.
Eta azkenik, Prometheus killer funtzioaren berri emango dizut - ezagutzen. Prometheus-ekin lan egiten duzunean, ez duzu monitorizaziorako objektuen helbide zehatzik zehaztu behar, nahikoa da haien mota ezartzea. Hau da, ez duzu idatzi behar "hemen IP helbidea, hona portua - monitorea", aitzitik, objektu hauek aurkitzeko zer printzipioren arabera zehaztu behar duzu (helburuak - helburuak). Prometheus-ek berak, gaur egun aktibo dauden objektuen arabera, beharrezkoak direnak atera eta monitorizaziora gehitzen ditu.
Ikuspegi hori ondo datorkio Kubernetesen egiturari, non dena ere flotatzen baita: gaur 10 zerbitzari daude, bihar 3. Zerbitzariaren IP helbidea ez zehazteko aldi bakoitzean, behin idatzi zuten nola aurkitu - eta Discovering-ek egingo du. .
Prometeo hizkuntzari deitzen zaio PromQL. Hizkuntza hau erabiliz, metrika espezifikoen balioak lor ditzakezu eta gero bihur ditzakezu, haietan oinarrituta kalkulu analitikoak eraiki.
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 web interfazea
Prometheus-ek bere web interfaze nahiko minimalista du. Arazte edo erakustaldirako bakarrik egokia.
Adierazpen lerroan, PromQL hizkuntzan kontsulta bat idatz dezakezu.
Alertak fitxak alerta-arauak ditu eta hiru egoera dituzte:
- inaktibo - alerta une honetan aktibo ez badago, hau da, dena ondo dago eta ez du funtzionatu;
- zain - alertak funtzionatu badu, baina bidalketa oraindik ez da gainditu. Atzerapena sarearen keinua konpentsatzeko ezarri da: zehaztutako zerbitzua minutu batean igo bada, orduan alarmak ez du jo behar oraindik;
- Tiroa da hirugarren egoera alerta pizten denean eta mezuak bidaltzen dituenean.
Egoera menuan Prometheus zer denari buruzko informaziorako sarbidea aurkituko duzu. Helburuetara (helburuetara) trantsizio bat ere badago, goian aipatu duguna.
Prometheus interfazearen ikuspegi zehatzagoa lortzeko, ikus .
Grafanarekin integratzea
Prometheus web-interfazean, ez duzu grafiko eder eta ulergarririk aurkituko klusterraren egoerari buruzko ondorio bat ateratzeko. Horiek eraikitzeko, Prometheus Grafanarekin integratuta dago. Horrelako aginte-panelak lortzen ditugu.
Prometheus eta Grafana integrazioa konfiguratzea ez da batere zaila, dokumentazioan aurki ditzakezu argibideak: Tira, honekin amaituko dut.
Ondorengo artikuluetan jarraipenaren gaia jarraituko dugu: Grafana Loki eta tresna alternatiboak erabiliz erregistroak biltzeaz eta aztertzeaz hitz egingo dugu.
Egilea: Marcel Ibraev, Kuberneteseko administratzaile ziurtatua, enpresan praktikatzen duen ingeniaria , hizlari eta ikastaroen garatzailea Slurm.
Iturria: www.habr.com