Să ne uităm la conceptul de monitorizare Kubernetes, să ne familiarizăm cu instrumentul Prometheus și să vorbim despre alertă.
Tema monitorizării este voluminoasă, nu poate fi tratată într-un articol. Scopul acestui text este de a oferi o privire de ansamblu asupra instrumentelor, conceptelor și abordărilor.
Materialul articolului este o stoarcere din . Dacă doriți să obțineți o pregătire completă, înscrieți-vă la un curs despre .
Ce este monitorizat într-un cluster Kubernetes
Servere fizice. Dacă un cluster Kubernetes este implementat pe propriile servere, trebuie să le monitorizați starea de sănătate. Zabbix se ocupă de această sarcină; dacă lucrezi cu el, atunci nu este nevoie să refuzi, nu vor exista conflicte. Zabbix este cel care monitorizează starea serverelor noastre.
Să trecem la monitorizarea la nivel de cluster.
Componentele planului de control: API, Scheduler și altele. Cel puțin, trebuie să monitorizați dacă API-ul serverului sau etcd este mai mare decât 0. Etcd poate furniza multe valori: pe discurile pe care se rotește, asupra sănătății clusterului său etcd și altele.
Docher a apărut cu mult timp în urmă și toată lumea este conștientă de problemele sale: multe containere provoacă înghețuri și alte probleme. Prin urmare, Docker însuși, ca sistem, ar trebui monitorizat, cel puțin pentru disponibilitate.
dns. Dacă DNS eșuează într-un cluster, atunci întregul serviciu Discovery va eșua și apelurile de la poduri la poduri nu vor mai funcționa. În practica mea, nu au existat astfel de probleme, dar asta nu înseamnă că starea DNS nu trebuie monitorizată. Latența solicitărilor și alte valori pot fi urmărite pe CoreDNS.
Intrare. Este necesar să se controleze disponibilitatea intrărilor (inclusiv Ingress Controller) ca puncte de intrare în proiect.
Componentele principale ale clusterului au fost dezasamblate - acum să mergem mai jos, la nivelul abstracțiilor.
S-ar părea că aplicațiile rulează în pod-uri, ceea ce înseamnă că trebuie controlate, dar în realitate nu. Pod-urile sunt efemere: astăzi funcționează pe un server, mâine pe altul; Astăzi sunt 10, mâine 2. De aceea nimeni nu monitorizează păstăile. Într-o arhitectură de microservicii, este mai important să controlezi disponibilitatea aplicației în ansamblu. În special, verificați disponibilitatea punctelor finale de serviciu: funcționează ceva? Dacă aplicația este disponibilă, atunci ce se întâmplă în spatele ei, câte replici există acum - acestea sunt întrebări de ordinul doi. Nu este nevoie să monitorizați cazurile individuale.
La ultimul nivel, trebuie să monitorizați funcționarea aplicației în sine, să luați măsurători de afaceri: numărul de comenzi, comportamentul utilizatorilor etc.
Prometeu
Cel mai bun sistem de monitorizare a unui cluster este . Nu cunosc niciun instrument care să se compare cu Prometheus în ceea ce privește calitatea și ușurința în utilizare. Este grozav pentru infrastructura agilă, așa că atunci când oamenii spun „monitorizare Kubernetes” se referă de obicei la Prometheus.
Există câteva opțiuni pentru a începe cu Prometheus: folosind Helm, puteți instala Prometheus obișnuit sau Prometheus Operator.
- Prometeu obișnuit. Totul este în regulă, dar trebuie să configurați ConfigMap - în esență, scrieți fișiere de configurare text, așa cum am făcut înainte, înainte de arhitectura microservicii.
- Prometheus Operator este puțin mai extins, puțin mai complex în logica sa internă, dar este mai ușor de lucrat cu: există obiecte separate, abstracții sunt adăugate la cluster, astfel încât acestea sunt mult mai convenabile de controlat și configurat.
Pentru a înțelege produsul, vă recomand să instalați mai întâi Prometheus obișnuit. Va trebui să configurați totul prin config, dar acest lucru va fi benefic: veți înțelege ce aparține la ce și cum este configurat. În Prometheus Operator, te ridici imediat la o abstracție mai înaltă, deși dacă vrei, poți să te adânci și în adâncuri.
Prometheus este bine integrat cu Kubernetes: poate accesa și interacționa cu serverul API.
Prometheus este popular și este susținut de un număr mare de aplicații și limbaje de programare. Este nevoie de suport deoarece Prometheus are propriul format de metrică, iar pentru a-l transfera aveți nevoie fie de o bibliotecă în interiorul aplicației, fie de un exportator gata făcut. Și există destul de mulți astfel de exportatori. De exemplu, există PostgreSQL Exporter: preia date din PostgreSQL și le convertește în format Prometheus, astfel încât Prometheus să poată lucra cu el.
Arhitectura Prometheus
Serverul Prometheus — aceasta este partea de server, creierul lui Prometeu. Aici sunt stocate și procesate valorile.
Valorile sunt stocate în baza de date a serii de timp (TSDB). TSDB nu este o bază de date separată, ci un pachet Go care este încorporat în Prometheus. În linii mari, totul este într-un singur binar.
Nu stocați date în TSDB pentru mult timp
Infrastructura Prometheus nu este potrivită pentru stocarea pe termen lung a valorilor. Perioada implicită de stocare este de 15 zile. Puteți depăși această limită, dar rețineți: cu cât stocați mai multe date în TSDB și cu cât o veți face mai mult, cu atât va consuma mai multe resurse. Stocarea datelor istorice în Prometheus este considerată o practică proastă.
Dacă aveți trafic uriaș, numărul de metrici este de sute de mii pe secundă, atunci este mai bine să le limitați stocarea în funcție de spațiul pe disc sau perioadă. De obicei, TSDB stochează „date fierbinți”, valorile literalmente pentru câteva ore. Pentru stocarea pe termen mai lung, stocarea externă este utilizată în acele baze de date care sunt cu adevărat potrivite pentru aceasta, de exemplu InfluxDB, ClickHouse și așa mai departe. Am văzut mai multe recenzii bune despre ClickHouse.
Prometheus Server funcționează conform modelului trage: el însuși merge după metrici la punctele finale pe care i le-am dat. Ei au spus: „mergi la serverul API” și merge acolo la fiecare n-a de secunde și ia valorile.
Pentru obiectele cu o durată de viață scurtă (job sau cron job) care pot apărea între perioadele de scraping, există o componentă Pushgateway. Sunt introduse în el valorile de la obiecte pe termen scurt: jobul a crescut, acțiunea a finalizat, a trimis valorile către Pushgateway și a fost finalizată. După ceva timp, Prometheus va merge în ritmul său și va prelua aceste valori de la Pushgateway.
Pentru a configura notificările în Prometheus există o componentă separată - Alertmanager. Și regulile de alertă. De exemplu, trebuie să creați o alertă dacă API-ul serverului este 0. Când evenimentul este declanșat, alerta este transmisă managerului de alerte pentru trimitere ulterioară. Managerul de alerte are setări de rutare destul de flexibile: un grup de alerte poate fi trimis la chat-ul telegramelor administratorilor, altul la chat-ul dezvoltatorilor și un al treilea la chat-ul lucrătorilor din infrastructură. Notificările pot fi trimise către Slack, Telegram, e-mail și alte canale.
Și, în sfârșit, vă voi spune despre caracteristica ucigașă a lui Prometheus - descoperirea. Când lucrați cu Prometheus, nu trebuie să specificați adrese specifice ale obiectelor de monitorizat; este suficient să specificați tipul acestora. Adică, nu este nevoie să scrieți „aici este adresa IP, aici este portul - monitor”, ci trebuie să determinați după ce principii să găsiți aceste obiecte (obiective - goluri). Prometheus însuși, în funcție de obiectele care sunt active în prezent, le trage pe cele necesare și le adaugă la monitorizare.
Această abordare se potrivește bine cu structura Kubernetes, unde totul plutește: astăzi sunt 10 servere, mâine sunt 3. Pentru a nu indica de fiecare dată adresa IP a serverului, am scris odată cum să o găsim - și Discovering o va face. .
Se numește limbajul Prometeu PromQL. Folosind acest limbaj, puteți obține valorile unor metrici specifice și apoi le puteți transforma și construi calcule analitice pe baza acestora.
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)Interfață web Prometheus
Prometheus are propria sa interfață web, destul de minimalistă. Potrivit doar pentru depanare sau demonstrație.
Puteți scrie o interogare în PromQL în linia Expression.
Fila Alerte conține reguli de alertă și au trei stări:
- inactiv - dacă alerta nu este activă în acest moment, adică totul este în regulă și nu a funcționat;
- în așteptare - aceasta este dacă alerta a fost declanșată, dar trimiterea nu a avut loc încă. Întârzierea este setată pentru a compensa clipirea rețelei: dacă serviciul specificat a crescut într-un minut, atunci nu este nevoie să sune alarma încă;
- tragere este a treia stare, când alerta se aprinde și trimite mesaje.
În meniul Stare veți găsi acces la informații despre ce este Prometheus. Există și o tranziție către obiectivele despre care am vorbit mai sus.
Pentru o prezentare mai detaliată a interfeței Prometheus, consultați .
Integrare cu Grafana
În interfața web Prometheus nu veți găsi grafice frumoase și de înțeles din care să puteți trage concluzii despre starea clusterului. Pentru a le construi, Prometheus se integrează cu Grafana. Acestea sunt tablourile de bord pe care le primim.
Configurarea integrării Prometheus și Grafana nu este deloc dificilă; instrucțiunile pot fi găsite în documentație: , ei bine, voi termina cu asta.
În următoarele articole vom continua subiectul monitorizării: vom vorbi despre colectarea și analiza logurilor folosind Grafana Loki și instrumente alternative.
Autor: Marcel Ibraev, administrator certificat Kubernetes, inginer practicant în companie , vorbitor și dezvoltator de cursuri Slurm.
Sursa: www.habr.com