ABONAMENTE VIDEO TESTE REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 79
Abonament PDF

Prometheus – sau cum să scalezi sistemul de monitoring când ai peste 1000 de servere

Marius Mitrofan
Senior IT Consultant & Founder @ NETBEARS
PROGRAMARE

În acest articol, vom analiza problemele care apar într-un sistem de monitorizare și de alerte, în momentul în care infrastructura dumneavoastră crește considerabil de mult.Resursele pentru acest tutorial sunt postate pe contul nostru de GitHub și conțin tot ceea ce aveți nevoie pentru a putea pune în funcțiune acest mecanism.

Ce este Prometheus?

Prometheus este un instrument de monitorizare și alertare open-source inițial construit la SoundCloud. 

De la înființarea sa în 2012, multe companii și organizații au adoptat Prometheus, iar proiectul are o comunitate de dezvoltatori și utilizatori foarte activi. Acesta este și va fi tot timpul un proiect open-source independent și menținut independent de orice companie. 

Pentru a sublinia acest lucru și pentru a clarifica structura de guvernanță a proiectului, Prometheus s-a alăturat Fundației Cloud Native Computing în 2016 ca al doilea proiect găzduit, după Kubernetes. 

Ce oferă în plus Prometheus?

La fel ca și cei de la SoundCloud, compania dumneavoastră a migrat deja sau se gândește să migreze către o arhitectură de microservicii. Așa că, în curând, dacă nu deja, veți avea o sumedenie de servicii, care vor rula pe sute/mii de instanțe, în care vor exista cel mai probabil și mai multe containere Docker. 

Încercând să monitorizați aceste microservicii cu o infrastructură clasică de monitorizare, bazată pe StatsD sau Graphite, veți întâmpina o serie mare de limitări.

Astfel, Prometheus vine în ajutor cu:

Cum arată Prometheus?

Pentru lansarea unei versiuni de Prometheus folosind AWS CloudFormation, trebuie să parcurgem pașii :

Linkurile de mai sus vă trimit către repository-urile noastre GitHub ce conțin resursele necesare pentru crearea unui stack folosind AWS CloudFormation în infrastructura dumneavoastră.

Resursele create aici sunt:

Dacă totul a mers bine, prima dată când veți deschide linkul generat în browser, veți întâmpina o imagine asemenea celei de mai jos:

Acum vom trece prin fiecare din feature-urile aplicației.

Alerte

Tabul de alertare vă va afișa toate alertele care au fost definite pentru această aplicație.

Alertele în sine nu reprezintă nimic altceva decât reguli simple care declanșează un eveniment când este îndeplinită o anumită condiție -> De exemplu, pragul dumneavoastră critic este depășit de orice valoare specifică.

Pentru a modifica, adăuga sau elimina aceste ținte, va trebui să editați fișierul de configurare Reguli de Alertă și să actualizați stackul.

Grafice și metrici

Metricile constituie logica centrală a lui Prometheus, iar colectarea, stocarea și afișarea acestora sunt lucrurile care determină puterea acestei aplicații.

Pentru a le prelua, Prometheus utilizează un mecanism de "scraping", care, pentru o listă de instanțe predefinite, interoghează un punct final HTTP pentru a prelua date granulare pe care le stochează apoi în baza de date temporară.

Ca un simplu instrument de vizualizare, această secțiune specifică "Graph" este construită pentru a afișa un grafic de date folosind baza de date de tip "timeseries".

Logica de "query" din spatele ei, este foarte puternică și permite numeroase moduri de filtrare și de agregare a unor seturi specifice de date.

Instanțele țintă

Țintele, așa cum spune și numele în sine, sunt o listă a punctelor finale pe care utilizatorul (dumneavoastră) le-a definit a fi monitorizate.

Pentru a modifica, adăuga sau elimina aceste ținte, va trebui să editați fișierul de configurare Prometheus și să actualizați stackul.

După ce sunteți mulțumit de cantitatea de ținte adăugată, veți observa că la un anumit interval de timp (implicit 60 de secunde), Prometheus va face "scraping" pe toate țintele și va prelua orice informații noi pe care exportatorul ce rulează pe acele ținte le oferă.

Cum primim alertele atunci?

"Minunat, dar cum pot seta canalele receptoare pentru aceste alerte?" - foarte bună intrebare!

Mecanismul efectiv de trimitere / primire în spatele alertelor nu face parte din stivele Prometheus, ci al lui Alertmanager, care este un software construit de aceeași organizație.

Alertmanager

