Początkowo wpis miał być zwykłym tutorialem co to Prometheus, jak z niego korzystać jednak po dłuższej chwili stwierdziłem że lepiej podejść od innej strony. Chciałbym Ci w tym wpisie wytłumaczyć na prostym przykładzie jak monitorować w sposób zautomatyzowany infrastrukturę.
Cały kod możesz znaleźć [TUTAJ].
Co to jest Prometheus
Jest to zestaw narzędzi do zbierania metryk oraz ich monitorowania. Sam monitoring polega na powiadamianiu deweloperów lub zespół odpowiedzialny za infrastrukturę w razie wystąpienia jakichkolwiek problemów. Przykładami takich problemów może być brak połączeń do bazy danych lub brak żądań do Nginxa.
Prometheus został głównie stworzony do zbierania metryk z infrastruktury itp. a nie eventów generowanych przez użytkownika m.in. wejścia na formularz czy zalogowania się do aplikacji. W przypadku gdy chcesz zbierać takie eventy zdecydowanie lepiej się sprawdzi InfluxDB.
Jeżeli nie pracowałeś z bazami typu InfluxDB najpewniej sobie zadajesz pytanie czym są metryki. Najprościej ujmując metryki to jakieś pomiary lub jeszcze inaczej to zwykłe szeregi czasowe. W życiu rzeczywistymi metrykami możemy nazwać ilość samochodów które przejechały przez ulicę Świętokrzyską w ciągu 5 minut. Dla twojej infrastruktury mogą to być średnie czasy żądań do aplikacji, średnie czasy wysyłki requestu do ERP, liczba aktywnych połączeń do bazy danych lub liczba aktywnych konsumerów. To wszystko zależy od tego co udostępnia źródło danych. W przypadku zwykłego nginxa będzie to bardzo mało danych. Jeżeli pokusisz się o wersje PLUS tych metryk możesz zbierać od groma.
W czym Prometheus pomaga
Takie szeregi czasowe pozwalają nam stwierdzać na faktach że np. funkcjonalność X działa za wolno lub aplikacja firmy trzeciej powiedzmy jakiś ERP odpowiada za długo na żądania. Zapewne gdy pracowałeś na service desk spotkałeś się ze zgłoszeniem że coś „wolno działa”. Takie subiektywne odczucia niestety powodują nieprzyjemne sytuacje. Dopóki na jakiś danych nie oprzemy odpowiedzi do osoby zgłaszając nie rozwiążemy zgłoszenia . Dzięki metrykom takim jak średni czas żądania itp. możemy zdiagnozować czy problem leży po stronie naszego dostawcy infrastruktury, sieci, aplikacji firmy trzeciej, złej konfiguracji… Można tutaj by wymieniać w nieskończoność a może to tylko złe odczucie osoby która dokonała zgłoszenia.
Poza samym wsparciem podczas pracy na service desku zyskujesz możliwość poszukiwania miejsca gdzie trzeba dokonać optymalizacji. Niestety ale najczęściej nikt nie ma czasu przyjrzeć się każdej funkcjonalności z osobna i szukać gdzie coś można zoptymalizować. Często takie dane przydadzą nam się podczas negocjacji z biznesem. Jeżeli przedstawimy że poświęcenie 1 lub 2 godzin miesięcznie na przejrzenie naszych metryk może przyciągnąć jeszcze większą liczbę użytkowników i do tego google lepiej będzie nas lepiej indeksowało na pewno spowoduje dużo lepsze przyjęcie niż „dajcie nam pogrzebać w metrykach”.
Uruchommy Prometheusa
Na poniższym przykładzie zobaczysz jak zbierać dane z Nginxa. Zapewne oczekiwałeś tutaj większej ilości integracji. Na szczęście ilość oferowanych integracji jest tak duża że ten wpis byłby o wszystkim i o niczym. Stąd decyzja o wybraniu tylko Nginxa. Wszystkie integracje Prometheusa a dokładniej exportery danych możesz znaleźć [TUTAJ].
version: '3.7'
services:
nginx:
image: nginx:latest
ports:
- '8000:80'
volumes:
- '.docker/nginx/site.conf:/etc/nginx/conf.d/default.conf'
nginx-exporter:
image: nginx/nginx-prometheus-exporter:latest
ports:
- '9113:9113'
command:
- -nginx.scrape-uri
- http://nginx:8080/stub_status
depends_on:
- prometheus
- nginx
links:
- nginx
- prometheus
prometheus:
image: bitnami/prometheus
ports:
- '9090:9090'
volumes:
- '.docker/prometheus/prometheus.yaml:/etc/prometheus/prometheus.yml'
Jak zapewne zauważyłeś ten docker-compose jest bardzo ubogi. Okroiłem go tylko do przysłowiowego mięsa ucinając część związaną z aplikacją. Poniżej został przedstawiony jest config Prometheusa oraz Nginxa.
global:
scrape_interval: 10s
scrape_configs:
- job_name: "prometheus_master"
scrape_interval: 5s
static_configs:
- targets: ["localhost:9090"]
- job_name: 'nginx_status'
metrics_path: '/metrics'
static_configs:
- targets: ['nginx-exporter:9113']
Sama konfiguracja Prometheusa która widzisz powyżej składa się w większości z definicji miejsca skąd ma zaciągać dane. Nie ma tutaj zbytnio co opowiadać więc pójdziemy dalej. 🙂
server {
listen 80;
server_name localhost;
error_log /var/log/nginx/error.log;
access_log /var/log/nginx/access.log;
root /app/public;
location / {
try_files $uri /index.php$is_args$args;
}
location ~ ^/index\.php(/|$) {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass fpm:9000;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;
internal;
}
location ~ \.php$ {
return 404;
}
}
server {
listen 8080;
server_name localhost;
location /stub_status {
stub_status on;
}
}
Podsumowanie
Sam post jak widzisz był dosyć krótki ale taki miał być. Chciałem Ci przedstawić szybko zwięźle i na temat jak zacząć przygodę z Prometheusem. W następnym wpisie ukarze się konfigurowanie alertów oraz integracja z grafaną. 🙂
Zachęcam Cię również do przeczytania ostatniej serii wpisów, wystarczy że klikniesz [TUTAJ]. 🙂