Mieti Kubernetes-monitoroinnin konseptia, tutustu Prometheus-työkaluun ja puhu hälytyksestä.
Seurannan aihe on laaja, sitä ei voi purkaa yhdessä artikkelissa. Tämän tekstin tarkoituksena on antaa yleiskuva työkaluista, käsitteistä ja lähestymistavoista.
Artikkelin materiaali on puristettua . Jos haluat suorittaa koko kurssin - ilmoittaudu kurssille osoitteessa .
Mitä Kubernetes-klusterissa valvotaan
fyysiset palvelimet. Jos Kubernetes-klusteri on otettu käyttöön sen palvelimilla, sinun on seurattava niiden tilaa. Zabbix hoitaa tämän tehtävän; jos työskentelet hänen kanssaan, sinun ei tarvitse kieltäytyä, konflikteja ei synny. Se on Zabbix, joka valvoo palvelintemme tilaa.
Siirrytään klusteritason seurantaan.
Ohjaustason komponentit: API, Scheduler ja muut. Vähintään sinun on varmistettava, että palvelimien tai etcd:n API on suurempi kuin 0. Etcd voi palauttaa paljon mittareita: levyjen, joilla se pyörii, sen etcd-klusterin kunnon ja muiden perusteella.
Satamatyöläinen ilmestyi kauan sitten ja kaikki ovat hyvin tietoisia sen ongelmista: monet säiliöt aiheuttavat jäätymistä ja muita ongelmia. Siksi Dockeria itseään järjestelmänä tulisi myös ohjata, ainakin saatavuuden suhteen.
dns. Jos DNS epäonnistuu klusterissa, myös koko Discovery-palvelu epäonnistuu ja puhelut podista podiin lakkaavat toimimasta. Käytännössäni tällaisia ongelmia ei ollut, mutta tämä ei tarkoita, että DNS-tilaa ei tarvitsisi valvoa. Pyyntöviivettä ja joitain muita mittareita voidaan seurata CoreDNS:ssä.
Ingress. Sisääntulojen (mukaan lukien Ingress Controllerin) saatavuus projektin sisääntulopisteinä on tarpeen valvoa.
Klusterin pääkomponentit on purettu - nyt mennään abstraktioiden tasolle.
Vaikuttaa siltä, että sovellukset toimivat koteloissa, mikä tarkoittaa, että niitä on ohjattava, mutta todellisuudessa niitä ei ole. Podit ovat lyhytaikaisia: tänään ne toimivat yhdellä palvelimella, huomenna toisella; tänään niitä on 10, huomenna 2. Siksi kukaan ei valvo paloja. Mikropalveluarkkitehtuurissa on tärkeämpää hallita sovelluksen saatavuutta kokonaisuutena. Tarkista erityisesti palvelun päätepisteiden saatavuus: toimiiko mikään? Jos sovellus on saatavilla, mitä sen takana tapahtuu, kuinka monta kopiota on nyt - nämä ovat toisen asteen kysymyksiä. Yksittäisiä tapauksia ei tarvitse seurata.
Viimeisellä tasolla sinun on ohjattava itse sovelluksen toimintaa, otettava liiketoimintamittarit: tilausten määrä, käyttäjien käyttäytyminen ja niin edelleen.
Prometheus
Paras järjestelmä klusterin seurantaan on . En tiedä yhtään työkalua, joka voisi verrata Prometheusta laadultaan ja helppokäyttöisyydeltään. Se sopii erinomaisesti joustavaan infrastruktuuriin, joten kun he sanovat "Kubernetes-seuranta", he tarkoittavat yleensä Prometheusta.
Prometheuksen käytön aloittamiseen on pari vaihtoehtoa: Helmin avulla voit asentaa tavallisen Prometheuksen tai Prometheus Operatorin.
- Tavallinen Prometheus. Kaikki on hyvin hänen kanssaan, mutta sinun täytyy määrittää ConfigMap - itse asiassa kirjoittaa tekstipohjaisia määritystiedostoja, kuten teimme ennen mikropalveluarkkitehtuuria.
- Prometheus Operator on hieman hajautetumpi, hieman monimutkaisempi sisäisen logiikan suhteen, mutta sen kanssa on helpompi työskennellä: siellä on erilliset objektit, abstraktioita lisätään klusteriin, joten niitä on paljon helpompi hallita ja konfiguroida.
Tuotteen ymmärtämiseksi suosittelen tavallisen Prometheuksen asentamista ensin. Sinun on määritettävä kaikki konfiguroinnin kautta, mutta tästä on hyötyä: ymmärrät, mikä kuuluu mihin ja miten se on määritetty. Prometheus Operatorissa nouset heti korkeampaan abstraktioon, vaikka halutessasi voit myös sukeltaa syvyyksiin.
Prometheus on hyvin integroitu Kubernetesiin: se voi käyttää API-palvelinta ja olla vuorovaikutuksessa sen kanssa.
Prometheus on suosittu, minkä vuoksi monet sovellukset ja ohjelmointikielet tukevat sitä. Tukea tarvitaan, sillä Prometheuksella on oma metriikkaformaattinsa ja sen siirtämiseen tarvitset joko sovelluksen sisällä olevan kirjaston tai valmiin viejän. Ja tällaisia viejiä on melko vähän. Esimerkiksi on olemassa PostgreSQL Exporter: se ottaa tiedot PostgreSQL:stä ja muuntaa ne Prometheus-muotoon, jotta Prometheus voi työskennellä sen kanssa.
Prometheus-arkkitehtuuri
Prometheus-palvelin on takapää, Prometheuksen aivot. Mittarit tallennetaan ja käsitellään täällä.
Mittarit tallennetaan aikasarjatietokantaan (TSDB). TSDB ei ole erillinen tietokanta, vaan Go-kielinen paketti, joka on upotettu Prometheukseen. Karkeasti sanottuna kaikki on yhdessä binäärissä.
Älä säilytä tietoja TSDB:ssä pitkään
Prometheus-infrastruktuuri ei sovellu mittareiden pitkäaikaiseen tallentamiseen. Oletussäilytysaika on 15 päivää. Voit ylittää tämän rajan, mutta muista: mitä enemmän tietoja tallennat TSDB:hen ja mitä kauemmin teet sen, sitä enemmän resursseja se kuluttaa. Historiallisten tietojen tallentamista Prometheukseen pidetään huonona käytäntönä.
Jos liikennettä on valtava, mittareiden määrä on satoja tuhansia sekunnissa, on parempi rajoittaa niiden tallennustilaa levytilan tai ajanjakson mukaan. Yleensä "kuumat tiedot" tallennetaan TSDB:hen, mittarit vain muutamassa tunnissa. Pidempään säilytykseen käytetään ulkoista tallennustilaa niihin tietokantoihin, jotka todella sopivat tähän, esimerkiksi InfluxDB, ClickHouse ja niin edelleen. Näin enemmän hyviä arvosteluja ClickHousesta.
Prometheus Server toimii mallin mukaan vetää: hän etsii mittareita niille päätepisteille, jotka annoimme hänelle. He sanoivat: "Mene API-palvelimelle", ja hän menee sinne joka n. sekunti ja ottaa mittareita.
Objekteille, joilla on lyhyt käyttöikä (työ tai cron-työ), jotka voivat ilmestyä kaavintajaksojen välillä, on Pushgateway-komponentti. Siihen työnnetään mittareita lyhytaikaisista kohteista: työ on noussut, suorittanut toiminnon, lähettänyt mittarit Pushgatewaylle ja valmis. Hetken kuluttua Prometheus tulee alas omaan tahtiinsa ja poimii nämä tiedot Pushgatewaysta.
Ilmoitusten konfigurointiin Prometheuksessa on erillinen komponentti - Alertmanager. Ja varoitussäännöt. Sinun on esimerkiksi luotava hälytys, jos palvelimen API on 0. Kun tapahtuma käynnistyy, hälytys välitetään hälytysten hallintaohjelmalle jatkolähetystä varten. Hälytyspäälliköllä on melko joustavat reititysasetukset: yksi hälytysryhmä voidaan lähettää järjestelmänvalvojien telegram-chatiin, toinen kehittäjien chattiin ja kolmas infrastruktuurityöntekijöiden chatiin. Ilmoitukset voidaan lähettää Slackiin, Telegramiin, sähköpostiin ja muihin kanaviin.
Ja lopuksi kerron sinulle Prometheus-tappajaominaisuudesta - Tutustumismatka. Prometheuksen kanssa työskennellessäsi sinun ei tarvitse määrittää tarkkailtavien kohteiden osoitteita, riittää, kun määrität niiden tyypin. Eli ei tarvitse kirjoittaa "tässä on IP-osoite, tässä on portti - monitori", vaan sinun on määritettävä, millä periaatteilla nämä objektit löydetään (tavoitteet - tavoitteet). Prometheus itse, riippuen siitä, mitkä kohteet ovat tällä hetkellä aktiivisia, hakee tarvittavat ja lisää ne valvontaan.
Tämä lähestymistapa sopii hyvin Kubernetes-rakenteeseen, jossa kaikki myös kelluu: tänään palvelimia on 10, huomenna 3. Jotta palvelimen IP-osoitetta ei joka kerta määritettäisi, he kirjoittivat kerran, kuinka se löydetään - ja Discovering tekee sen .
Prometheuksen kieltä kutsutaan PromQL. Tällä kielellä voit saada tiettyjen mittareiden arvot ja sitten muuntaa ne ja rakentaa niiden perusteella analyyttisiä laskelmia.
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-verkkokäyttöliittymä
Prometheuksella on oma, melko minimalistinen verkkokäyttöliittymä. Sopii vain virheenkorjaukseen tai esittelyyn.
Lausekeriville voit kirjoittaa kyselyn PromQL-kielellä.
Hälytykset-välilehti sisältää hälytyssääntöjä, ja niillä on kolme tilaa:
- ei-aktiivinen - jos hälytys ei ole tällä hetkellä aktiivinen, eli kaikki on kunnossa, eikä se toiminut;
- vireillä - tämä on, jos hälytys toimi, mutta lähetys ei ole vielä mennyt ohi. Viive on asetettu kompensoimaan verkon vilkkumista: jos määritetty palvelu on noussut minuutin sisällä, hälytystä ei pitäisi vielä soida;
- laukaisu on kolmas tila, kun hälytys syttyy ja lähettää viestejä.
Tila-valikosta löydät pääsyn tietoihin siitä, mitä Prometheus on. On myös siirtyminen tavoitteisiin (tavoitteisiin), joista puhuimme edellä.
Yksityiskohtaisemman yleiskatsauksen Prometheus-käyttöliittymästä, katso .
Integrointi Grafanaan
Prometheus-verkkoliittymästä et löydä kauniita ja ymmärrettäviä kaavioita, joista voit tehdä johtopäätöksen klusterin tilasta. Niiden rakentamiseksi Prometheus on integroitu Grafanaan. Meillä on tällaisia kojetauluja.
Prometheuksen ja Grafanan integroinnin asettaminen ei ole ollenkaan vaikeaa, löydät ohjeet dokumentaatiosta: No, lopetan tähän.
Seuraavissa artikkeleissa jatkamme seuranta-aihetta: puhumme lokien keräämisestä ja analysoinnista Grafana Lokin ja vaihtoehtoisten työkalujen avulla.
Kirjoittaja: Marcel Ibraev, sertifioitu Kubernetes-järjestelmänvalvoja, työskentelevä insinööri yrityksessä , kaiuttimen ja kurssin kehittäjä Slurm.
Lähde: will.com