OpenTelemetry și Prometheus răspund unor nevoi de observabilitate conexe, dar diferite. Alegerea potrivită depinde de faptul dacă echipa dvs. are nevoie de colectare de date de telemetrie, metrici, trasee sau o combinație a acestor capacități. În multe arhitecturi moderne, decizia practică nu este legată de alegerea unui instrument anume, ci de locul în care se potrivesc OpenTelemetry și Prometheus și dacă acestea ar trebui utilizate împreună.
Cuprins
Ce roluri au OpenTelemetry și Prometheus?
OpenTelemetry este cel mai bine înțeles în contextul colectării datelor de telemetrie și al trasării. Acesta ajută la definirea modului în care datele de observabilitate sunt colectate și transmise printr-o arhitectură care poate include mai multe back-end-uri de monitorizare.
Prometheus este cel mai bine înțeles în contextul metricilor. Acesta este evaluat de obicei ca parte a unei arhitecturi de metrici care include exportatori, stocare, alerte și vizualizare. Aceste roluri se suprapun, dar nu sunt identice. Considerarea instrumentelor ca fiind interschimbabile poate complica planificarea arhitecturii.
Cum se integrează acestea într-o arhitectură de metrici și urme?
O arhitectură de metrici și urme are mai multe responsabilități. Ea trebuie să colecteze date de telemetrie, să furnizeze metrici și urme utilizabile, să stocheze aceste date, să declanșeze alerte și să conecteze rezultatele la platforme de vizualizare sau de monitorizare în cloud.
OpenTelemetry se potrivește stratului de colectare și traseului de urmărire. Prometheus se potrivește traseului de metrici. Prin urmare, o echipă poate utiliza OpenTelemetry pentru colectarea datelor de telemetrie și a traseelor, în timp ce folosește Prometheus pentru metrici, alerte și părțile din stiva de monitorizare construite în jurul datelor Prometheus.
Această abordare combinată este utilă atunci când un sistem are nevoie atât de trasee ale aplicațiilor, cât și de un flux de lucru dedicat metricilor. De asemenea, separă colectarea de alegerea platformei de stocare sau de monitorizare, ceea ce poate fi de ajutor atunci când o organizație lucrează cu mai mulți furnizori.
Ce ar trebui să compare echipele înainte de a alege?
| Domeniu | OpenTelemetry | Prometheus |
|---|---|---|
| Rol principal | Colectarea datelor de telemetrie și trasarea | Metrici |
| Poziția în arhitectură | Colectarea și fluxul de telemetrie | Metrici, stocare și fluxul de lucru pentru alerte |
| Exportatori | Important atunci când telemetria trebuie trimisă către diferite back-end-uri | Important atunci când metricile trebuie colectate de la sisteme care le expun prin intermediul exportatorilor |
| Vizualizare | De obicei conectat la o platformă de monitorizare sau vizualizare | Poate fi conectată la Grafana și la alte platforme de monitorizare |
| Cea mai potrivită opțiune | Echipe care standardizează colectarea datelor de telemetrie la nivelul tuturor furnizorilor | Echipe care se concentrează pe un flux de lucru bazat pe Prometheus pentru metrici și alerte |
Ce opțiune se potrivește unei echipe mici?
O echipă mică ar trebui să evite operarea a două sisteme separate, cu excepția cazului în care are nevoie atât de metrici, cât și de trasee. Dacă cerința imediată este un flux de lucru concentrat pe metrici și alerte, Prometheus poate fi soluția cea mai potrivită. Dacă echipa are nevoie de o abordare comună de colectare a datelor de telemetrie și intenționează să conecteze diferite back-end-uri de monitorizare, OpenTelemetry poate fi un punct de plecare mai bun.
Atunci când sunt necesare atât metricile, cât și trasările, utilizarea combinată a OpenTelemetry și Prometheus poate asigura o separare mai clară între operațiunile de colectare și cele legate de metrici. Echipa ar trebui să definească ce sistem colectează datele, unde sunt stocate acestea, cum sunt create alertele și cum vizualizează inginerii rezultatele.
Care opțiune se potrivește mediilor Kubernetes?
Mediile Kubernetes conțin adesea numeroase servicii și surse de telemetrie. Prin urmare, alegerea ar trebui să se concentreze pe cât de consecvent poate echipa să colecteze date de telemetrie, să expună metricile, să gestioneze exportatorii, să stocheze datele și să conecteze alertele la fluxul de lucru de monitorizare al echipei.
Prometheus este o componentă adecvată a arhitecturii atunci când metricile și alertele Kubernetes reprezintă cerința principală. OpenTelemetry devine important atunci când mediul necesită, de asemenea, trasări (traces) sau un strat de colectare consistent la nivelul serviciilor și al platformelor de monitorizare. Utilizarea ambelor este adecvată atunci când mediul are nevoie de aceste responsabilități în același timp.
Care opțiune se potrivește organizațiilor care standardizează între furnizori?
Organizațiile care utilizează mai mulți furnizori ar trebui să evalueze cât de ușor se poate transfera telemetria între platformele de colectare, stocare, vizualizare și monitorizare în cloud. OpenTelemetry reprezintă soluția arhitecturală mai potrivită atunci când standardizarea colectării și a traseului de urmărire reprezintă prioritatea. Prometheus rămâne util pentru metrice și traseul de alertare.
Decizia finală ar trebui să se bazeze pe semnalele de observabilitate necesare și pe arhitectura dorită, nu pe presupunerea că un instrument trebuie să îl înlocuiască pe celălalt. OpenTelemetry este alegerea mai bună pentru colectare și trasee, Prometheus este alegerea mai bună pentru metrici, iar ambele sunt adecvate atunci când platforma are nevoie de un flux de lucru complet de metrici și trasee.