Vurder konseptet med Kubernetes-overvåking, gjør deg kjent med Prometheus-verktøyet og snakk om varsling.
Temaet for overvåking er omfangsrikt, det kan ikke demonteres i en artikkel. Hensikten med denne teksten er å gi en oversikt over verktøyene, konseptene og tilnærmingene.
Materialet til artikkelen er en klem fra . Ønsker du å ta et fullt kurs - meld deg på kurs på .
Hva overvåkes i en Kubernetes-klynge
fysiske servere. Hvis Kubernetes-klyngen er distribuert på serverne, må du overvåke helsen deres. Zabbix håndterer denne oppgaven; hvis du jobber med ham, trenger du ikke å nekte, det vil ikke være noen konflikter. Det er Zabbix som overvåker tilstanden til serverne våre.
La oss gå videre til overvåking på klyngenivå.
Kontrollplankomponenter: API, Scheduler og andre. Som et minimum må du sørge for at API-en til servere eller etcd er større enn 0. Etcd kan returnere mange beregninger: etter diskene den spinner på, av helsen til etcd-klyngen og andre.
Docker dukket opp for lenge siden, og alle er godt klar over problemene: mange beholdere gir opphav til fryser og andre problemer. Derfor bør Docker selv, som et system, også kontrolleres, i det minste for tilgjengelighet.
dns. Hvis DNS faller av i klyngen, vil hele Discovery-tjenesten falle av etter den, anrop fra pods til pods vil slutte å fungere. I min praksis var det ingen slike problemer, men dette betyr ikke at tilstanden til DNS ikke trenger å overvåkes. Forespørselsforsinkelse og noen andre beregninger kan spores på CoreDNS.
Ingress. Det er nødvendig å kontrollere tilgjengeligheten av ingresser (inkludert Ingress Controller) som inngangspunkter til prosjektet.
Hovedkomponentene i klyngen er demontert - la oss nå gå ned til abstraksjonsnivået.
Det ser ut til at applikasjoner kjører i pods, noe som betyr at de må kontrolleres, men i virkeligheten er de det ikke. Pods er flyktige: i dag kjører de på en server, i morgen på en annen; i dag er det 10 av dem, i morgen 2. Derfor er det ingen som overvåker podene. Innenfor en mikrotjenestearkitektur er det viktigere å kontrollere tilgjengeligheten til applikasjonen som helhet. Sjekk spesielt tilgjengeligheten til tjenesteendepunkter: fungerer noe? Hvis applikasjonen er tilgjengelig, hva skjer bak den, hvor mange kopier er det nå - dette er spørsmål av andre rekkefølge. Det er ikke nødvendig å overvåke enkelttilfeller.
På det siste nivået må du kontrollere driften av selve applikasjonen, ta forretningsberegninger: antall bestillinger, brukeratferd og så videre.
Prometheus
Det beste systemet for å overvåke en klynge er . Jeg vet ikke om noe verktøy som kan matche Prometheus når det gjelder kvalitet og brukervennlighet. Det er flott for fleksibel infrastruktur, så når de sier "Kubernetes-overvåking", mener de vanligvis Prometheus.
Det er et par alternativer for å komme i gang med Prometheus: ved å bruke Helm kan du installere en vanlig Prometheus- eller Prometheus-operatør.
- Vanlig Prometheus. Alt er bra med ham, men du må konfigurere ConfigMap - faktisk skrive tekstbaserte konfigurasjonsfiler, som vi gjorde før, før mikrotjenestearkitekturen.
- Prometheus Operator er litt mer spredt, litt mer komplisert med tanke på intern logikk, men det er lettere å jobbe med det: det er separate objekter, abstraksjoner legges til klyngen, så de er mye mer praktiske å kontrollere og konfigurere.
For å forstå produktet anbefaler jeg å installere den vanlige Prometheus først. Du må konfigurere alt gjennom konfigurasjonen, men dette vil være fordelaktig: du vil finne ut hva som hører til hva og hvordan det er konfigurert. I Prometheus Operator stiger du umiddelbart til en abstraksjon høyere, selv om du også kan fordype deg i dypet hvis du ønsker det.
Prometheus er godt integrert med Kubernetes: den kan få tilgang til og samhandle med API-serveren.
Prometheus er populær, og det er grunnen til at et stort antall applikasjoner og programmeringsspråk støtter det. Støtte er nødvendig, siden Prometheus har sitt eget metrikkformat, og for å overføre det trenger du enten et bibliotek inne i applikasjonen eller en ferdig eksportør. Og det er ganske mange slike eksportører. For eksempel er det PostgreSQL Exporter: den tar data fra PostgreSQL og konverterer dem til Prometheus-format slik at Prometheus kan jobbe med det.
Prometheus arkitektur
Prometheus server er bakenden, hjernen til Prometheus. Beregninger lagres og behandles her.
Beregningene lagres i tidsseriedatabasen (TSDB). TSDB er ikke en egen database, men en pakke på Go-språket som er innebygd i Prometheus. Grovt sett er alt i en binær.
Ikke lagre data i TSDB over lengre tid
Prometheus-infrastrukturen er ikke egnet for langtidslagring av metrikk. Standard oppbevaringsperiode er 15 dager. Du kan overskride denne grensen, men husk: jo mer data du lagrer i TSDB og jo lenger du gjør det, jo mer ressurser vil det forbruke. Lagring av historiske data i Prometheus anses som dårlig praksis.
Hvis du har stor trafikk, er antallet beregninger hundretusener per sekund, så er det bedre å begrense lagringen deres etter diskplass eller etter periode. Vanligvis lagres "hot data" i TSDB, beregninger på bare noen få timer. For lengre lagring brukes ekstern lagring i de databasene som virkelig egner seg for dette, for eksempel InfluxDB, ClickHouse og så videre. Jeg så flere gode anmeldelser om ClickHouse.
Prometheus Server fungerer på modellen trekke: han går for beregninger til de endepunktene vi ga ham. De sa: "gå til API-serveren", og han går dit hvert n-te antall sekunder og tar beregningene.
For objekter med kort levetid (jobb eller cron-jobb) som kan dukke opp mellom skrapeperioder, finnes det en Pushgateway-komponent. Beregninger fra kortsiktige objekter blir presset inn i den: jobben har steget, utført en handling, sendt beregninger til Pushgateway og fullført. Etter en stund vil Prometheus komme ned i sitt eget tempo og hente disse beregningene fra Pushgateway.
For å konfigurere varsler i Prometheus er det en egen komponent - Alertmanager. Og varslingsreglene. Du må for eksempel opprette et varsel hvis server-API-en er 0. Når hendelsen utløses, sendes varselet til varselbehandleren for videre utsendelse. Varslingsbehandleren har ganske fleksible rutinginnstillinger: en gruppe med varsler kan sendes til administratorens telegramchat, en annen til utviklernes chat og en tredje til infrastrukturarbeidernes chat. Varsler kan sendes til Slack, Telegram, e-post og andre kanaler.
Og til slutt skal jeg fortelle deg om Prometheus-killer-funksjonen - Oppdage. Når du arbeider med Prometheus, trenger du ikke spesifisere spesifikke adresser til objekter for overvåking, det er nok å angi deres type. Det vil si at du ikke trenger å skrive "her er IP-adressen, her er porten - monitor", i stedet må du bestemme etter hvilke prinsipper du skal finne disse objektene (mål - mål). Prometheus selv, avhengig av hvilke objekter som for øyeblikket er aktive, trekker opp de nødvendige og legger dem til overvåking.
Denne tilnærmingen passer godt med Kubernetes-strukturen, der alt også flyter: i dag er det 10 servere, i morgen 3. For ikke å spesifisere IP-adressen til serveren hver gang, skrev de en gang hvordan man finner den – og Discovering vil gjøre det .
Prometheus-språket kalles PromQL. Ved å bruke dette språket kan du få verdiene til spesifikke beregninger og deretter konvertere dem, bygge analytiske beregninger basert 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 nettgrensesnitt
Prometheus har sitt eget, ganske minimalistiske nettgrensesnitt. Kun egnet for feilsøking eller demonstrasjon.
På Expression-linjen kan du skrive en spørring på PromQL-språket.
Kategorien Varsler inneholder varslingsregler, og de har tre statuser:
- inaktiv - hvis varselet ikke er aktivt for øyeblikket, det vil si at alt er bra med det, og det fungerte ikke;
- venter - dette er hvis varselet fungerte, men sendingen ennå ikke har passert. Forsinkelsen er satt til å kompensere for nettverksblinking: hvis den spesifiserte tjenesten har steget innen et minutt, bør alarmen ikke utløses ennå;
- avfyring er den tredje statusen når varselet lyser og sender meldinger.
I Status-menyen finner du tilgang til informasjon om hva Prometheus er. Det er også en overgang til målene (målene), som vi snakket om ovenfor.
For en mer detaljert oversikt over Prometheus-grensesnittet, se .
Integrasjon med Grafana
I Prometheus-nettgrensesnittet finner du ikke vakre og forståelige grafer som du kan trekke en konklusjon om tilstanden til klyngen fra. For å bygge dem er Prometheus integrert med Grafana. Vi får slike dashbord.
Å sette opp integreringen av Prometheus og Grafana er ikke vanskelig i det hele tatt, du kan finne instruksjoner i dokumentasjonen: Vel, jeg avslutter med dette.
I de følgende artiklene vil vi fortsette temaet overvåking: vi vil snakke om å samle og analysere logger ved hjelp av Grafana Loki og alternative verktøy.
Forfatter: Marcel Ibraev, sertifisert Kubernetes-administrator, praktiserende ingeniør i selskapet , foredragsholder og kursutvikler Slurm.
Kilde: www.habr.com