Kom ons kyk na die konsep van Kubernetes-monitering, maak kennis met die Prometheus-instrument en praat oor waarskuwing.
Die onderwerp van monitering is omvangryk; dit kan nie in een artikel gedek word nie. Die doel van hierdie teks is om 'n oorsig te gee van die gereedskap, konsepte en benaderings.
Die materiaal van die artikel is 'n druk uit . As jy volle opleiding wil kry, teken aan vir 'n kursus oor .
Wat word in 'n Kubernetes-kluster gemonitor
Fisiese bedieners. As 'n Kubernetes-kluster op sy eie bedieners ontplooi word, moet u hul gesondheid monitor. Zabbix behartig hierdie taak; as jy saam met hom werk, hoef jy nie te weier nie, daar sal geen konflikte wees nie. Dit is Zabbix wat die toestand van ons bedieners monitor.
Kom ons gaan oor na monitering op groepsvlak.
Beheervliegtuigkomponente: API, skeduleerder en ander. Op 'n minimum moet jy monitor dat die bediener API of ens groter as 0 is. Ens kan baie maatstawwe verskaf: op die skywe waarop dit draai, oor die gesondheid van sy ens-groepering, en ander.
Docker het lank gelede verskyn en almal is deeglik bewus van die probleme daarvan: baie houers veroorsaak vries en ander probleme. Daarom moet Docker self, as 'n stelsel, ook gemonitor word, ten minste vir beskikbaarheid.
dns. As DNS in 'n groep misluk, sal die hele Discovery-diens ook misluk, en oproepe van peule na peule sal ophou werk. In my praktyk was daar nie sulke probleme nie, maar dit beteken nie dat die DNS-status nie gemonitor hoef te word nie. Versoek latency en 'n paar ander maatstawwe kan nagespoor word op CoreDNS.
Intrede. Dit is nodig om die beskikbaarheid van ingange (insluitend ingangbeheerder) as toegangspunte tot die projek te beheer.
Die hoofkomponente van die groepering is uitmekaar gehaal - kom ons gaan nou laer, na die vlak van abstraksies.
Dit wil voorkom asof toepassings in peule loop, wat beteken dat hulle beheer moet word, maar in werklikheid doen hulle dit nie. Peule is kortstondig: vandag werk hulle op een bediener, môre op 'n ander; Vandag is daar 10 van hulle, môre 2. Dit is hoekom niemand die peule monitor nie. In 'n mikrodiensargitektuur is dit belangriker om die beskikbaarheid van die toepassing as geheel te beheer. Gaan veral na die beskikbaarheid van dienseindpunte: werk enigiets? As die toepassing beskikbaar is, wat gebeur dan daaragter, hoeveel replikas is daar nou - dit is tweede-orde vrae. Dit is nie nodig om individuele gevalle te monitor nie.
Op die laaste vlak moet u die werking van die toepassing self monitor, besigheidsstatistieke neem: die aantal bestellings, gebruikersgedrag, ens.
Prometheus
Die beste stelsel vir die monitering van 'n groepering is . Ek weet nie van enige instrument wat met Prometheus kan vergelyk wat kwaliteit en gebruiksgemak betref nie. Dit is wonderlik vir ratse infrastruktuur, so wanneer mense sê "Kubernetes monitering" bedoel hulle gewoonlik Prometheus.
Daar is 'n paar opsies om met Prometheus te begin: deur Helm te gebruik, kan jy gewone Prometheus of Prometheus Operator installeer.
- Gereelde Prometheus. Alles is goed daarmee, maar jy moet die ConfigMap konfigureer - in wese skryf tekskonfigurasielêers, soos ons voorheen gedoen het, voor die mikrodiensargitektuur.
- Prometheus Operator is 'n bietjie meer omvangryk, 'n bietjie meer kompleks in sy interne logika, maar dit is makliker om mee te werk: daar is aparte voorwerpe, abstraksies word by die groep gevoeg, so dit is baie geriefliker om te beheer en te konfigureer.
Om die produk te verstaan, beveel ek aan om eers gewone Prometheus te installeer. U sal alles deur die konfigurasie moet konfigureer, maar dit sal voordelig wees: u sal verstaan wat waartoe behoort en hoe dit opgestel is. In Prometheus Operator styg jy dadelik tot 'n hoër abstraksie, alhoewel as jy wil, kan jy ook in die dieptes delf.
Prometheus is goed geïntegreer met Kubernetes: dit het toegang tot en interaksie met die API-bediener.
Prometheus is gewild en word ondersteun deur 'n groot aantal toepassings en programmeertale. Ondersteuning is nodig omdat Prometheus sy eie maatstafformaat het, en om dit oor te dra, benodig jy óf 'n biblioteek binne die toepassing óf 'n klaargemaakte uitvoerder. En daar is nogal baie sulke uitvoerders. Daar is byvoorbeeld PostgreSQL-uitvoerder: dit neem data van PostgreSQL en sit dit om in Prometheus-formaat sodat Prometheus daarmee kan werk.
Prometheus argitektuur
Prometheus-bediener — dit is die bedienerdeel, die brein van Prometheus. Dit is waar metrieke gestoor en verwerk word.
Die maatstawwe word in die tydreeksdatabasis (TSDB) gestoor. TSDB is nie 'n aparte databasis nie, maar 'n Go-pakket wat in Prometheus ingebou is. Rofweg gesproke is alles in een binêr.
Moenie data lank in TSDB stoor nie
Die Prometheus-infrastruktuur is nie geskik vir langtermynberging van metrieke nie. Die verstekbergingstydperk is 15 dae. Jy kan hierdie limiet oorskry, maar hou in gedagte: hoe meer data jy in TSDB stoor en hoe langer jy dit doen, hoe meer hulpbronne sal dit verbruik. Die stoor van historiese data in Prometheus word as slegte praktyk beskou.
As u groot verkeer het, is die aantal metrieke in die honderdduisende per sekonde, dan is dit beter om hul berging volgens skyfspasie of -periode te beperk. Tipies stoor TSDB "warm data", metrieke letterlik vir 'n paar uur. Vir langertermynberging word eksterne berging gebruik in daardie databasisse wat werklik hiervoor geskik is, byvoorbeeld InfluxDB, ClickHouse, ensovoorts. Ek het meer goeie resensies oor ClickHouse gesien.
Prometheus Server werk volgens die model trek: hy self gaan vir metrieke na die eindpunte wat ons hom gegee het. Hulle het gesê: "gaan na die API-bediener," en dit gaan elke n-de aantal sekondes daarheen en neem die statistieke.
Vir voorwerpe met 'n kort lewensduur (job of cron job) wat tussen skraapperiodes mag voorkom, is daar 'n Pushgateway-komponent. Metrieke van korttermynvoorwerpe word daarin gedruk: die taak het gestyg, die aksie voltooi, die statistieke na Pushgateway gestuur en voltooi. Na 'n rukkie sal Prometheus teen sy eie pas gaan en hierdie maatstawwe van Pushgateway neem.
Om kennisgewings in Prometheus op te stel is daar 'n aparte komponent - Alertbestuurder. En die waarskuwingsreëls. Byvoorbeeld, jy moet 'n waarskuwing skep as die bediener-API 0 is. Wanneer die gebeurtenis geaktiveer word, word die waarskuwing aan die waarskuwingsbestuurder oorgedra vir verdere versending. Die waarskuwingsbestuurder het redelik buigsame roete-instellings: een groep waarskuwings kan na die administrateurs se telegramklets gestuur word, 'n ander na die ontwikkelaars se klets, en 'n derde na die infrastruktuurwerkers se klets. Kennisgewings kan na Slack, Telegram, e-pos en ander kanale gestuur word.
En laastens, ek sal jou vertel van die moordende kenmerk van Prometheus - Ontdekking van. Wanneer jy met Prometheus werk, hoef jy nie spesifieke adresse van voorwerpe te spesifiseer om te monitor nie; dit is genoeg om hul tipe te spesifiseer. Dit wil sê, dit is nie nodig om te skryf "hier is die IP-adres, hier is die poort - monitor", in plaas daarvan moet jy bepaal deur watter beginsels om hierdie voorwerpe te vind (teikens - doelwitte). Prometheus self, afhangende van watter voorwerpe tans aktief is, trek die nodige op en voeg dit by monitering.
Hierdie benadering pas goed by die struktuur van Kubernetes, waar alles ook dryf: vandag is daar 10 bedieners, môre 3. Om nie elke keer die bediener se IP-adres aan te dui nie, het ons eenkeer geskryf hoe om dit te vind - en Discovering sal dit doen.
Die Prometheus-taal word genoem PromQL. Deur hierdie taal te gebruik, kan u die waardes van spesifieke statistieke kry en dit dan transformeer en analitiese berekeninge op grond daarvan bou.
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-webkoppelvlak
Prometheus het sy eie, taamlik minimalistiese webkoppelvlak. Slegs geskik vir ontfouting of demonstrasie.
Jy kan 'n navraag in PromQL in die Expression-lyn skryf.
Die Waarskuwings-oortjie bevat waarskuwingsreëls, en hulle het drie statusse:
- onaktief - as die waarskuwing nie op die oomblik aktief is nie, dit wil sê, alles is goed daarmee, en dit het nie gewerk nie;
- hangende - dit is as die waarskuwing geaktiveer is, maar die versending het nog nie plaasgevind nie. Die vertraging is ingestel om te vergoed vir netwerkknippering: as die gespesifiseerde diens binne 'n minuut gestyg het, is dit nog nie nodig om die alarm te maak nie;
- afvuur is die derde status, wanneer die waarskuwing brand en boodskappe stuur.
In die Status-kieslys sal jy toegang kry tot inligting oor wat Prometheus is. Daar is ook 'n oorgang na die doelwitte waaroor ons hierbo gepraat het.
Vir 'n meer gedetailleerde oorsig van die Prometheus-koppelvlak, sien .
Integrasie met Grafana
In die Prometheus-webkoppelvlak sal jy nie pragtige en verstaanbare grafieke vind waaruit jy gevolgtrekkings kan maak oor die toestand van die tros nie. Om hulle te bou, integreer Prometheus met Grafana. Dit is die dashboards wat ons kry.
Om die integrasie van Prometheus en Grafana op te stel is glad nie moeilik nie; instruksies kan in die dokumentasie gevind word: , wel, ek sal hiermee klaarmaak.
In die volgende artikels sal ons voortgaan met die onderwerp van monitering: ons sal praat oor die insameling en ontleding van logs met behulp van Grafana Loki en alternatiewe gereedskap.
Skrywer: Marcel Ibraev, gesertifiseerde Kubernetes-administrateur, praktiserende ingenieur in die maatskappy , spreker en Slurm kursus ontwikkelaar.
Bron: will.com