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: – Prometheus aktywnie wysyła zapytania do usług w celu uzyskania danych o ich metrykach. Model pull – usługi przesyłają swoje metryki do pośrednika, który następnie zbiera je za pomocą Prometheusa. Model push (Pushgateway) Omówmy je szczegółowo. Modelowanie typu pull W Prometheus metryki z Twojej aplikacji za pośrednictwem protokołu HTTP (np. ). modelu pull aktywnie pobiera 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 (np. zliczanie żądań HTTP): Zdefiniuj swoje metryki 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", }) punkt końcowy : Udostępnij /metrics import ( "net/http" "github.com/prometheus/client_golang/prometheus/promhttp" ) func main() { http.Handle("/metrics", promhttp.Handler()) } w : Skonfiguruj Prometheusa do zbierania danych metrycznych z Twojej usługi prometheus.yml scrape_configs: - job_name: "example_service" static_configs: - targets: ["localhost:8080"] Teraz Prometheus będzie automatycznie wysyłał zapytanie co kilka sekund w celu zebrania danych. http://localhost:8080/metrics Dlaczego preferowany jest model Pull? – Prometheus kontroluje harmonogram i częstotliwość scrapowania. Prostota – nie ma potrzeby korzystania z dodatkowej usługi w celu otrzymywania danych pomiarowych. Mniej punktów awarii – jeśli usługa przestaje odpowiadać, Prometheus po prostu przestaje odbierać dane, unikając w ten sposób nieaktualnych metryk. Automatyczne czyszczenie Model Push (podejście Pushgateway) W usługa swoje metryki do usługi pośredniczącej o nazwie , która przechowuje je do momentu ich pobrania przez Prometheusa. modelu push wysyła Pushgateway Jak to działa (model push) Twoja aplikacja do Pushgateway: przesyła metryki 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 przydatny? naprawdę które kończą się, zanim Prometheus zdąży je przechwycić. Zadania krótkotrwałe (zadania wsadowe, zadania cron), uniemożliwiające Prometheusowi bezpośredni dostęp do usługi. Ograniczenia sieciowe (urządzenia IoT, zewnętrzne interfejsy API), których nie można pozyskać bezpośrednio. Zewnętrzne źródła danych 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 rozwiązuje niektóre problemy (np. krótkotrwałe procesy, które kończą się, zanim Prometheus je zbierze), : Pushgateway 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ą lub skonfigurować zasady wygasania. push.Delete(...) Dodatkowa złożoność Zamiast bezpośredniego łącza , masz teraz . Service → Prometheus łą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 — jest prosty, wydajny i zapewnia świeże dane bez dodatkowej złożoności. Jednak jeśli pracujesz z , takimi jak funkcje Lambda lub zadania wsadowe, za pośrednictwem Pushgateway może być przydatny do przechwytywania metryk przed zakończeniem procesu. model pull procesami krótkotrwałymi model push Wybór odpowiedniego podejścia gwarantuje lepszą obserwację i łatwość utrzymania systemu. Dbać o siebie!