Î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.
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.
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:
Un model de date multidimensional în care să vă puteți juca cu toate datele adunate la discreție, folosind tot felul de dimensiuni, adnotări și etichete pe care le aveți la îndemână;
Simplitate operațională, întrucât o singură instanță de Prometheus poate stoca și verifica destul de multe puncte de interes, fără a necesita un spațiu de stocare distribuit sau a reinventa roata;
Scalabilitate și descentralizare în colectarea datelor, putând separa instanțe diferite de monitorizat pe instanțe diferite de Prometheus și oferind acces diferit și limitat membrilor echipelor din compania dumneavoastră;
Pentru lansarea unei versiuni de Prometheus folosind AWS CloudFormation, trebuie să parcurgem pașii :
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
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:
1 AutoScaling Group,
1 Elastic Load Balancer,
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.
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.
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.
Ț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ă.
"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 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:
Gruparea: clasifică alertele de natură similară într-o singură notificare. Acest lucru este util în special în cazul unor întreruperi mai mari atunci când multe sisteme eșuează imediat și se pot declanșa simultan sute/mii de alerte;
Caracteristica "Inhibition": este un concept de suprimare a notificărilor pentru anumite alerte, dacă alte alerte sunt deja lansate;
Caracteristica "Silent": Pauzele sunt un mod simplu de a dezactiva alertele pentru o anumită perioadă de timp. Caracteristica de acest gen se configurează bazându-se pe matematici, la fel ca arborele de direcționare. Alertele primite sunt verificate dacă se potrivesc cu toți factorii de egalitate sau de expresie regulată, atunci când este activă. În caz contrar, nu vor fi trimise notificări pentru acea alertă;
Î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.
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. .
Î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).
Pentru a actualiza versiunea de Prometheus lansată anterior folosind template-urile de Consul, traversăm etapele:
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/generated-consul-template
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.
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?
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:
Așa cum am promis, resursele folosite în acest tutorial pot fi găsite pe contul nostru de Github:
de Ovidiu Mățan
de Adrian Cozac
de Ovidiu Mățan
