Laten we eens kijken naar het concept van Kubernetes-monitoring, kennismaken met de Prometheus-tool en het hebben over waarschuwingen.
Het onderwerp monitoring is veelomvattend en kan niet in één artikel worden behandeld. Het doel van deze tekst is om een overzicht te geven van de tools, concepten en benaderingen.
Het materiaal van het artikel is een knijpuitje . Wilt u de volledige training afronden, meld u dan aan voor de cursus .
Wat wordt er in een Kubernetes-cluster gemonitord?
Fysieke servers. Als u een Kubernetes-cluster op uw servers hebt geïmplementeerd, moet u de status ervan in de gaten houden. Zabbix pakt deze taak op; Als je met hem samenwerkt, hoef je niet te weigeren en zullen er geen conflicten ontstaan. Zabbix bewaakt de status van onze servers.
Laten we verder gaan met monitoring op clusterniveau.
Componenten van het besturingsvlak: API, Scheduler en andere. U moet minimaal controleren of de API van servers of etcd groter is dan 0. Etcd kan veel statistieken leveren: over de schijven waarop het draait, over de status van het etcd-cluster en meer.
havenarbeider is al lang geleden ontstaan en iedereen kent de problemen die het met zich meebrengt: veel containers veroorzaken bevriezing en andere problemen. Daarom moet Docker zelf, als systeem, ook worden gemonitord, op zijn minst wat betreft de beschikbaarheid.
dns. Als DNS in een cluster faalt, zal de gehele Discovery-service falen en zullen verzoeken van pods naar pods niet meer werken. In mijn praktijk doen zich geen dergelijke problemen voor, maar dat wil niet zeggen dat de DNS-status niet gecontroleerd hoeft te worden. Verzoeklatentie en enkele andere statistieken kunnen worden bijgehouden op CoreDNS.
Binnenkomen. Het is noodzakelijk om de beschikbaarheid van ingangen (inclusief de Ingress Controller) als toegangspunten tot het project te beheren.
Nadat we de hoofdcomponenten van het cluster hebben gedemonteerd, gaan we nu naar het abstractieniveau.
Je zou denken dat applicaties in pods draaien en dat ze dus beheerd moeten worden. Maar dat is niet het geval. Pods zijn vluchtig: vandaag werken ze op de ene server, morgen op een andere; Vandaag zijn het er 10, morgen 2. Daarom houdt niemand toezicht op de pods. In een microservicesarchitectuur is het belangrijker om de beschikbaarheid van de applicatie als geheel te beheren. Controleer met name de beschikbaarheid van service-eindpunten: werkt er iets? Als de applicatie beschikbaar is, wat er achter de applicatie gebeurt, hoeveel replica's er inmiddels zijn, dat zijn vragen van de tweede orde. Er is geen noodzaak om individuele gevallen te monitoren.
Op het laatste niveau moet u toezicht houden op de werking van de applicatie zelf en bedrijfsstatistieken verzamelen: aantal bestellingen, gebruikersgedrag, enzovoort.
Prometheus
Het beste systeem voor clusterbewaking is . Ik ken geen enkele tool die qua kwaliteit en gebruiksgemak te vergelijken is met Prometheus. Het is geweldig voor een flexibele infrastructuur. Als mensen het over "Kubernetes-monitoring" hebben, bedoelen ze meestal Prometheus.
Er zijn een aantal opties om aan de slag te gaan met Prometheus: via Helm kunt u de reguliere Prometheus of Prometheus Operator installeren.
- Regelmatige Prometheus. Alles is prima, maar je moet ConfigMap configureren. Dat betekent dat je tekstuele configuratiebestanden moet schrijven, net zoals we dat deden vóór de microservicesarchitectuur.
- Prometheus Operator is iets uitgebreider en iets complexer qua interne logica, maar is wel gemakkelijker om mee te werken. Het heeft afzonderlijke objecten en er worden abstracties aan het cluster toegevoegd, waardoor het veel handiger is om ze te beheren en configureren.
Om met het product aan de slag te kunnen, raad ik aan om eerst de reguliere Prometheus te installeren. Je moet alles via de configuratie configureren, maar het is wel nuttig: je leert wat met wat te maken heeft en hoe je het moet configureren. In Prometheus Operator ga je direct naar een hoger abstractieniveau, maar je kunt ook dieper graven als je dat wilt.
Prometheus is goed geïntegreerd met Kubernetes: het heeft toegang tot de API-server en kan ermee communiceren.
Prometheus is populair en wordt daarom door een groot aantal applicaties en programmeertalen ondersteund. Ondersteuning is nodig omdat Prometheus een eigen metrische indeling heeft en om deze over te zetten, een in-app-bibliotheek of een kant-en-klare exporter nodig is. En er zijn nogal wat van zulke exporteurs. Een voorbeeld is de PostgreSQL Exporter: deze haalt gegevens uit PostgreSQL en zet deze om in het Prometheus-formaat, zodat Prometheus ermee kan werken.
Prometheus-architectuur
Prometheus-server — dit is het servergedeelte, het brein van Prometheus. Hier worden de statistieken opgeslagen en verwerkt.
Metrieken worden opgeslagen in de tijdreeksdatabase (TSDB). TSDB is geen aparte database, maar een Go-pakket dat in Prometheus is ingebouwd. Grofweg gezegd bevindt alles zich in één binair systeem.
Bewaar gegevens niet te lang in TSDB
De Prometheus-infrastructuur is niet geschikt voor langdurige opslag van gegevens. De standaard bewaartermijn bedraagt 15 dagen. U kunt deze limiet overschrijden, maar houd er dan rekening mee dat hoe meer gegevens u in TSDB opslaat en hoe langer u dit doet, hoe meer bronnen dit zal verbruiken. Het opslaan van historische gegevens in Prometheus wordt als een slechte praktijk beschouwd.
Als u veel verkeer hebt, en het aantal statistieken honderdduizenden per seconde bedraagt, is het beter om de opslag te beperken door schijfruimte of door tijdsperiode. Normaal gesproken slaat TSDB “hot data”, statistieken, slechts enkele uren op. Voor langdurige opslag wordt gebruik gemaakt van externe opslag in die databases die hier echt geschikt voor zijn, bijvoorbeeld InfluxDB, ClickHouse, enzovoort. Ik heb meer goede recensies over ClickHouse gezien.
Prometheus Server werkt volgens het model trek: Hij gaat zelf voor metrieken in de eindpunten die wij aan hem hebben doorgegeven. Ze zeiden: "ga naar de API-server", en daar gaat het elke n-aantal seconden heen en verzamelt het gegevens.
Voor objecten met een korte levensduur (job of cronjob) die tussen de scraping-perioden kunnen verschijnen, is er een Pushgateway-component. Metrieken van kortetermijnobjecten worden hierin gepusht: de taak is gestart, er is een actie uitgevoerd, er zijn metrieken naar Pushgateway verzonden en de taak is afgerond. Na verloop van tijd zal Prometheus weer in het normale ritme komen en deze gegevens van Pushgateway overnemen.
Om meldingen te configureren, heeft Prometheus een apart onderdeel: Alertmanager. En de waarschuwingsregels. U moet bijvoorbeeld een waarschuwing maken als de API van de server 0 is. Wanneer de gebeurtenis wordt geactiveerd, wordt de waarschuwing doorgegeven aan de waarschuwingsbeheerder voor verdere verwerking. De waarschuwingsbeheerder heeft zeer flexibele routeringsinstellingen: één groep waarschuwingen kan naar de Telegramchat van de beheerders worden verzonden, een andere naar de chat van de ontwikkelaars en een derde naar de chat van de infrastructuurontwikkelaars. Meldingen kunnen naar Slack, Telegram, e-mail en andere kanalen worden verzonden.
En tot slot zal ik je vertellen over de belangrijkste feature van Prometheus: Het ontdekken van. Wanneer u met Prometheus werkt, hoeft u geen specifieke adressen op te geven van objecten die u wilt bewaken. Het is voldoende om hun type op te geven. Dat wil zeggen dat u niet hoeft te schrijven “hier is het IP-adres, hier is de poort – monitor”, maar dat u moet bepalen volgens welke principes deze objecten gevonden moeten worden (doelen - doelen). Prometheus haalt zelf, afhankelijk van welke objecten op dat moment actief zijn, de benodigde objecten op en voegt ze toe voor monitoring.
Deze aanpak past goed bij de Kubernetes-structuur, waar ook alles zwevend is: vandaag 10 servers, morgen 3. Om niet telkens het IP-adres van de server te hoeven specificeren, hebben we in één keer beschreven hoe je die kunt vinden - en Discovery doet dat.
De taal van Prometheus wordt genoemd PromQL. Met deze taal kunt u de waarden van specifieke statistieken extraheren en deze vervolgens transformeren, waarna u op basis daarvan analytische berekeningen kunt maken.
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-webinterface
Prometheus heeft een eigen, vrij minimalistische webinterface. Alleen geschikt voor foutopsporing of demonstratie.
In de regel Expressie kunt u een query schrijven in de PromQL-taal.
Het tabblad Waarschuwingen bevat waarschuwingsregels en deze hebben drie statussen:
- inactief — als de waarschuwing op dit moment niet actief is, dat wil zeggen dat er niets mis mee is en de waarschuwing niet is geactiveerd;
- in behandeling - dit gebeurt als het alarm is geactiveerd, maar het bericht nog niet is verzonden. De vertraging wordt ingesteld om te compenseren voor netwerkflikkeringen: als de opgegeven service binnen een minuut is toegenomen, is het nog niet nodig om het alarm te laten afgaan;
- Vuren is de derde status, waarbij het alarm oplicht en berichten verstuurt.
Via het menu Status krijgt u toegang tot informatie over Prometheus. Er is ook een overgang naar de doelstellingen waar we het hierboven over hadden.
Voor een meer gedetailleerd overzicht van de Prometheus-interface, zie .
Integratie met Grafana
In de webinterface van Prometheus vindt u geen mooie, duidelijke grafieken die u een beeld geven van de gezondheid van het cluster. Om deze te bouwen, wordt Prometheus geïntegreerd met Grafana. Zo zien de dashboards eruit.
Het opzetten van de integratie van Prometheus en Grafana is helemaal niet moeilijk. Instructies vindt u in de documentatie: Nou, ik zal het hierbij laten.
In de volgende artikelen gaan we verder met het onderwerp monitoring. We bespreken het verzamelen en analyseren van logs met behulp van Grafana Loki en alternatieve tools.
Auteur: Marcel Ibraev, gecertificeerde Kubernetes-beheerder, praktiserend ingenieur in het bedrijf , spreker en ontwikkelaar van Slurm-cursussen.
Bron: www.habr.com