Alertmanager gestionează alertele trimise de aplicațiile client, cum ar fi serverul Prometheus. Se ocupă de deduplicarea, gruparea și direcționarea acestora către unul din receptorii acceptați, cum ar fi e-mail, PagerDuty sau OpsGenie. De asemenea, are grijă de oprirea și de inhibarea alertelor.

Principalele caracteristici ale Alertmanager sunt:

Cum arată Alertmanager?

În lansarea unei versiuni de Alertmanager folosind AWS CloudFormation, pașii de parcurs sunt:

• Intrați în consola AWS la secțiunea CloudFormation;

• Selectați fișierul cloudformation-template.yaml;

• Modificați calea către fișierele de configurare folosind un bucket S3 pre-creat și fișierele din folderul samples/static 

• Accesați linkul generat din tabul Output.

Servere - ce s-a schimbat?

Nu veți observa nimic neobișnuit, cu excepția cazului în care o alertă va fi semnalată ! Mecanismul real de trimitere / primire în spatele alertelor este definit printr-un fișier de configurare similar celui furnizat în directorul de mostre. Verificați definiția statics/alertmanager.yaml ca referință.

În acesta, o listă de receptoare și canale poate fi definită pe baza oricărui mecanism de grupare pe care doriți să-l activați, cum ar fi numele microserviciului, mediul, tipul de metric etc. .

Cum poate scala acest lucru raportat la mai multe echipe?

Întrebare minunată. Să ne gândim la acesta pentru o secundă ...

Deși Prometheus este perfect capabil să verifice și să analizeze numeroase metrici, nu este într-adevăr posibil din punct de vedere al DevOps să se ocupe continuu de o listă de definiții de servere statice, nu?

Și dând la o parte serverele, ce facem atunci când mai multe echipe doresc metode diferite de primire a alertelor pe baza urgenței metricelor și a canalelor specifice pe care le utilizează?

De altfel, chiar ne dorim să ne petrecem timpul în întreținerea tuturor acestor lucruri?

Răspunsul este desigur -> Categoric NU!

Pentru a aborda această problemă specifică, folosim un mecanism de descoperire a serviciului pentru preluarea de noi ținte și de stocare a datelor de configurare specific echipelor noastre folosind un system "key-value".

Dacă nu ați făcut-o deja, acum este timpul să lansați un cluster Consul cu metoda despre care am vorbit într-un articol anterior de pe site-ul netbears.com (Consul - Launch, Backup and Restore a cluster in AWS).

Prometheus configurat dinamic

Servere - ce s-a schimbat?

Ar trebui să vedeți acum un număr mai mare de ținte, cu mult mai multe etichete. Cea mai bună parte a acestui lucru este că acum, nu numai trebuie să vă asigurați că fișierul de configurare este actualizat manual de fiecare dată când un server este lansat sau terminat.

Alerte - ce s-a schimbat?

Veți observa că acum alertele s-au multiplicat și sunt configurate folosind valorile CUSTOM și DEFAULT pentru fiecare microserviciu în parte.

Ar fi trebuit să fi fost adăugată o configurație cheie-cheie pe serverul dumneavoastră Consul, dar suntem destul de siguri că puteți să vă ocupați singuri de acest lucru, nu-i așa?

Și acum, să îl facem să arate frumos!

După ce ați spus și ați făcut toate aceste lucruri și după ce ați navigat în jurul diferitelor valori disponibile și în care v-ați jucat cu toți operatorii/filtrele, veți începe să vă plictisiți de interfața grafică cu aspect antic pe care o oferă Prometheus.

Nu vă faceți griji! Grafana ne poate salva.

Pentru aceia dintre voi care nu sunt foarte familiarizați cu acest software, Grafana vă permite să interogați, să vizualizați și să înțelegeți valorile metricelor indiferent de locul în care sunt stocate.

Tot ceea ce trebuie să faceți pentru a vă integra soluția de Prometheus este să adăugați URL-ul generat ca sursă de date în Grafana și apoi să începeți să construiți tablouri de bord.

Dacă nu vă pricepeți la design (ca și noi, de altfel), trebuie doar să verificați Marketplace-ul pentru ceva ce vă place și care funcționează bine.

În final, ar trebui să puteți genera o asemenea imagine:

Resurse folosite

Așa cum am promis, resursele folosite în acest tutorial pot fi găsite pe contul nostru de Github:

LANSAREA NUMĂRULUI 80, CLUJ

Prezentări articole și
Panel: IT-ului clujean – oportunitate și viziune

Marți, 19 Februarie, ora 18:00
NTT DATA Romania

Înregistrează-te

Facebook Meetup

Sponsori

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MicroFocus
  • Colors in projects