Lad os se på konceptet med Kubernetes-overvågning, stifte bekendtskab med Prometheus-værktøjet og tale om alarmering.
Emnet overvågning er omfangsrigt; det kan ikke dækkes i én artikel. Formålet med denne tekst er at give et overblik over værktøjerne, begreberne og tilgangene.
Artiklens materiale er et klem fra . Hvis du ønsker at få fuld træning, så tilmeld dig et kursus vedr .
Hvad overvåges i en Kubernetes-klynge
Fysiske servere. Hvis en Kubernetes-klynge er installeret på dens egne servere, skal du overvåge deres helbred. Zabbix varetager denne opgave; hvis du arbejder med ham, så er der ingen grund til at nægte, der vil ikke være nogen konflikter. Det er Zabbix, der overvåger tilstanden på vores servere.
Lad os gå videre til overvågning på klyngeniveau.
Kontrolplans komponenter: API, Scheduler og andre. Som minimum skal du overvåge, at server-API'en eller etcd'en er større end 0. Etcd kan give mange metrics: på de diske, som den spinder på, om sundheden for dens etcd-klynge og andre.
Docker dukkede op for længe siden, og alle er godt klar over dets problemer: mange beholdere forårsager fryse og andre problemer. Derfor bør Docker selv, som et system, også overvåges, i det mindste for tilgængelighed.
dns. Hvis DNS fejler i en klynge, vil hele Discovery-tjenesten også fejle, og opkald fra pods til pods vil holde op med at virke. I min praksis var der ingen sådanne problemer, men det betyder ikke, at DNS-status ikke skal overvåges. Anmodningsforsinkelse og nogle andre målinger kan spores på CoreDNS.
Ingress. Det er nødvendigt at kontrollere tilgængeligheden af indgange (inklusive Ingress Controller) som indgangspunkter i projektet.
Hovedkomponenterne i klyngen er blevet adskilt - lad os nu gå lavere, til abstraktionsniveauet.
Det ser ud til, at applikationer kører i pods, hvilket betyder, at de skal kontrolleres, men i virkeligheden gør de det ikke. Pods er flygtige: i dag arbejder de på én server, i morgen på en anden; I dag er der 10 af dem, i morgen 2. Derfor er der ingen, der overvåger bælgerne. I en mikroservicearkitektur er det vigtigere at kontrollere tilgængeligheden af applikationen som helhed. Tjek især tilgængeligheden af serviceendepunkter: virker noget? Hvis applikationen er tilgængelig, hvad sker der så bagved, hvor mange replikaer er der nu - det er andenordens spørgsmål. Det er ikke nødvendigt at overvåge individuelle tilfælde.
På det sidste niveau skal du overvåge driften af selve applikationen, tage forretningsmålinger: antallet af ordrer, brugeradfærd osv.
Prometheus
Det bedste system til at overvåge en klynge er . Jeg kender ikke noget værktøj, der kan sammenlignes med Prometheus med hensyn til kvalitet og brugervenlighed. Det er fantastisk til agil infrastruktur, så når folk siger "Kubernetes-overvågning", mener de normalt Prometheus.
Der er et par muligheder for at komme i gang med Prometheus: ved at bruge Helm kan du installere almindelig Prometheus eller Prometheus Operator.
- Almindelig Prometheus. Alt er fint med det, men du skal konfigurere ConfigMap - i det væsentlige skrive tekstkonfigurationsfiler, som vi gjorde før, før mikroservicearkitekturen.
- Prometheus Operator er lidt mere omfattende, lidt mere kompleks i sin interne logik, men det er lettere at arbejde med: der er separate objekter, abstraktioner føjes til klyngen, så de er meget mere bekvemme at kontrollere og konfigurere.
For at forstå produktet anbefaler jeg først at installere almindelig Prometheus. Du bliver nødt til at konfigurere alt gennem konfigurationen, men dette vil være fordelagtigt: du vil forstå, hvad der hører til hvad og hvordan det er konfigureret. I Prometheus Operator stiger du straks til en højere abstraktion, selvom du, hvis du vil, også kan dykke ned i dybden.
Prometheus er godt integreret med Kubernetes: den kan få adgang til og interagere med API-serveren.
Prometheus er populær og understøttes af en lang række applikationer og programmeringssprog. Support er nødvendig, fordi Prometheus har sit eget metriske format, og for at overføre det skal du enten have et bibliotek inde i applikationen eller en færdig eksportør. Og sådanne eksportører er der ret mange af. For eksempel er der PostgreSQL Exporter: den tager data fra PostgreSQL og konverterer dem til Prometheus-format, så Prometheus kan arbejde med det.
Prometheus arkitektur
Prometheus server — dette er serverdelen, Prometheus' hjerne. Det er her metrics gemmes og behandles.
Metrikken gemmes i tidsseriedatabasen (TSDB). TSDB er ikke en separat database, men en Go-pakke, der er indbygget i Prometheus. Groft sagt er alt i én binær.
Gem ikke data i TSDB længe
Prometheus-infrastrukturen er ikke egnet til langtidslagring af metrikker. Standardopbevaringsperioden er 15 dage. Du kan overskride denne grænse, men du skal huske på: Jo flere data du gemmer i TSDB og jo længere tid du gør det, jo flere ressourcer vil det forbruge. Lagring af historiske data i Prometheus betragtes som dårlig praksis.
Hvis du har enorm trafik, er antallet af metrics i hundredtusindvis i sekundet, så er det bedre at begrænse deres lagerplads efter diskplads eller periode. Typisk gemmer TSDB "hot data", metrics bogstaveligt talt i et par timer. Til længerevarende lagring bruges ekstern lagring i de databaser, der virkelig egner sig til dette, for eksempel InfluxDB, ClickHouse, og så videre. Jeg så flere gode anmeldelser om ClickHouse.
Prometheus Server fungerer efter modellen Træk: han går selv efter metrics til de endepunkter, som vi gav ham. De sagde: "gå til API-serveren," og den går der hvert n'te antal sekunder og tager metrics.
For objekter med kort levetid (job eller cron job), der kan dukke op mellem skrabeperioder, er der en Pushgateway-komponent. Målinger fra kortsigtede objekter skubbes ind i det: Jobbet steg, fuldførte handlingen, sendte metrikken til Pushgateway og fuldført. Efter nogen tid vil Prometheus gå i sit eget tempo og tage disse målinger fra Pushgateway.
For at konfigurere meddelelser i Prometheus er der en separat komponent - Alertmanager. Og varslingsreglerne. For eksempel skal du oprette en advarsel, hvis server-API'en er 0. Når hændelsen udløses, sendes advarslen til advarselsadministratoren for yderligere afsendelse. Alert-manageren har ret fleksible routing-indstillinger: en gruppe af advarsler kan sendes til administratorernes telegramchat, en anden til udviklernes chat og en tredje til infrastrukturarbejdernes chat. Notifikationer kan sendes til Slack, Telegram, e-mail og andre kanaler.
Og til sidst vil jeg fortælle dig om det dræbende træk ved Prometheus - Opdage. Når du arbejder med Prometheus, behøver du ikke at angive specifikke adresser på objekter, der skal overvåges; det er nok at angive deres type. Det vil sige, at der ikke er behov for at skrive "her er IP-adressen, her er porten - monitor", i stedet skal du bestemme efter hvilke principper du skal finde disse objekter (mål - mål). Prometheus selv, afhængigt af hvilke objekter der er aktive i øjeblikket, trækker de nødvendige op og tilføjer dem til overvågning.
Denne tilgang passer godt til strukturen i Kubernetes, hvor alt også flyder: i dag er der 10 servere, i morgen 3. For ikke at angive serverens IP-adresse hver gang, skrev vi engang, hvordan man finder den – og Discovering vil gøre det.
Prometheus-sproget kaldes PromQL. Ved at bruge dette sprog kan du få værdierne af specifikke metrikker og derefter transformere dem og bygge analytiske beregninger baseret på dem.
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 webgrænseflade
Prometheus har sin egen, ret minimalistiske webgrænseflade. Kun egnet til fejlfinding eller demonstration.
Du kan skrive en forespørgsel i PromQL i Expression-linjen.
Fanen Alarmer indeholder advarselsregler, og de har tre statusser:
- inaktiv - hvis advarslen ikke er aktiv i øjeblikket, det vil sige, at alt er fint med det, og det virkede ikke;
- afventer - dette er, hvis alarmen blev udløst, men afsendelsen endnu ikke har fundet sted. Forsinkelsen er indstillet til at kompensere for netværksblink: hvis den angivne tjeneste er steget inden for et minut, er der ikke behov for at slå alarmen endnu;
- affyring er den tredje status, når alarmen lyser og sender beskeder.
I statusmenuen finder du adgang til information om, hvad Prometheus er. Der er også en overgang til de mål, som vi talte om ovenfor.
For en mere detaljeret oversigt over Prometheus-grænsefladen, se .
Integration med Grafana
I Prometheus-webgrænsefladen finder du ikke smukke og forståelige grafer, hvorfra du kan drage konklusioner om klyngens tilstand. For at bygge dem integrerer Prometheus med Grafana. Det er de dashboards, vi får.
Opsætning af integrationen af Prometheus og Grafana er overhovedet ikke vanskelig; instruktioner kan findes i dokumentationen: Nå, jeg slutter med det her.
I de følgende artikler vil vi fortsætte emnet overvågning: vi vil tale om indsamling og analyse af logfiler ved hjælp af Grafana Loki og alternative værktøjer.
Forfatter: Marcel Ibraev, certificeret Kubernetes-administrator, praktiserende ingeniør i virksomheden , speaker og Slurm kursusudvikler.
Kilde: www.habr.com