Denk eens aan het concept van Kubernetes-monitoring, maak kennis met de Prometheus-tool en praat over alerting.
Het onderwerp monitoring is omvangrijk, het kan niet in één artikel worden gedemonteerd. Het doel van deze tekst is om een overzicht te geven van de instrumenten, concepten en benaderingen.
Het materiaal van het artikel is een knijpuitje . Als je een volledige cursus wilt volgen, meld je dan aan voor een cursus op .
Wat wordt gemonitord in een Kubernetes-cluster
fysieke servers. Als het Kubernetes-cluster op zijn servers wordt geïmplementeerd, moet u de status ervan controleren. Zabbix verzorgt deze taak; als je met hem samenwerkt, hoef je niet te weigeren, er zullen geen conflicten zijn. Het is Zabbix die de status van onze servers bewaakt.
Laten we verder gaan met monitoring op clusterniveau.
Componenten van het besturingsvlak: API, Planner en anderen. Je moet er op zijn minst voor zorgen dat de API van servers of etcd groter is dan 0. Etcd kan veel statistieken retourneren: door de schijven waarop het draait, door de gezondheid van zijn etcd-cluster, en andere.
havenarbeider verscheen lang geleden en iedereen is zich terdege bewust van de problemen ervan: veel containers veroorzaken bevriezingen en andere problemen. Daarom moet Docker zelf, als systeem, ook worden gecontroleerd, in ieder geval op beschikbaarheid.
dns. Als DNS in het cluster wegvalt, valt de hele Discovery-service erna weg en werken oproepen van pods naar pods niet meer. In mijn praktijk waren dergelijke problemen niet aanwezig, maar dit betekent niet dat de status van de DNS niet hoeft te worden gecontroleerd. Verzoeklatentie en enkele andere statistieken kunnen worden bijgehouden op CoreDNS.
Ingress. Het is noodzakelijk om de beschikbaarheid van ingangen (inclusief de Ingress Controller) als toegangspunten tot het project te controleren.
De belangrijkste componenten van het cluster zijn ontmanteld - laten we nu naar het abstractieniveau gaan.
Het lijkt erop dat applicaties in pods draaien, wat betekent dat ze gecontroleerd moeten worden, maar in werkelijkheid is dat niet het geval. Pods zijn kortstondig: vandaag draaien ze op de ene server, morgen op een andere; vandaag zijn het er tien, morgen twee. Daarom houdt niemand toezicht op de pods. Binnen een microservice-architectuur is het belangrijker om de beschikbaarheid van de applicatie als geheel te beheersen. Controleer vooral de beschikbaarheid van service-eindpunten: werkt er iets? Als de applicatie beschikbaar is, wat er dan achter gebeurt, hoeveel replica's er nu zijn - dit zijn vragen van de tweede orde. Het is niet nodig om individuele gevallen te monitoren.
Op het laatste niveau moet u de werking van de applicatie zelf controleren en zakelijke statistieken gebruiken: het aantal bestellingen, gebruikersgedrag, enzovoort.
Prometheus
Het beste systeem voor het monitoren van een cluster is . Ik ken geen tool die Prometheus kan evenaren qua kwaliteit en gebruiksgemak. Het is geweldig voor flexibele infrastructuur, dus als ze ‘Kubernetes-monitoring’ zeggen, bedoelen ze meestal Prometheus.
Er zijn een aantal opties om aan de slag te gaan met Prometheus: met behulp van Helm kunt u een gewone Prometheus of Prometheus Operator installeren.
- Reguliere Prometheus. Alles gaat goed met hem, maar je moet ConfigMap configureren - in feite tekstgebaseerde configuratiebestanden schrijven, zoals we eerder deden, vóór de microservice-architectuur.
- Prometheus Operator is iets meer verspreid, iets ingewikkelder in termen van interne logica, maar het is gemakkelijker om ermee te werken: er zijn afzonderlijke objecten, abstracties worden aan het cluster toegevoegd, dus ze zijn veel handiger te beheren en te configureren.
Om het product te begrijpen, raad ik aan eerst de reguliere Prometheus te installeren. Je zult alles via de configuratie moeten configureren, maar dit zal nuttig zijn: je zult erachter komen wat bij wat hoort en hoe het is geconfigureerd. In Prometheus Operator stijg je meteen naar een abstractie hoger, al kun je desgewenst ook de diepte induiken.
Prometheus is goed geïntegreerd met Kubernetes: het heeft toegang tot en kan communiceren met de API Server.
Prometheus is populair en daarom ondersteunen een groot aantal applicaties en programmeertalen het. Ondersteuning is nodig, omdat Prometheus zijn eigen metrische indeling heeft, en om deze over te dragen heb je een bibliotheek in de applicatie nodig of een kant-en-klare exporteur. En er zijn nogal wat van dergelijke exporteurs. Er is bijvoorbeeld PostgreSQL Exporter: deze haalt gegevens uit PostgreSQL en converteert deze naar Prometheus-formaat zodat Prometheus ermee kan werken.
Prometheus-architectuur
Prometheus-server is de achterkant, het brein van Prometheus. Hier worden statistieken opgeslagen en verwerkt.
De statistieken worden opgeslagen in de tijdreeksdatabase (TSDB). TSDB is geen aparte database, maar een pakket in de Go-taal dat is ingebed in Prometheus. Grofweg gezegd zit alles in één binair getal.
Bewaar gegevens niet voor langere tijd in TSDB
De Prometheus-infrastructuur is niet geschikt voor langdurige opslag van statistieken. De standaardbewaartermijn bedraagt 15 dagen. U kunt deze limiet overschrijden, maar houd er rekening mee: hoe meer gegevens u in TSDB opslaat en hoe langer u dit doet, hoe meer bronnen het zal verbruiken. Het opslaan van historische gegevens in Prometheus wordt als een slechte praktijk beschouwd.
Als u veel verkeer heeft en het aantal statistieken honderdduizenden per seconde bedraagt, is het beter om de opslag ervan te beperken op schijfruimte of op periode. Meestal worden ‘hot data’ opgeslagen in TSDB, statistieken in slechts een paar uur. Voor langere opslag wordt gebruik gemaakt van externe opslag in die databases die hier echt geschikt voor zijn, bijvoorbeeld InfluxDB, ClickHouse, enzovoort. Ik zag meer goede recensies over ClickHouse.
Prometheus Server werkt op het model trek: hij gaat voor statistieken voor de eindpunten die we hem hebben gegeven. Ze zeiden: "ga naar de API-server", en hij gaat daar elk n-de aantal seconden heen en neemt de statistieken op.
Voor objecten met een korte levensduur (job of cronjob) die tussen schraapperioden kunnen verschijnen, is er een Pushgateway-component. Metrieken van kortetermijnobjecten worden erin gepusht: de taak is gestegen, heeft een actie uitgevoerd, metrieken naar Pushgateway verzonden en voltooid. Na een tijdje zal Prometheus in zijn eigen tempo naar beneden komen en deze statistieken van Pushgateway ophalen.
Om meldingen in Prometheus te configureren is er een apart onderdeel - Alertmanager. En de waarschuwingsregels. U moet bijvoorbeeld een waarschuwing maken als de server-API 0 is. Wanneer de gebeurtenis wordt geactiveerd, wordt de waarschuwing doorgegeven aan de waarschuwingsmanager voor verdere verzending. De waarschuwingsmanager heeft vrij flexibele routeringsinstellingen: een 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 infrastructuurwerkers. Meldingen kunnen worden verzonden naar Slack, Telegram, e-mail en andere kanalen.
En tot slot zal ik je vertellen over de Prometheus-moordenaarsfunctie - Het ontdekken van. Wanneer u met Prometheus werkt, hoeft u geen specifieke adressen van objecten op te geven voor monitoring, het volstaat om hun type in te stellen. Dat wil zeggen, u hoeft niet te schrijven "hier is het IP-adres, hier is de poort - monitor", maar u moet bepalen op basis van welke principes u deze objecten kunt vinden (doelen - doelen). Prometheus zelf haalt, afhankelijk van welke objecten momenteel actief zijn, de nodige op en voegt deze toe aan de monitoring.
Deze aanpak past goed bij de Kubernetes-structuur, waar ook alles zweeft: vandaag zijn er 10 servers, morgen 3. Om niet elke keer het IP-adres van de server op te geven, hebben ze een keer geschreven hoe je het kunt vinden - en Discovering zal het doen .
De Prometheus-taal wordt genoemd PromQL. Met behulp van deze taal kunt u de waarden van specifieke statistieken verkrijgen en deze vervolgens converteren, en op basis daarvan analytische berekeningen 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 debuggen of demonstratie.
In de expressieregel 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 alles in orde is en dat het niet werkte;
- in behandeling - dit is als de waarschuwing werkte, maar de verzending nog niet is voltooid. De vertraging is ingesteld om te compenseren voor het knipperen van het netwerk: als de opgegeven dienst binnen een minuut is gestegen, mag het alarm nog niet klinken;
- vuren is de derde status wanneer het alarm oplicht en berichten verzendt.
In het Statusmenu vindt u toegang tot informatie over wat Prometheus is. Er is ook een overgang naar de doelstellingen (targets), waar we het hierboven over hadden.
Voor een gedetailleerder overzicht van de Prometheus-interface, zie .
Integratie met Grafana
In de Prometheus-webinterface vind je geen mooie en begrijpelijke grafieken waaruit je een conclusie kunt trekken over de toestand van het cluster. Om ze te bouwen, is Prometheus geïntegreerd met Grafana. We krijgen zulke dashboards.
Het opzetten van de Prometheus en Grafana integratie is helemaal niet moeilijk, instructies vind je in de documentatie: Nou, ik eindig hiermee.
In de volgende artikelen gaan we verder met het onderwerp monitoring: we zullen het hebben over 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 cursusontwikkelaar Slurm.
Bron: www.habr.com