Czym jest Prometheus i dlaczego go potrzebujesz?
Prometheus to potężny system monitorujący, który zbiera i przetwarza dane liczbowe (metryki) z aplikacji. Pomaga śledzić kluczowe wskaźniki, takie jak:
- Liczba żądań obsłużonych przez Twoją usługę.
- Czas odpowiedzi na każde żądanie.
- Wykorzystanie pamięci i procesora.
- Liczba błędów występujących w systemie.
Korzystając z Prometheusa możesz odpowiedzieć na takie ważne pytania jak:
„Czy moja usługa działa wydajnie?”
„Jakie są wąskie gardła wydajnościowe?”
„Czy musimy zwiększyć skalę naszej infrastruktury?”
A w jaki sposób Prometheus zbiera dane?
Istnieją dwa główne sposoby gromadzenia danych przez Prometheusa:
- Model pull – Prometheus aktywnie wysyła zapytania do usług w celu uzyskania danych o ich metrykach.
- Model push (Pushgateway) – usługi przesyłają swoje metryki do pośrednika, który następnie zbiera je za pomocą Prometheusa.
Omówmy je szczegółowo.
Modelowanie typu pull
W modelu pull Prometheus aktywnie pobiera metryki z Twojej aplikacji za pośrednictwem protokołu HTTP (np. http://your-service:8080/metrics ).
Jest to domyślna i najczęściej stosowana metoda.
Konfigurowanie Prometheusa z Golang (model pull)
Zainstaluj niezbędne biblioteki:
go get github.com/prometheus/client_golang/prometheus go get github.com/prometheus/client_golang/prometheus/promhttp
Zdefiniuj swoje metryki (np. zliczanie żądań HTTP):
import ( "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/promauto" ) var httpRequestsTotal = promauto.NewCounter(prometheus.CounterOpts{ Name: "http_requests_total", Help: "Total number of HTTP requests", })
Udostępnij punkt końcowy
/metrics:import ( "net/http" "github.com/prometheus/client_golang/prometheus/promhttp" ) func main() { http.Handle("/metrics", promhttp.Handler()) }
Skonfiguruj Prometheusa do zbierania danych metrycznych z Twojej usługi w
prometheus.yml:scrape_configs: - job_name: "example_service" static_configs: - targets: ["localhost:8080"]
Teraz Prometheus będzie automatycznie wysyłał zapytanie http://localhost:8080/metrics co kilka sekund w celu zebrania danych.
Dlaczego preferowany jest model Pull?
- Prostota – Prometheus kontroluje harmonogram i częstotliwość scrapowania.
- Mniej punktów awarii – nie ma potrzeby korzystania z dodatkowej usługi w celu otrzymywania danych pomiarowych.
- Automatyczne czyszczenie – jeśli usługa przestaje odpowiadać, Prometheus po prostu przestaje odbierać dane, unikając w ten sposób nieaktualnych metryk.
Model Push (podejście Pushgateway)
W modelu push usługa wysyła swoje metryki do usługi pośredniczącej o nazwie Pushgateway , która przechowuje je do momentu ich pobrania przez Prometheusa.
Jak to działa (model push)
Twoja aplikacja przesyła metryki do Pushgateway:
import ( "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/push" ) func main() { registry := prometheus.NewRegistry() jobCounter := prometheus.NewCounter(prometheus.CounterOpts{ Name: "job_execution_count", Help: "Number of executed jobs", }) registry.MustRegister(jobCounter) jobCounter.Inc() err := push.New("http://localhost:9090", "my_service_or_job"). Collector(jobCounter). Grouping("instance", "worker_1"). Push() if err != nil { panic(err) } }
Skonfiguruj Prometheusa do zbierania danych z Pushgateway:
scrape_configs: - job_name: "pushgateway" static_configs: - targets: ["localhost:9091"]
Kiedy model Push jest naprawdę przydatny?
- Zadania krótkotrwałe (zadania wsadowe, zadania cron), które kończą się, zanim Prometheus zdąży je przechwycić.
- Ograniczenia sieciowe uniemożliwiające Prometheusowi bezpośredni dostęp do usługi.
- Zewnętrzne źródła danych (urządzenia IoT, zewnętrzne interfejsy API), których nie można pozyskać bezpośrednio.
Którego modelu powinieneś użyć?
Metoda | Najlepiej dla... | Zalety | Wady |
|---|---|---|---|
Pociągnij (zalecane) | Usługi sieciowe, API, aplikacje długoterminowe | Prosta konfiguracja, mniej zależności, automatyczne czyszczenie | Nie nadaje się do zadań o bardzo krótkim okresie trwania |
Push (bramka push) | Zadania wsadowe, zadania bez stabilnego dostępu do sieci | Umożliwia przesyłanie danych z krótkotrwałych zadań | Nieaktualne dane, dodatkowa złożoność, ryzyko wąskich gardeł |
Dlaczego model Push nie jest idealny?
Mimo że Pushgateway rozwiązuje niektóre problemy (np. krótkotrwałe procesy, które kończą się, zanim Prometheus je zbierze), wprowadza kilka nowych kwestii :
- Trudności w zarządzaniu nieaktualnymi danymi
Jeśli usługa przestanie działać, jej stare metryki pozostaną w Pushgateway.
Prometheus nie ma możliwości sprawdzenia, czy usługa nadal działa.
Należy ręcznie usunąć nieaktualne metryki za pomocą
push.Delete(...)lub skonfigurować zasady wygasania.
- Dodatkowa złożoność
Zamiast bezpośredniego łącza Service → Prometheus , masz teraz łącze Service → Pushgateway → Prometheus .
Pushgateway wymaga dodatkowych zależności, co zwiększa nakłady na konserwację.
- Potencjalne wąskie gardła
Jeśli wiele usług często przesyła dane, Pushgateway może zostać przeciążony.
W przeciwieństwie do bezpośrednich żądań Prometheusa (które rozkładają obciążenie) wszystkie żądania trafiają do pojedynczej instancji Pushgateway.
- Problemy ze spójnością danych
- Jeśli wiele usług przesyła metryki o tej samej nazwie, ale o różnych wartościach, dane mogą zostać nadpisane, co doprowadzi do nieprawidłowych wyników.
Wniosek
Prometheus to potężne i niezawodne narzędzie do monitorowania usług. W przypadku większości aplikacji najlepszym wyborem jest model pull — jest prosty, wydajny i zapewnia świeże dane bez dodatkowej złożoności. Jednak jeśli pracujesz z procesami krótkotrwałymi , takimi jak funkcje Lambda lub zadania wsadowe, model push za pośrednictwem Pushgateway może być przydatny do przechwytywania metryk przed zakończeniem procesu.
Wybór odpowiedniego podejścia gwarantuje lepszą obserwację i łatwość utrzymania systemu.
Dbać o siebie!
