Övervaka ett Kubernetes-kluster: En översikt och introduktion till Prometheus

Låt oss titta på konceptet med Kubernetes-övervakning, bekanta oss med verktyget Prometheus och prata om larm.

Ämnet övervakning är omfattande, det kan inte tas upp i en artikel. Syftet med denna text är att ge en översikt över verktygen, begreppen och tillvägagångssätten.

Materialet i artikeln är en kläm från öppen föreläsning av skolan "Slurm". Om du vill få full utbildning, anmäl dig till en kurs på Infrastruktur för övervakning och loggning i Kubernetes.

Vad som övervakas i ett Kubernetes-kluster

Fysiska servrar. Om ett Kubernetes-kluster distribueras på sina egna servrar måste du övervaka deras tillstånd. Zabbix sköter denna uppgift; om du arbetar med honom, så finns det ingen anledning att vägra, det kommer inga konflikter. Det är Zabbix som övervakar tillståndet på våra servrar.

Låt oss gå vidare till övervakning på klusternivå.

Kontrollplanets komponenter: API, Scheduler och andra. Som ett minimum måste du övervaka att serverns API eller etcd är större än 0. Etcd kan tillhandahålla många mätvärden: på diskarna som den snurrar på, om hälsan hos dess etcd-kluster och andra.

Hamnarbetare dök upp för länge sedan och alla är väl medvetna om dess problem: många behållare orsakar frysningar och andra problem. Därför bör Docker självt, som ett system, också övervakas, åtminstone för tillgänglighet.

dns. Om DNS misslyckas i ett kluster kommer hela Discovery-tjänsten också att misslyckas, och samtal från pods till pods slutar fungera. I min praktik fanns det inga sådana problem, men det betyder inte att DNS-statusen inte behöver övervakas. Begäranvändning och vissa andra mätvärden kan spåras på CoreDNS.

Inträde. Det är nödvändigt att kontrollera tillgängligheten av ingresser (inklusive Ingress Controller) som ingångspunkter till projektet.

Huvudkomponenterna i klustret har tagits isär - låt oss nu gå lägre, till abstraktionsnivån.

Det verkar som att applikationer körs i pods, vilket betyder att de måste kontrolleras, men i verkligheten gör de det inte. Pods är tillfälliga: idag fungerar de på en server, imorgon på en annan; Idag är det 10 av dem, imorgon 2. Det är därför ingen övervakar baljorna. I en mikrotjänstarkitektur är det viktigare att kontrollera tillgängligheten för applikationen som helhet. Kontrollera särskilt tillgängligheten för tjänstens slutpunkter: fungerar något? Om applikationen är tillgänglig, vad händer bakom den, hur många repliker det finns nu - det här är andra ordningens frågor. Det finns inget behov av att övervaka enskilda instanser.

På den sista nivån måste du övervaka driften av själva applikationen, ta affärsmått: antalet beställningar, användarbeteende etc.

Prometheus

Det bästa systemet för att övervaka ett kluster är Prometheus. Jag känner inte till något verktyg som kan jämföras med Prometheus vad gäller kvalitet och användarvänlighet. Det är bra för agil infrastruktur, så när folk säger "Kubernetes-övervakning" menar de vanligtvis Prometheus.

Det finns ett par alternativ för att komma igång med Prometheus: med Helm kan du installera vanliga Prometheus eller Prometheus Operator.

1. Vanlig Prometheus. Allt är bra med det, men du måste konfigurera ConfigMap - i huvudsak, skriv textkonfigurationsfiler, som vi gjorde tidigare, innan mikrotjänstarkitekturen.
2. Prometheus Operator är lite mer omfattande, lite mer komplex i sin interna logik, men det är lättare att arbeta med: det finns separata objekt, abstraktioner läggs till i klustret, så de är mycket bekvämare att kontrollera och konfigurera.

För att förstå produkten rekommenderar jag att du installerar vanliga Prometheus först. Du måste konfigurera allt genom konfigurationen, men detta kommer att vara fördelaktigt: du kommer att förstå vad som hör till vad och hur det är konfigurerat. I Prometheus Operator stiger du omedelbart till en högre abstraktion, även om du vill kan du också fördjupa dig i djupet.

Prometheus är väl integrerad med Kubernetes: den kan komma åt och interagera med API-servern.

Prometheus är populärt och stöds av ett stort antal applikationer och programmeringsspråk. Support behövs eftersom Prometheus har sitt eget måttformat, och för att överföra det behöver du antingen ett bibliotek inuti applikationen eller en färdig exportör. Och det finns ganska många sådana exportörer. Till exempel finns det PostgreSQL Exporter: den tar data från PostgreSQL och konverterar den till Prometheus-format så att Prometheus kan arbeta med den.

Prometheus arkitektur

Prometheus server — det här är serverdelen, Prometheus hjärna. Det är här mätvärdena lagras och bearbetas.

