🥇Kubernetes'i klastri jälgimine: üldine ülevaade ja tutvustus Prometheusele

Vaatame üle Kubernetes'e jälgimise kontseptsiooni, tutvume vahendiga Prometheus ja räägime alerteerimisest.

Jälgimise teema on ulatuslik, ühe artikli raames ei saa seda täielikult käsitleda. Selle teksti eesmärk on anda ülevaade tööriistadest, kontseptsioonidest ja lähenemistest.

Artikli materjal on väljavõte avatoru loengust „Slyrm“. Kui soovite minna läbi täiendava koolituse, registreeruge kursusele Kubernetes'e infrastruktuuri jälgimise ja logimise kohta.

Mida jälgitakse Kubernetes'e klastris

Füüsilised serverid. Kui Kubernetes'i klaster on püstitatud oma serveritele, tuleb jälgida nende tervist. Selle ülesande täidab Zabbix; kui te töötate selle tööriistaga, ei pea te loobuma, konflikte ei teki. Meie serverite seisundit jälgib just Zabbix.

Liigume edasi klastritasandi jälgimise juurde.

Control Plane komponendid: API, Scheduler ja teised. Vähemalt tuleb jälgida, et API serverite või etcd arv oleks suurem kui 0. Etcd suudab anda palju mõõdikuid: kettad, millel see töötab, oma klastrite etcd tervis ja teised.

Docker on ilmus ammu ja kõik teavad tema probleemidest: palju konteinerite tekitab riputusi ja muid probleeme. Seetõttu tuleb ka Dockerit kui süsteemi jälgida, vähemalt selle kättesaadavust.

DNS. Kui klastris DNS töölt kukub, siis kukub välja ka kogu Discovery teenus, podide vahelised päringud lakkavad töötamast. Minu praktikas sarnaseid probleeme ei ole olnud, kuid see ei tähenda, et DNS-i seisukorras ei peaks jälgima. Kutsu arvestust päringute viivituste ja teiste metrikate üle CoreDNS-is.

Ingress. Peame jälgima sissepääsud (kaasa arvatud Ingress Controller) kättesaadavust, kuna need on projekti sissepääsud.

Peamised klastri komponendid on üle vaadatud — nüüd liigume madalamale, abstraktsioonide tasemele.

Tundub, et rakendused käivitatakse podides, seega peaks neid jälgima, kuid tegelikult ei ole see vajalik. Podid on efemeersed: täna töötavad nad ühel serveril, homme teisel; täna on neid 10, homme 2. Seega pole kellegi jaoks pelgalt podide jälgimine oluline. Mikroteenuste arhitektuuri raames on olulisem jälgida rakenduse üldist kättesaadavust. Eriliste tähelepanu all on teenuse lõpp-punktide kättesaadavus: kas midagi üldse töötab? Kui rakendus on kättesaadav, siis mis toimub selle taga, kui palju replikate on — need on teisejärgulised küsimused. Üksikute instantside jälgimine pole vajalik.

Viimasel tasemel tuleb jälgida rakenduse enda toimimist, koguda ärimeetmeid: tellimuste arv, kasutajate käitumine jne.

Prometheus

Parim süsteem klastri jälgimiseks on Prometheus. Ma ei tunne ühtegi tööriista, mis suudaks Prometheusega kvaliteedi ja kasutusmugavuse poolest võrreldav olla. See sobib suurepäraselt paindlikule infrastruktuurile, seega kui räägitakse "Kubernetes'e jälgimisest", mõeldakse tavaliselt just Prometheusele.

On paar varianti, kuidas Prometheusega alustada: Helm'i abil saab installida tavalise Prometheuse või Prometheus Operatori.

Taval Prometheus. Sellega on kõik hästi, kuid ConfigMap'i seadistamine on vajalik — põhimõtteliselt peate kirjutama tekstilisi konfiguratsioonifailesid, nagu me varem tegime enne mikroteenuste arhitektuuri.
Prometheus Operator on natuke keerukam, natuke keerukama siseloomuga, kuid selle kasutamine on lihtsam: seal on eraldi objektid, abstraktsioonid lisanduvad klastrisse, seega on neid palju mugavam hallata ja seadistada.

Kuna soovite tootega tutvuda, soovitan kõigepealt installida tavalise Prometheuse. Peate kõik seadistama konfi kaudu, kuid see on kasulik: saate aru, mis millele vastab ja kuidas seadistada. Prometheus Operator investeerib teid kohe kõrgemale abstraktsioonitasemele, kuigi soovi korral saate süveneda ka sügavale.

Prometheus on hästi integreeritud Kubernetesega: see võib pöörduda API serveri poole ja suhelda sellega.

Prometheus on populaarne, seetõttu toetab seda suur hulk rakendusi ja programmeerimiskeeli. Tugi on vajalik, kuna Prometheusel on oma metrikate formaat ning selle edastamiseks on vajalik kas teek rakenduses või valmis eksportija. Ja selliseid eksportijaid on üsna palju. Näiteks on olemas PostgreSQL Exporter: see võtab andmed PostgreSQL-st ja konverteerib need Prometheuse formaati, et Prometheus saaks nendega töötada.

Prometheuse arhitektuur

Prometheus Server — see on Prometheuse serveripool, aju Prometheuses. Siin hoitakse ja töödeldakse metrikaid.

