Mõelge Kubernetese seire kontseptsioonile, tutvuge Prometheuse tööriistaga ja rääkige hoiatamisest.
Seireteema on mahukas, seda ei saa ühes artiklis lahti võtta. Selle teksti eesmärk on anda ülevaade vahenditest, kontseptsioonidest ja lähenemisviisidest.
Artikli materjal on pigistatud . Kui soovite läbida täiskursuse - registreeruge kursusele aadressil .
Mida Kubernetese klastris jälgitakse
füüsilised serverid. Kui Kubernetese klaster on selle serverites juurutatud, peate jälgima nende tervist. Zabbix tegeleb selle ülesandega; kui töötate temaga, siis ei pea te keelduma, konflikte ei teki. Just Zabbix jälgib meie serverite olekut.
Liigume edasi seirega klastri tasemel.
Juhttasandi komponendid: API, Scheduler ja teised. Vähemalt peate veenduma, et serverite või etcd API on suurem kui 0. Etcd võib tagastada palju mõõdikuid: ketaste, millel see pöörleb, etcd klastri seisukorra ja muu järgi.
laevalaadija ilmus juba ammu ja kõik on selle probleemidest hästi teadlikud: paljud konteinerid tekitavad külmumist ja muid probleeme. Seetõttu tuleks ka Dockerit ennast kui süsteemi kontrollida, vähemalt saadavuse osas.
dns. Kui DNS klastris ära kukub, kukub pärast seda välja kogu Discovery teenus, kõned kabudest kabudesse lakkavad töötamast. Minu praktikas selliseid probleeme ei esinenud, kuid see ei tähenda, et DNS-i olekut ei oleks vaja jälgida. Päringu latentsust ja mõnda muud mõõdikut saab jälgida CoreDNS-is.
Ingress. Projekti sisenemispunktidena on vaja kontrollida sissepääsude (sh Ingress Controller) saadavust.
Klastri põhikomponendid on lahti võetud – nüüd laskume abstraktsioonide tasemele.
Näib, et rakendused töötavad kaustades, mis tähendab, et neid tuleb kontrollida, kuid tegelikult see nii ei ole. Kaunad on lühiajalised: täna töötavad need ühes serveris, homme teises; täna on neid 10, homme 2. Seetõttu ei jälgi kaunasid keegi. Mikroteenuste arhitektuuris on olulisem kontrollida rakenduse kui terviku kättesaadavust. Kontrollige eelkõige teenuse lõpp-punktide saadavust: kas miski töötab? Kui rakendus on saadaval, siis mis selle taga toimub, kui palju koopiaid praegu on - need on teist järku küsimused. Üksikuid juhtumeid pole vaja jälgida.
Viimasel tasemel peate kontrollima rakenduse enda tööd, võtma ärimõõdikuid: tellimuste arvu, kasutaja käitumist jne.
Prometheus
Parim süsteem klastri jälgimiseks on . Ma ei tea ühtegi tööriista, mis võiks kvaliteedi ja kasutusmugavuse poolest Prometheusega võrrelda. See sobib suurepäraselt paindliku infrastruktuuri jaoks, nii et kui öeldakse "Kubernetese seire", tähendab see tavaliselt Prometheust.
Prometheusega alustamiseks on paar võimalust: Helmi abil saate installida tavalise Prometheuse või Prometheuse operaatori.
- Tavaline Prometheus. Temaga on kõik korras, kuid peate ConfigMapi konfigureerima - tegelikult kirjutage tekstipõhised konfiguratsioonifailid, nagu me tegime enne mikroteenuse arhitektuuri.
- Prometheus Operator on veidi laialivalguvam, sisemise loogika poolest veidi keerulisem, kuid sellega on lihtsam töötada: seal on eraldi objektid, klastrisse lisatakse abstraktsioone, nii et neid on palju mugavam juhtida ja seadistada.
Tootest arusaamiseks soovitan esmalt paigaldada tavaline Prometheus. Peate kõik konfiguratsiooni kaudu konfigureerima, kuid see tuleb kasuks: saate aru, mis millesse kuulub ja kuidas see on konfigureeritud. Prometheus Operatoris tõused kohe abstraktsiooni kõrgemale, kuigi võid soovi korral ka sügavustesse süveneda.
Prometheus on Kubernetesega hästi integreeritud: see pääseb API serverile juurde ja saab sellega suhelda.
Prometheus on populaarne, mistõttu toetab seda suur hulk rakendusi ja programmeerimiskeeli. Vaja on tuge, kuna Prometheusel on oma mõõdikute vorming ja selle ülekandmiseks on vaja kas rakenduse sees olevat teeki või valmis eksportijat. Ja selliseid eksportijaid on päris palju. Näiteks on PostgreSQL Exporter: see võtab andmed PostgreSQL-ist ja teisendab need Prometheuse vormingusse, et Prometheus saaks sellega töötada.
Prometheuse arhitektuur
Prometheuse server on tagaots, Prometheuse aju. Siin salvestatakse ja töödeldakse mõõdikuid.
Mõõdikud salvestatakse aegridade andmebaasis (TSDB). TSDB ei ole eraldi andmebaas, vaid Go-keeles pakett, mis on Prometheusesse manustatud. Jämedalt öeldes on kõik ühes binaaris.
Ärge salvestage andmeid TSDB-s pikka aega
Prometheuse infrastruktuur ei sobi mõõdikute pikaajaliseks säilitamiseks. Vaikimisi on säilitusperiood 15 päeva. Saate seda limiiti ületada, kuid pidage meeles: mida rohkem andmeid TSDB-s salvestate ja mida kauem seda teete, seda rohkem ressursse see kulutab. Ajalooliste andmete säilitamist Prometheuses peetakse halvaks tavaks.
Kui teil on tohutu liiklus, mõõdikute arv on sadu tuhandeid sekundis, siis on parem piirata nende salvestusruumi kettaruumi või perioodide kaupa. Tavaliselt salvestatakse "kuumad andmed" TSDB-sse, mõõdikud vaid mõne tunniga. Pikemaks säilitamiseks kasutatakse välist salvestusruumi nendes andmebaasides, mis selleks tõesti sobivad, näiteks InfluxDB, ClickHouse jne. Nägin ClickHouse'i kohta rohkem häid arvustusi.
Mudelil töötab Prometheus Server vedama: ta otsib mõõdikuid nende lõpp-punktide kohta, mille me talle andsime. Nad ütlesid: "Minge API serverisse" ja ta läheb sinna iga n-nda sekundi järel ja võtab mõõdikuid.
Lühikese elueaga objektide jaoks (töö või cron töö), mis võivad ilmuda kraapimisperioodide vahel, on Pushgateway komponent. Sellesse lükatakse lühiajaliste objektide mõõdikud: töö on tõusnud, toimingu sooritanud, mõõdikud Pushgatewaysse saadetud ja lõpetatud. Mõne aja pärast tuleb Prometheus omas tempos alla ja võtab need mõõdikud Pushgatewayst.
Prometheuse teavituste konfigureerimiseks on eraldi komponent - Alertmanager. Ja hoiatusreeglid. Näiteks peate looma hoiatuse, kui serveri API on 0. Kui sündmus käivitub, edastatakse hoiatus edasiseks saatmiseks hoiatuste haldurile. Häirehalduril on üsna paindlikud marsruutimise sätted: ühe grupi hoiatusi saab saata administraatorite telegrammivestlusesse, teise arendajate vestlusse ja kolmanda taristutöötajate vestlusesse. Teateid saab saata Slackile, Telegramile, e-postile ja teistele kanalitele.
Ja lõpuks räägin teile Prometheuse tapja funktsioonist - Avastamine. Prometheusega töötades ei pea te jälgimiseks määrama objektide konkreetseid aadresse, piisab nende tüübi määramisest. See tähendab, et te ei pea kirjutama "siin on IP-aadress, siin on port - monitor", selle asemel peate määrama, milliste põhimõtete järgi need objektid leida (eesmärgid - eesmärgid). Prometheus ise, olenevalt sellest, millised objektid parasjagu aktiivsed on, tõmbab vajalikud üles ja lisab need jälgimisse.
Selline lähenemine sobib hästi Kubernetese struktuuriga, kus kõik ka hõljub: täna on serveriid 10, homme 3. Et mitte iga kord serveri IP-aadressi täpsustada, kirjutasid nad korra, kuidas seda leida – ja Discovering teeb seda .
Prometheuse keelt nimetatakse PromQL. Seda keelt kasutades saate hankida konkreetsete mõõdikute väärtused ja need seejärel teisendada ning nende põhjal analüütilisi arvutusi koostada.
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)Prometheuse veebiliides
Prometheusel on oma, üsna minimalistlik veebiliides. Sobib ainult silumiseks või tutvustamiseks.
Avaldise reale saate kirjutada päringu PromQL keeles.
Vahekaart Hoiatused sisaldab hoiatusreegleid ja neil on kolm olekut.
- passiivne - kui hoiatus ei ole hetkel aktiivne, see tähendab, et sellega on kõik korras ja see ei töötanud;
- ootel – see on siis, kui hoiatus töötas, kuid saatmine pole veel möödunud. Viivitus on seatud võrgu vilkumise kompenseerimiseks: kui määratud teenus on minuti jooksul tõusnud, ei tohiks häiret veel kõlada;
- süütamine on kolmas olek, kui märguanne süttib ja sõnumeid saadab.
Menüüst Olek leiate juurdepääsu teabele selle kohta, mis on Prometheus. Toimub ka üleminek sihtmärkidele (sihtmärkidele), millest eespool rääkisime.
Prometheuse liidese üksikasjalikuma ülevaate saamiseks vt .
Integratsioon Grafanaga
Prometheuse veebiliidesest ei leia ilusaid ja arusaadavaid graafikuid, millest saaks teha järelduse klastri oleku kohta. Nende ehitamiseks on Prometheus integreeritud Grafanaga. Meil on sellised armatuurlauad.
Prometheuse ja Grafana integratsiooni seadistamine pole sugugi keeruline, juhised leiate dokumentatsioonist: Noh, ma lõpetan sellega.
Järgmistes artiklites jätkame jälgimise teemat: räägime logide kogumisest ja analüüsimisest Grafana Loki ja alternatiivsete tööriistade abil.
Autor: Marcel Ibraev, Kubernetese sertifitseeritud administraator, ettevõttes praktiseeriv insener , kõneleja ja kursuse arendaja Slurm.
Allikas: www.habr.com