ProHoster > Blogs > Administrācija > Kubernetes klastera uzraudzība: pārskats un ievads par Prometheus

Kubernetes klastera uzraudzība: pārskats un ievads par Prometheus

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 atklātā lekcija Slurm skolā. Ja vēlaties iegūt pilnu apmācību, pierakstieties kursiem par Monitoringa un mežizstrādes infrastruktūra Kubernetes.

Kubernetes klastera uzraudzība: pārskats un ievads par Prometheus

Kas tiek uzraudzīts Kubernetes klasterī

Kubernetes klastera uzraudzība: pārskats un ievads par Prometheus

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 Prometejs. 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.

  1. 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.
  2. 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

Kubernetes klastera uzraudzība: pārskats un ievads par Prometheus

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.

Kubernetes klastera uzraudzība: pārskats un ievads par Prometheus

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:

  1. neaktīvs - ja brīdinājums Ŕobrīd nav aktīvs, tas ir, ar to viss ir kārtībā un tas nedarbojās;
  2. 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;
  3. Å”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Å”.

Kubernetes klastera uzraudzība: pārskats un ievads par Prometheus

Detalizētāku pārskatu par Prometheus saskarni sk Slurma lekcijā par Kubernetes klastera uzraudzību.

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.

Kubernetes klastera uzraudzība: pārskats un ievads par Prometheus

Prometheus un Grafana integrācijas iestatÄ«Å”ana nepavisam nav grÅ«ta, instrukcijas var atrast dokumentācijā: GRAFANA ATBALSTS PROMETĒJAM, 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 Southbridge, skaļruņu un Slurm kursu izstrādātājs.

Avots: www.habr.com

Pievieno komentāru