Metrikaid hoiab ajaserverite andmebaas (TSDB). TSDB ei ole eraldi andmebaas, vaid Go keeles loodud pakett, mis on sisse ehitatud Prometheusesse. Ükskõik, kõik on ühes binäärfailis.

Ärge hoidke andmeid TSDB-s kaua
Prometheuse infrastruktuur ei sobi metrikate pikaajaliseks hoidmiseks. Vaikimisi on säilitamise aeg 15 päeva. Seda piirangut on võimalik ületada, kuid tuleks arvesse võtta: mida rohkem andmeid te taastate TSDB-s ja mida pikemalt te seda teete, seda rohkem ressursse see kasutab. Ajalooliste andmete hoidmine Prometheuses loetakse halva praktikana.
Kui teie liiklus on suur, ja mõõdikute arv ulatub sadade tuhandete sekundis, on parem piirata nende salvestamist kas kettaruumi või ajakava järgi. Üldiselt salvestatakse TSDB-s „kuumi andmeid”, mõõdikuid vaid mõne tunni jooksul. Pikemaajaliseks säilitamiseks kasutatakse väliseid ladustamisi neis andmebaasides, mis on selleks tõeliselt sobivad, näiteks InfluxDB, ClickHouse ja nii edasi. Rohkem heade arvustustega olen näinud ClickHouse'i kohta.

Prometheus Server töötab mudeli järgi pull: see käib ise mõõdikute järele nendes lõpp-punktides, mille oleme talle edastanud. Ütlesime: „mine API Serverisse”, ja ta läheb igal n-ndal sekundil sinna ning toob mõõdikud.

Lühiajaliste elutsüklitega objektide (nt töö või cron job), mis võivad ilmuda kraapimise perioodide vahele, jaoks on olemas komponent Pushgateway. Sellesse saadetakse mõõdikud lühiajalistest objektidest: töö käivitus, sooritas toimingu, saatis mõõdikud Pushgateway'sse ja lõpetas. Teatud aja pärast korjab Prometheus oma rütmis need mõõdikud Pushgateway'st.

Prometheuses teavituste seadistamiseks on olemas eraldi komponent — Alertmanager. Ja häirete reeglid — alerting rules. Näiteks, tuleks luua alert, kui API serverid on 0. Kui sündmus aktiveerub, edastatakse alert häirete haldurile edasist saatmist jaoks. Häirete halduril on piisavalt paindlikud marsruutimise seaded: ühte gruppi häireid saab saata adminside Telegrami vestlusesse, teise arendajate vestlusesse, kolmanda infrastruktuuri spetsialistide vestlusesse. Teateid võib saada Slackis, Telegramis, e-kirjade teel ja teistes kanalites.

Ja viimaseks räägin Prometheuse tapja-funktsioonist — Avastamine. Prometheusega töötades ei pea te määrama konkreetseid objektide aadresse jälgimiseks, piisab nende tüübi määramisest. See tähendab, et pole vaja kirjutada „siin on IP-aadress, siin on port — jälgi”, selle asemel tuleb määrata, milliste põhimõtete alusel neid objekte leida (targets — sihid). Prometheus ise, sõltuvalt sellest, millised objektid on aktiivsed, tõmbab vajalikud objectid ja lisab need jälgimisele.

Selline lähenemine sobib hästi Kubernetes'i struktuuri, kus kõik on kaasküjne: täna 10 serverit, homme 3. Et iga kord IP-aadressi mitterämemata, on kord kirjutatud, kuidas seda leida — ja Avastamine tegeleb sellega.

Prometheuse keel nimetatakse PromQL. Selle keele abil on võimalik hankida konkreetsete mõõdikute väärtusi ja seejärel neid töödelda, et koostada analüütilisi järeldusi.

https://prometheus.io/docs/prometheus/latest/querying/basics/

Lihtne päring

    container_memory_usage_bytes

Matemaatilised toimingud

    container_memory_usage_bytes / 1024 / 1024

Sisseehitatud funktsioonid

    sum(container_memory_usage_bytes) / 1024 / 1024

Päringu täpsustamine

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

Prometheuse veebiliides

Prometheusel on oma, üsna minimalistlik veebiliides. Sobib peamiselt silumiseks või demonstreerimiseks.

Väljendi real saab kirjutada päringud PromQL keeles.

Alerdite vahekaardil on hoiatusreeglid — alerting rules, ja nendel on kolm staatust:

inactive — kui hetkel on alert mitteaktiivne, see tähendab, et kõik on korras ja see ei aktiveerunud;
pending — see kehtib juhul, kui alert aktiveerus, kuid teavitus pole veel läinud. Viivitus seadistatakse, et kompenseerida võrgu vilkumist: kui antud teenus on minutiga tööle hakanud, siis alarmi anda ei ole vaja;
firing — see on kolmas staatus, kui alert süttib ja saadab teateid.

Menü Status sisaldab teavet selle kohta, mis on Prometheus. Seal on ka link sihtkohtadele (targets), millest me eelnevalt rääkisime.

Täpsema ülevaate Prometheuse liidesest leiate Slërmi loengust Kubernetes klastrite jälgimise kohta..

Integreerimine Grafanaga.

Prometheuse veebi liideses ei leia te kauneid ja arusaadavaid graafikuid, mille abil saaksite hinnata klastrite seisukorda. Nende koostamiseks integreeritakse Prometheus Grafanaga, mille tulemuseks saavad sellised juhtpaneelid.