Integracja Prometheus i Grafana, która wychwytuje problemy
Opublikowano 6 października 2026 r
Integracja Prometheus i Grafana pozwala wykorzystać metryki serwera do konkretnych celów: pokazywania zmian, ostrzegania przed awarią, zanim zostanie przekroczony limit, oraz dostarczania dowodów, gdy usługa działa wolno. Prometheus zbiera i przechowuje dane liczbowe. Grafana przekształca je w pulpity nawigacyjne i alerty, które zespół może zrozumieć na pierwszy rzut oka. Razem zastępują zgadywanie spokojniejszym obrazem sytuacji operacyjnej.
W przypadku VPS-a, serwera dedykowanego, platformy SaaS czy popularnego sklepu internetowego taka konfiguracja jest najbardziej przydatna, zanim coś ulegnie awarii. Zapełniony dysk, wyczerpana pamięć, wydłużający się czas odpowiedzi czy pula połączeń z bazą danych zbliżająca się do limitu zwykle najpierw dają o sobie znać w metrykach. Usługa może nadal działać, ale wykres już opowiada dalszy ciąg historii.
Za co odpowiadają Prometheus i Grafana
Prometheus to system monitorowania szeregów czasowych. Regularnie pobiera metryki z monitorowanych celów, oznacza te pomiary etykietami i udostępnia je do zapytań. Szczególnie dobrze sprawdza się w monitorowaniu serwerów i aplikacji, ponieważ metryki takie jak użycie procesora, obciążenie pamięci, liczba żądań, opóźnienia i pojemność systemu plików naturalnie pasują do jego modelu.
Grafana odpowiada za wizualizację i alerty. Łączy się z Prometheus jako źródłem danych, umożliwia tworzenie paneli na podstawie zapytań PromQL i porządkuje je w pulpity nawigacyjne. Dobry pulpit nawigacyjny Grafana nie musi być ozdobny. Jego zadaniem jest szybkie udzielanie odpowiedzi na praktyczne pytania: Czy serwer działa prawidłowo? Która usługa zużywa zasoby? Czy wydajność się pogarsza? Czy wdrożenie o 14:00 coś zmieniło?
Prometheus może samodzielnie oceniać reguły alertów, a Alertmanager obsługuje grupowanie, kierowanie i wyciszanie powiadomień. Grafana może również tworzyć alerty na podstawie zapytań z pulpitów nawigacyjnych. Oba podejścia mogą się sprawdzić. W przypadku alertów obejmujących całą infrastrukturę i zarządzanych za pomocą kodu łatwiej jest często ustandaryzować reguły Prometheus wraz z Alertmanager. W przypadku pulpitu nawigacyjnego dla konkretnej usługi wygodne mogą być alerty zarządzane przez Grafana. Unikaj uruchamiania obu rozwiązań dla dokładnie tego samego warunku, chyba że chodzi o duplikaty alertów o 3 nad ranem. są częścią planu.
Integracja Prometheus i Grafana: praktyczna architektura
Rozsądna architektura początkowa jest niewielka. Uruchom Prometheus i Grafana na VPS-ie monitorującym, w miarę możliwości oddzielonym od obserwowanego serwera lub aplikacji. Zainstaluj eksportery w monitorowanych systemach. Eksportery udostępniają metryki za pośrednictwem punktu końcowego HTTP, a Prometheus pobiera je zgodnie z harmonogramem.
W przypadku serwerów z systemem Linux najczęściej na początek wybiera się Node Exporter. Udostępnia on pomiary na poziomie hosta, w tym dane o procesorze, pamięci, średnim obciążeniu, użyciu dysku, ruchu sieciowym i statystykach systemu plików. Eksportery baz danych mogą zapewnić wgląd w działanie MySQL, PostgreSQL, Redis i innych usług. Metryki aplikacji mogą pochodzić z natywnego punktu końcowego Prometheus, biblioteki dla danego środowiska lub starannie dobranego eksportera.
Podstawowy przepływ danych jest prosty:
- Eksporter udostępnia metryki serwera, bazy danych lub aplikacji.
- Prometheus pobiera dane z punktu końcowego i przechowuje je jako szeregi czasowe.
- Grafana wysyła zapytania do Prometheus i wyświetla wyniki.
- Reguły alertów oceniają progi lub nietypowe zachowania i wysyłają powiadomienia wybranym kanałem.
Prosty schemat ma znaczenie, bo dzięki niemu rozwiązywanie problemów również jest proste. Jeśli panel Grafana jest pusty, sprawdź, czy Grafana może wysyłać zapytania do Prometheus. Jeśli Prometheus nie ma danych, sprawdź stronę celów i punkt końcowy eksportera. Jeśli cel jest niedostępny, sprawdź dostęp do sieci, reguły zapory, stan usługi i konfigurację eksportera. Dzienniki zwykle opowiadają teraz tę samą historię.
Zacznij od metryk, które pomagają podjąć działanie
Zbieranie wszystkich dostępnych metryk powoduje nadmiar informacji, zajmuje miejsce i prowadzi do powstawania pulpitów nawigacyjnych, których nikt nie otwiera. Zacznij od metryk, które wspierają konkretne decyzje operacyjne. W przypadku większości serwerów oznacza to monitorowanie wykorzystania procesora i obciążenia, dostępnej pamięci, aktywności pamięci wymiany, miejsca na dysku i użycia i-węzłów, opóźnień operacji wejścia/wyjścia dysku, błędów sieci, dostępności procesów oraz czasu nieprzerwanej pracy systemu.
W przypadku aplikacji internetowych dodaj liczbę żądań HTTP, współczynnik błędów, czas trwania żądań, liczbę aktywnych połączeń i głębokość kolejki, jeśli ma to zastosowanie. W przypadku baz danych monitoruj liczbę połączeń, wolne zapytania, stan replikacji, wydajność pamięci podręcznej, blokady i przyrost danych. Sklep internetowy może przywiązywać dużą wagę do błędów realizacji zakupów i opóźnień bazy danych, a agencja programistyczna może priorytetowo traktować dostępność środowisk klientów i powodzenie kopii zapasowych. Wszystko zależy od obciążenia, a nie od tego, który pulpit nawigacyjny wygląda najbardziej imponująco.
Używaj etykiet rozważnie. Etykiety umożliwiają filtrowanie według środowiska, roli serwera, klienta, regionu lub aplikacji. Mogą również powodować powstawanie dużej liczby odrębnych szeregów czasowych, jeśli zawierają stale zmieniające się wartości, takie jak identyfikatory użytkowników, identyfikatory zamówień, tokeny sesji czy ścieżki żądań z dynamicznymi parametrami. Etykiety o dużej kardynalności to łatwy sposób, by niepotrzebnie znacznie zwiększyć obciążenie Prometheus.
Skonfiguruj zbieranie danych bez wprowadzania nowych zagrożeń
Prometheus potrzebuje listy celów w swojej konfiguracji. Podstawowy cel Node Exporter może wyglądać tak:
``\`yaml scrape_configs:
- job_name: node
static_configs:
- targets: ['10.0.0.15:9100']
labels: environment: production role: web ``\`
W niewielkim środowisku statyczne cele są przejrzyste i niezawodne. Wraz z rozwojem infrastruktury lepiej sprawdza się zwykle wykrywanie usług, ponieważ cele są dodawane i usuwane automatycznie. Niezależnie od wybranej metody, w miarę możliwości nie udostępniaj publicznie punktów końcowych monitorowania. Nie udostępniaj szeroko portów eksporterów w publicznym internecie tylko dlatego, że pulpit nawigacyjny potrzebuje danych.
W razie potrzeby korzystaj z sieci prywatnej, list dozwolonych w zaporze, VPN-u lub serwera proxy pośredniczącego z uwierzytelnianiem. Szyfruj ruch, gdy metryki przesyłane są przez niezaufane sieci. Metryki Prometheus mogą ujawniać nazwy hostów i usług wewnętrznych, wzorce obciążenia oraz informacje o wersjach. To dane operacyjne, a nie publiczna ozdoba.
Ustal okres przechowywania danych zgodnie z potrzebami związanymi z obsługą incydentów i planowaniem pojemności. Piętnaście do trzydziestu dni wystarczy w przypadku wielu niewielkich instalacji, aby wykrywać niedawne zmiany i krótkoterminowe trendy. Dłuższy okres przechowywania pomaga analizować sezonowe zapotrzebowanie i stopniowy wzrost wymagań dotyczących pojemności, ale zwiększa zapotrzebowanie na miejsce na dysku. Do długoterminowego raportowania historycznego rozważ użycie zdalnego magazynu danych zamiast bezterminowego przechowywania danych na tym samym VPS-ie, na którym działa Grafana.
Twórz pulpity nawigacyjne ułatwiające szybką diagnozę
Najpierw utwórz jeden pulpit nawigacyjny z ogólnym przeglądem. Powinien pokazywać stan najważniejszych systemów, a nie wszystkie metryki z katalogu. Przydatny przegląd często obejmuje dostępność serwera, użycie procesora i pamięci, wykorzystanie dysku, ruch sieciowy, współczynnik błędów HTTP i opóźnienie żądań. Używaj zmiennych dla hosta, środowiska i usługi, aby jeden pulpit nawigacyjny obsługiwał kilka systemów bez przekształcania się w muzeum kopii i wklejania.
Następnie utwórz pulpity nawigacyjne dla poszczególnych usług. Pulpit nawigacyjny bazy danych wymaga innych paneli niż pulpit nawigacyjny serwera WWW. Pulpit nawigacyjny dla procesu działającego w tle powinien pokazywać głębokość kolejki, czas przetwarzania, ponowienia prób i błędy. Tytuły paneli powinny być konkretne: „Wolne miejsce na /var”, „Współczynnik błędów HTTP 5xx” i „Aktywne połączenia PostgreSQL” są lepsze niż pomysłowe nazwy, które w najmniej odpowiednim momencie wymagają tłumaczenia.
Warto dodawać adnotacje dotyczące wdrożeń, okien konserwacyjnych i zmian konfiguracji. Gdy opóźnienia rosną krótko po wydaniu nowej wersji, adnotacja zmienia podejrzany wykres w przydatny punkt wyjścia do rozmowy. Nie dowodzi związku przyczynowego, ale stanowi rozsądny punkt wyjścia do analizy.
Ustawiaj alerty dotyczące objawów, a nie każdej liczby
Alert o użyciu procesora na poziomie 80% może być przydatny w przypadku jednego serwera, a w przypadku innego nie mieć znaczenia. Węzeł przetwarzający partie danych może z założenia pracować z dużym obciążeniem przez wiele godzin, podczas gdy nagły wzrost opóźnień API może natychmiast wpłynąć na klientów, nawet przy umiarkowanym użyciu procesora. Reguły alertów powinny uwzględniać wpływ na działanie systemu i jego oczekiwane zachowanie.
Zacznij od alertów dotyczących sytuacji wymagających reakcji: eksporter lub usługa jest nieosiągalna, wkrótce zabraknie miejsca na dysku, zadania tworzenia kopii zapasowych kończą się niepowodzeniem, presja na pamięć powoduje użycie pamięci wymiany, rośnie liczba błędów, zbliża się wygaśnięcie certyfikatów lub replikacja bazy danych nie działa prawidłowo. Ustaw czas trwania warunku, aby krótkotrwałe skoki niepotrzebnie nikogo nie budziły. Na przykład utrzymujący się przez piętnaście minut niski poziom wolnego miejsca na dysku jest zazwyczaj bardziej miarodajny niż pięciosekundowy spadek.
Każdy alert powinien odpowiadać na trzy pytania: co jest nie tak, gdzie występuje problem i co osoba reagująca powinna sprawdzić w pierwszej kolejności? W adnotacji alertu umieść nazwę serwera, środowisko, usługę i krótką instrukcję z podręcznika procedur. Samo „Mało miejsca na dysku” nie wystarczy, gdy serwerów jest dwadzieścia, a ktoś czyta wiadomość na telefonie.
Wyciszenia i okna konserwacyjne są częścią prawidłowego systemu alertów, a nie sposobem na ukrywanie problemów. Korzystaj z nich podczas zaplanowanych prac, a po ich zakończeniu je usuń. Zapomniane wyciszenie ma fatalne wyczucie czasu.
Dbaj o łatwość utrzymania stosu monitorowania
Traktuj pulpity nawigacyjne, reguły alertów i konfigurację Prometheus jako zasoby operacyjne. Twórz ich kopie zapasowe, analizuj je po incydentach i przechowuj konfigurację w systemie kontroli wersji, jeśli zespół może robić to bezpiecznie. Od czasu do czasu testuj alerty. Kanał powiadomień, który nigdy nie został przetestowany, jest tylko optymistycznym przypuszczeniem.
Monitoruj również sam system monitorowania. Prometheus potrzebuje wystarczającej ilości pamięci i miejsca na dane, Grafana wymaga kopii zapasowych konfiguracji i bazy danych, a eksportery muszą pozostać osiągalne po zmianach zapory lub sieci. Monitoruj czas pobierania danych, nieudane pobrania, pojemność magazynu danych i błędy dostarczania alertów. Jeśli serwer monitorujący jest przeciążony, wykresy mogą wyglądać spokojnie, mimo że system po cichu nie rejestruje potrzebnych dowodów.
Zespołom, które oprócz infrastruktury potrzebują wsparcia operacyjnego, kodu.cloud może pomóc w obsłudze monitorowanych środowisk VPS i serwerów, zapewniając jednocześnie wgląd w metryki istotne dla ich działalności. Celem nie jest uczynienie monitorowania tajemniczym. Chodzi o to, by kolejny problem był mniejszy, został wcześniej wykryty i łatwiej było sobie z nim poradzić.
Dobrze dostrojona konfiguracja Prometheus i Grafana nie eliminuje incydentów. Zapewnia zespołowi wcześniejsze ostrzeżenia, jaśniejszy kontekst i mniej decyzji podejmowanych po omacku, gdy pojawi się incydent. Zacznij od jednego serwera, jednego pulpitu nawigacyjnego i krótkiej listy alertów, na które ludzie rzeczywiście będą reagować. Dzięki temu działanie usługi znów staje się spokojne.
Andres Saar, inżynier ds. obsługi klienta