Mätvärdena lagras i tidsseriedatabasen (TSDB). TSDB är inte en separat databas, utan ett Go-paket som är inbyggt i Prometheus. Grovt sett är allt i en binär.

Lagra inte data i TSDB länge

Prometheus infrastruktur är inte lämplig för långtidslagring av mätvärden. Standardlagringsperioden är 15 dagar. Du kan överskrida denna gräns, men kom ihåg: ju mer data du lagrar i TSDB och ju längre du gör det, desto mer resurser kommer det att förbruka. Att lagra historiska data i Prometheus anses vara dålig praxis.

Om du har enorm trafik, är antalet mätvärden i hundratusentals per sekund, då är det bättre att begränsa deras lagring efter diskutrymme eller period. Vanligtvis lagrar TSDB "het data", mätvärden bokstavligen i några timmar. För längre tids lagring används extern lagring i de databaser som verkligen lämpar sig för detta, till exempel InfluxDB, ClickHouse, och så vidare. Jag såg fler bra recensioner om ClickHouse.

Prometheus Server fungerar enligt modellen dra: han själv går efter mätvärden till de slutpunkter som vi gav honom. De sa: "gå till API-servern", och den går dit var n:e antal sekunder och tar måtten.

För objekt med kort livslängd (jobb eller cron-jobb) som kan dyka upp mellan skrapningsperioderna finns en Pushgateway-komponent. Mätvärden från kortsiktiga objekt trycks in i det: jobbet steg, fullbordade åtgärden, skickade mätvärdena till Pushgateway och slutförde. Efter en tid kommer Prometheus att gå i sin egen takt och ta dessa mätvärden från Pushgateway.

För att konfigurera aviseringar i Prometheus finns det en separat komponent - Alertmanager. Och varningsreglerna. Till exempel måste du skapa en varning om serverns API är 0. När händelsen utlöses skickas varningen till varningshanteraren för vidare sändning. Varningshanteraren har ganska flexibla routinginställningar: en grupp av varningar kan skickas till administratörernas telegramchatt, en annan till utvecklarnas chatt och en tredje till infrastrukturarbetarnas chatt. Aviseringar kan skickas till Slack, Telegram, e-post och andra kanaler.

Och slutligen, jag ska berätta för dig om den mördande egenskapen hos Prometheus - upptäcka. När du arbetar med Prometheus behöver du inte ange specifika adresser till objekt som ska övervakas, det räcker med att ange deras typ. Det vill säga, det finns inget behov av att skriva "här är IP-adressen, här är porten - monitor", istället måste du bestämma med vilka principer du ska hitta dessa objekt (mål - mål). Prometheus själv, beroende på vilka objekt som för närvarande är aktiva, drar upp de nödvändiga och lägger till dem i övervakningen.

Detta tillvägagångssätt passar bra med Kubernetes-strukturen, där allt också flyter: idag finns det 10 servrar, imorgon finns det 3. För att inte ange serverns IP-adress varje gång skrev vi en gång hur man hittar den – och Discovering kommer att göra det .

Prometheus-språket kallas PromQL. Med det här språket kan du få värdena för specifika mätvärden och sedan omvandla dem och bygga analytiska beräkningar baserade 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 webbgränssnitt

Prometheus har ett eget, ganska minimalistiskt webbgränssnitt. Endast lämplig för felsökning eller demonstration.

Du kan skriva en fråga i PromQL på raden Expression.

Fliken Varningar innehåller varningsregler och de har tre statusar:

1. inaktiv - om varningen inte är aktiv för tillfället, det vill säga allt är bra med det, och det fungerade inte;
2. väntar - detta är om varningen utlöstes, men sändningen ännu inte har skett. Fördröjningen är inställd för att kompensera för nätverkets blinkande: om den angivna tjänsten har stigit inom en minut, behöver du inte ringa larmet ännu;
3. skjutning är den tredje statusen, när varningen tänds och skickar meddelanden.

I Status-menyn hittar du tillgång till information om vad Prometheus är. Det finns också en övergång till målen som vi pratade om ovan.

För en mer detaljerad översikt av Prometheus-gränssnittet, se i Slurms föreläsning om övervakning av ett Kubernetes-kluster.

Integration med Grafana

I Prometheus webbgränssnitt hittar du inga vackra och begripliga grafer från vilka du kan dra slutsatser om klustrets tillstånd. För att bygga dem integrerar Prometheus med Grafana. Det här är instrumentpanelerna vi får.

Att ställa in integrationen av Prometheus och Grafana är inte alls svårt; instruktioner finns i dokumentationen: GRAFANA STÖD FÖR PROMETHEUS, ja, jag ska avsluta med det här.

I följande artiklar kommer vi att fortsätta med övervakningsämnet: vi kommer att prata om att samla in och analysera loggar med Grafana Loki och alternativa verktyg.

Författare: Marcel Ibraev, certifierad Kubernetes-administratör, praktiserande ingenjör i företaget Southbridge, talare och Slurm-kursutvecklare.

Källa: will.com