Apskatīsim Kubernetes monitoringa koncepciju, iepazīsimies ar Prometheus rīku un runāsim par brīdināšanu.
Monitoringa tēma ir apjomīga, to nevar aptvert vienā rakstā. Šī teksta mērķis ir sniegt pārskatu par instrumentiem, koncepcijām un pieejām.
Raksta materiāls - izraksts no . Ja vēlaties iegūt pilnu apmācību, pierakstieties kursiem par .
Kas tiek uzraudzīts Kubernetes klasterī
Fiziskie serveri. Ja Kubernetes klasteris ir izvietots savos serveros, jums ir jāuzrauga to stāvoklis. Zabbix tiek galā ar šo uzdevumu; ja strādā ar viņu, tad nevajag atteikt, nebūs konfliktu. Tas ir Zabbix, kas uzrauga mūsu serveru stāvokli.
Pāriesim uz uzraudzību klastera līmenī.
Vadības plaknes sastāvdaļas: API, plānotājs un citi. Vismaz ir jāuzrauga, vai servera API vai etcd ir lielāks par 0. Etcd var nodrošināt daudzus rādītājus: par diskiem, kuros tas griežas, par tā etcd klastera stāvokli un citiem.
dokers parādījās jau sen, un visi labi apzinās tās problēmas: daudzi konteineri izraisa sasalšanu un citas problēmas. Tāpēc arī pati Docker kā sistēma būtu jāuzrauga, vismaz pieejamība.
dns. Ja DNS neizdodas klasterī, neizdosies arī viss Discovery pakalpojums, un zvani no podiem pārstās darboties. Manā praksē šādu problēmu nebija, taču tas nenozīmē, ka DNS statuss nav jāuzrauga. Pieprasījuma latentumu un dažus citus rādītājus var izsekot CoreDNS.
Iekļūšana. Nepieciešams kontrolēt ieeju (tostarp Ingress Controller) kā ieejas punktu pieejamību projektā.
Klastera galvenās sastāvdaļas ir izjauktas - tagad ejam zemāk, līdz abstrakciju līmenim.
Šķiet, ka lietojumprogrammas darbojas podiņos, kas nozīmē, ka tās ir jākontrolē, taču patiesībā tās nav. Pāksti ir īslaicīgi: šodien tie darbojas vienā serverī, rīt citā; Šodien tās ir 10, rīt 2. Tāpēc neviens pākstis neuzrauga. Mikropakalpojumu arhitektūrā svarīgāk ir kontrolēt visas lietojumprogrammas pieejamību. Jo īpaši pārbaudiet pakalpojuma galapunktu pieejamību: vai kaut kas darbojas? Ja aplikācija ir pieejama, tad kas aiz tās notiek, cik tagad ir repliku – tie ir otrās kārtas jautājumi. Nav nepieciešams uzraudzīt atsevišķus gadījumus.
Pēdējā līmenī jums ir jāuzrauga pašas lietojumprogrammas darbība, jāņem vērā biznesa rādītāji: pasūtījumu skaits, lietotāju uzvedība utt.
Prometejs
Vislabākā klastera uzraudzības sistēma ir . Es nezinu nevienu rīku, ko varētu salīdzināt ar Prometheus kvalitātes un lietošanas ērtuma ziņā. Tas ir lieliski piemērots elastīgai infrastruktūrai, tāpēc, kad cilvēki saka "Kubernetes monitorings", viņi parasti domā Prometheus.
Ir dažas iespējas, kā sākt darbu ar Prometheus: izmantojot Helm, varat instalēt parasto Prometheus vai Prometheus Operator.
- Regulārs Prometejs. Ar to viss ir kārtībā, bet jums ir jākonfigurē ConfigMap - būtībā jāraksta teksta konfigurācijas faili, kā mēs to darījām iepriekš, pirms mikropakalpojumu arhitektūras.
- Prometheus Operator ir nedaudz plašāks, nedaudz sarežģītāks savā iekšējā loģikā, taču ar to ir vieglāk strādāt: ir atsevišķi objekti, klasterim tiek pievienotas abstrakcijas, tāpēc tās ir daudz ērtāk kontrolēt un konfigurēt.
Lai saprastu produktu, iesaku vispirms instalēt parasto Prometheus. Jums viss būs jākonfigurē caur konfigurāciju, taču tas būs izdevīgi: jūs sapratīsit, kas kam pieder un kā tas ir konfigurēts. Prometheus Operatorā jūs uzreiz paceļaties uz augstāku abstrakciju, lai gan, ja vēlaties, varat iedziļināties arī dziļumos.
Prometheus ir labi integrēts ar Kubernetes: tas var piekļūt un mijiedarboties ar API serveri.
Prometheus ir populārs, un to atbalsta liels skaits lietojumprogrammu un programmēšanas valodu. Atbalsts ir nepieciešams, jo Prometheus ir savs metrikas formāts, un, lai to pārsūtītu, ir nepieciešama vai nu lietojumprogrammas bibliotēka, vai gatavs eksportētājs. Un tādu eksportētāju ir diezgan daudz. Piemēram, ir PostgreSQL Exporter: tas ņem datus no PostgreSQL un pārvērš tos Prometheus formātā, lai Prometheus varētu ar to strādāt.
Prometeja arhitektūra
Prometheus serveris — šī ir servera daļa, Prometeja smadzenes. Šeit tiek glabāti un apstrādāti rādītāji.
Metrikas tiek glabātas laikrindu datu bāzē (TSDB). TSDB nav atsevišķa datu bāze, bet gan Go pakotne, kas ir iebūvēta Prometheus. Aptuveni runājot, viss ir vienā binārā.
Neglabājiet datus TSDB ilgi
Prometheus infrastruktūra nav piemērota metriku ilgstošai glabāšanai. Noklusējuma glabāšanas periods ir 15 dienas. Varat pārsniegt šo ierobežojumu, taču paturiet prātā: jo vairāk datu glabājat TSDB un jo ilgāk to darāt, jo vairāk resursu tas patērēs. Vēsturisko datu glabāšana programmā Prometheus tiek uzskatīta par sliktu praksi.
Ja jums ir milzīga trafika, metrikas skaits ir simtiem tūkstošu sekundē, tad labāk ir ierobežot to uzglabāšanu pēc diska vietas vai perioda. Parasti TSDB burtiski dažas stundas saglabā “karsto datus”, metriku. Ilgākai uzglabāšanai tiek izmantota ārējā krātuve tajās datu bāzēs, kuras tam tiešām ir piemērotas, piemēram, InfluxDB, ClickHouse u.c. Es redzēju vairāk labu atsauksmju par ClickHouse.
Prometheus Server darbojas saskaņā ar modeli vilkt: viņš pats meklē metriku galapunktos, ko mēs viņam iedevām. Viņi teica: “dodieties uz API serveri”, un tas dodas tur katru n-to sekunžu skaitu un ņem metriku.
Objektiem ar īsu kalpošanas laiku (darbs vai cron darbs), kas var parādīties starp skrāpēšanas periodiem, ir Pushgateway komponents. Tajā tiek ievietota īstermiņa objektu metrika: darbs tika palielināts, darbība tika pabeigta, metrika tika nosūtīta uz Pushgateway un pabeigta. Pēc kāda laika Prometheus darbosies savā tempā un pārņems šos rādītājus no Pushgateway.
Paziņojumu konfigurēšanai programmā Prometheus ir atsevišķs komponents - Brīdinājumu pārvaldnieks. Un brīdināšanas noteikumi. Piemēram, jums ir jāizveido brīdinājums, ja servera API ir 0. Kad notikums tiek aktivizēts, brīdinājums tiek nodots brīdinājumu pārvaldniekam tālākai sūtīšanai. Brīdinājumu pārvaldniekam ir diezgan elastīgi maršrutēšanas iestatījumi: vienu brīdinājumu grupu var nosūtīt administratoru telegrammas tērzēšanai, otru izstrādātāju tērzēšanai un trešo infrastruktūras darbinieku tērzēšanai. Paziņojumus var nosūtīt uz Slack, Telegram, e-pastu un citiem kanāliem.
Un visbeidzot es jums pastāstīšu par Prometeja slepkavas iezīmi - atklājot. Strādājot ar Prometheus, nav jānorāda konkrētas uzraugāmo objektu adreses, pietiek norādīt to veidu. Tas ir, nav nepieciešams rakstīt “šeit ir IP adrese, šeit ir ports - monitors”, tā vietā jums ir jānosaka, pēc kādiem principiem atrast šos objektus (mērķi - vārti). Pats Prometejs atkarībā no tā, kuri objekti šobrīd ir aktīvi, izvelk nepieciešamos un pievieno monitoringam.
Šī pieeja labi saskan ar Kubernetes struktūru, kur arī viss peld: šodien ir 10 serveri, rīt 3. Lai katru reizi nenorādītu servera IP adresi, reiz rakstījām, kā to atrast - un Discovering to izdarīs.
Prometeja valodu sauc PromQL. Izmantojot šo valodu, varat iegūt konkrētu metrikas vērtības un pēc tam tās pārveidot un, pamatojoties uz tām, veidot analītiskos aprēķinus.
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 tīmekļa saskarne
Prometheus ir savs, diezgan minimālistisks tīmekļa interfeiss. Piemērots tikai atkļūdošanai vai demonstrēšanai.
PromQL vaicājumu var uzrakstīt izteiksmes rindā.
Cilnē Brīdinājumi ir brīdinājumu kārtulas, un tām ir trīs statusi:
- neaktīvs - ja brīdinājums šobrīd nav aktīvs, tas ir, ar to viss ir kārtībā un tas nedarbojās;
- gaida — tas ir, ja brīdinājums tika aktivizēts, bet nosūtīšana vēl nav notikusi. Aizkave ir iestatīta, lai kompensētu tīkla mirgošanu: ja norādītais pakalpojums minūtes laikā ir pieaudzis, tad vēl nav jāzvana;
- šaušana ir trešais statuss, kad iedegas brīdinājums un tiek nosūtīti ziņojumi.
Statusa izvēlnē jūs atradīsit piekļuvi informācijai par to, kas ir Prometheus. Ir arī pāreja uz mērķiem, par kuriem mēs runājām iepriekš.
Detalizētāku pārskatu par Prometheus saskarni sk .
Integrācija ar Grafana
Prometheus tīmekļa saskarnē jūs neatradīsit skaistus un saprotamus grafikus, no kuriem jūs varētu izdarīt secinājumus par klastera stāvokli. Lai tos izveidotu, Prometheus integrējas ar Grafana. Šie ir informācijas paneļi, ko mēs iegūstam.
Prometheus un Grafana integrācijas iestatīšana nepavisam nav grūta, instrukcijas var atrast dokumentācijā: , labi, es pabeigšu ar šo.
Nākamajos rakstos turpināsim monitoringa tēmu: runāsim par žurnālu apkopošanu un analīzi, izmantojot Grafana Loki un alternatīvos rīkus.
Autors: Marsels Ibrajevs, sertificēts Kubernetes administrators, uzņēmumā praktizējošais inženieris , skaļruņu un Slurm kursu izstrādātājs.
Avots: www.habr.com
