Tworzenie pulpitów nawigacyjnych Grafana dla infrastruktur hostingowych

Od zbioru wskaźników do jasnej wizji docelowej pulpitu nawigacyjnego

Tablica kontrolna nie zaczyna się od wyboru kolorowych paneli, lecz od pytania operacyjnego: czy zespół musi teraz zareagować na zakłócenia w gromadzeniu danych, niedobór pamięci czy utrzymujące się obciążenie? Grafana przedstawia zapytania do źródeł danych w postaci paneli i może je wizualizować w zależności od stawianego pytania. Interfejs jest zatem narzędziem wspomagającym podejmowanie decyzji, a nie automatycznym odzwierciedleniem stanu usługi.

Najwyższy poziom, na przykład „stan hostingu“, powinien obejmować tylko kilka wskaźników: dostępność z punktu widzenia Prometeusz, obciążenie procesora, dostępna pamięć i ruch sieciowy. Ich celem jest ustalenie priorytetów: który obszar zasługuje na sprawdzenie? Nie wyjaśnia to jeszcze, dlaczego serwer WWW działa wolno ani jaki wolumen danych powoduje ostrzeżenie o przekroczeniu pojemności.

W tym zakresie pomagają Widoki ról dla systemów internetowych, baz danych, pamięci podręcznej, poczty elektronicznej lub wirtualizacji. Podobne instancje można tam porównywać na podstawie wskaźników istotnych dla ich przeznaczenia. Na przykład rola bazy danych wymaga innych szczegółowych wartości niż serwer proxy odwrotny; wspólna strona podsumowująca nie musi ukrywać tych różnic w jednym wskaźniku.

Widok diagnostyczny umożliwia wreszcie przegląd szeregów czasowych dla poszczególnych instancji, przegląd punktów montowania lub urządzeń oraz zdarzeń operacyjnych. Duży pulpit nawigacyjny zawierający wszystkie hosty i usługi utrudnia identyfikację. Pulpity nawigacyjne Grafana mogą łączyć różne wizualizacje i źródła danych; jednak nie każde szczegółowe pytanie powinno znajdować odpowiedź na tej samej stronie.

Dokładne sprawdzenie bazy danych Prometheus i etykiet

Przed rozpoczęciem tworzenia pulpitu nawigacyjnego należy zapewnić dostępność Prometheusa i docelowych eksporterów, a Grafana wymaga skonfigurowanego źródła danych Prometheusa. Prometheus określa w swojej konfiguracji zadania zbierania danych, instancje docelowe oraz pliki reguł, które mają być wczytywane. Zmiany w konfiguracji można wprawdzie ponownie załadować, jednak błędna konfiguracja nie zostanie przy tym przyjęta.

Kluczowe znaczenie ma spójność Struktura etykiet. Wytwórnie job oraz instance określić źródło i miejsce docelowe; dodatkowe etykiety, takie jak environment lub role umożliwiają przejrzyste rozdzielenie środowiska produkcyjnego, testowego i funkcji serwerowych. Bez takich zasad ta sama zmienna może łączyć różne hosty, które choć mają podobne nazwy, mają jednak różne okna serwisowe, zakresy odpowiedzialności lub ograniczenia wydajnościowe.

Punkty końcowe eksportera nie powinny być publicznie dostępne bez kontroli. Metryki mogą ujawniać nazwy hostów, punkty montowania, interfejsy sieciowe lub inne szczegóły dotyczące infrastruktury. Sprawdź również, czy Grafana ma uprawnienia do wysyłania zapytań do Prometheusa oraz czy istniejące szeregi czasowe faktycznie dostarczają dane w przewidzianym okresie; pustego panelu nie da się naprawić nawet za pomocą bardziej atrakcyjnej wizualizacji.

• W Prometheisie lub w sekcji „Explore” należy sprawdzić faktycznie istniejące nazwy metryk, etykiety i wartości etykiet.
• Dla każdego celu należy sprawdzić, czy operacje „scrape” przebiegają obecnie pomyślnie oraz czy oczekiwana instancja jest jednoznacznie zidentyfikowana.
• W przypadku wskaźników dotyczących systemu plików i sieci należy zawęzić zakres punktów montowania lub interfejsów w oparciu o własne środowisko.
• Przykłady pulpitów nawigacyjnych należy przenieść do lokalnej struktury metryk i etykiet dopiero po przeprowadzeniu tej kontroli.

Node Exporter dokumentuje dane zebrane przez moduł Collector, między innymi dotyczące systemu plików, sieci i nośników danych. To, które wiersze pojawiają się podczas działania, zależy jednak od systemu operacyjnego, jądra, kontenerów, punktów montowania oraz włączonych modułów Collector. Plik README gałęzi rozwojowej nie opisuje ponadto automatycznie możliwości już zainstalowanej stabilnej wersji.

W związku z tym sprawdź zainstalowaną wersję programu Node Exporter oraz jej widoczne wskaźniki niezależnie od dokumentacji programistycznej. W momencie przeprowadzania badania wersja Node Exporter 1.12.1 została wydana 14 lipca 2026 r.; ta informacja o wydaniu nie zastępuje sprawdzenia, która kompilacja działa na konkretnym hoście. Szablony pulpitów nawigacyjnych pochodzące z innych źródeł stanowią jedynie wskazówki, a nie wiarygodny spis własnej infrastruktury.

Wybierz typy paneli na podstawie ich opisu

Typ panelu zależy od pytania. Panel statystyczny nadaje się do przedstawienia aktualnej, jasno określonej wartości kluczowej. Może on wyświetlać pojedynczą wartość obliczoną oraz, opcjonalnie, niewielką linię trendu. Opis musi dokładnie określać, jaki wskaźnik i jaki punkt kontrolny są przedstawiane; na podstawie pojedynczej wartości pomiarowej nie można wyciągać ogólnych wniosków dotyczących stanu strony internetowej lub aplikacji.

Czynnikami decydującymi o obciążeniu, wzroście i powiązaniach są szeregi czasowe bardziej przydatne. Pokazują one na przykład, czy obciążenie procesora wzrasta tylko na krótko podczas wdrażania, czy też utrzymuje się na wysokim poziomie przez wiele godzin. Dopiero zakres czasowy, właściwa jednostka miary oraz porównanie z innymi sygnałami sprawiają, że pojedyncza wartość staje się wiarygodną obserwacją. Grafana obsługuje w tym celu różne wizualizacje, których znaczenie zależy od zapytania i sposobu przedstawienia danych.

Tabele nadają się do wielu podobnych elementów. Hosty, punkty montowania lub urządzenia można porównywać w poszczególnych wierszach, uwzględniając wartości pomiarowe i kontekst operacyjny, bez konieczności umieszczania wszystkich wierszy na jednym wykresie czasowym. Z kolei do analizy zależności czasowych zazwyczaj bardziej odpowiednia jest seria czasowa. Wybierz więc sposób przedstawienia danych w zależności od tego, czy chcesz porównać jednostki, czy też zbadać przebieg zmian.

Każdy panel wymaga precyzyjnego opisu, z którego wynika jednostka miary, zakres filtrowania oraz granica interpretacji. „Dostępna przestrzeń dyskowa według systemu plików dla każdego punktu montowania“ jest bardziej miarodajna niż „dysk“, ponieważ limity, zarezerwowane bloki lub brakujące i-węzły mogą mimo wszystko powodować problemy z zapisem. Podobnie czerwona wartość procentowa nie wskazuje ani na dostępność, ani na przyczynę; kolory przyciągają uwagę, ale nie zastępują diagnozy.

Nie należy ustawiać progów operacyjnych tylko dla ozdoby. Kolor ostrzegawczy może być przydatny, jeśli znane są rola służbowa, wzrost, nadmiarowość i potencjalny czas reakcji. W przypadku braku tego kontekstu panel powinien wyświetlać wartość neutralną i przekierowywać do odpowiedniego widoku szczegółowego. W ten sposób pozostają Wypowiedź panelu a ograniczenia techniczne są zrozumiałe dla wszystkich zainteresowanych.

Jak krok po kroku stworzyć przegląd usług hostingowych

Strona przeglądowa nie zaczyna się od wszystkich dostępnych wskaźników, lecz od kilku pytań, na które należy natychmiast odpowiedzieć w trakcie pracy: czy osiągane są wyznaczone cele, czy wzrasta obciążenie hosta, czy zaczyna brakować istotnej przestrzeni dyskowej lub czy ruch danych ulega zauważalnym zmianom? W tym celu należy najpierw utworzyć tylko cztery grupy paneli. Grafana grupuje zapytania i przedstawienia w panelach; dlatego różne wizualizacje powinny odpowiadać na konkretne pytania operacyjne.

Na początek wystarczy przejrzysty przegląd stanu gromadzenia danych, szereg czasowy obciążenia procesora, tabela lub szereg czasowy dostępnej pamięci dla każdego punktu montowania oraz szereg czasowy przepustowości sieci. Panele statystyczne nadają się do wyświetlania pojedynczej aktualnej wartości i mogą przedstawiać niewielki przebieg danych. Nie zastępują one jednak szeregu czasowego, gdy istotne są czas trwania, częstotliwość i moment wystąpienia nieprawidłowości.

Tabela stanowi podstawę do planowania, a nie sztywny szablon: Node Exporter dokumentuje obszary zbieraczy danych dotyczące systemów plików, sieci i innych danych hosta, jednak widoczne metryki i etykiety zależą od systemu, punktów montowania, kontenerów oraz aktywowanych zbieraczy danych. Dopiero potem dodaj panele specyficzne dla aplikacji, na przykład dotyczące błędów HTTP, połączeń z bazami danych lub kolejek. Bardziej szczegółowy przegląd na temat Pakiet narzędzi do monitorowania serwerów hostingowych może przy tym pogłębić swoją wiedzę na temat klasyfikacji wskaźników dotyczących infrastruktury i usług.

Wyrażenia PromQL zawarte w tym artykule są wyraźnie przykłady do dostosowania. Przed zatwierdzeniem sprawdź nazwy metryk, wartości etykiet oraz liczbę wynikowych szeregów w obszarze „Explore”. Oznacz każdy panel tak zwięźle, jak pozwala na to jego treść. Jednostka miary, wybrany zakres filtrów oraz wykluczone interfejsy lub pseudoplikowe systemy plików powinny być wyraźnie widoczne w konfiguracji lub opisie panelu.

Przejrzysty przegląd jest celowo uproszczony. Jeśli wyświetlane są jednocześnie wszystkie hosty, urządzenia, punkty montowania i etykiety kontenerów, traci się możliwość ustalenia priorytetów. Diagnozę przejmują następnie strony szczegółowe: tam można osobno przyjrzeć się poszczególnym instancjom, woluminom lub usługom. Dzięki temu strona główna pozostaje narzędziem orientacyjnym, a nie wizualnie przeładowanym zbiorem niepowiązanych ze sobą wskaźników.

Prawidłowe łączenie PromQL i zmiennych

Zapytanie musi jednocześnie określać metrykę i jej limit. Najpierw sprawdź w Prometheusie lub Grafana Explore, które serie i etykiety faktycznie istnieją w Twoim środowisku. Zmienne Grafany mogą następnie zastąpić stałe wartości etykiet. Jeśli włączono opcję wielokrotnego wyboru, jego zawartość zostanie użyta jako wyrażenie regularne; dlatego moduł dopasowujący etykiety musi =~ zamiast = użycie.

W przypadku obciążenia procesora skumulowany licznik nie ma bezpośredniego znaczenia. Poniższy przykład oblicza wartość procentową dla każdej instancji na podstawie czasu pracy procesora, który nie został spędzony w trybie bezczynności. Zakłada się, że node_cpu_seconds_total oraz czy dostępne są używane etykiety i zmienne Grafany $job oraz $instance zostały odpowiednio zdefiniowane.

100 - (
  avg by (instance) (
    rate(node_cpu_seconds_total{mode="idle", job=~"$job", instance=~"$instance"}[$__rate_interval])
  ) * 100
)

Sprawdź uzyskaną serię czasową w kilku przedziałach czasowych i porównaj ją z faktycznie zarejestrowanymi próbkami. Niewłaściwie dobrane okno przedziałowe może prowadzić do braku wyników lub do wyników o niewielkiej wartości informacyjnej. Ponadto dla analizy PromQL istotne jest, aby:, rate() należy zastosować przed agregacją, aby podczas obliczeń uwzględnić zresetowanie liczników.

W widoku pamięci następny przykład oblicza dostępną część dla każdego wybranego Punkt montowania. Należy wcześniej sprawdzić oba wskaźniki i ich zbiory etykiet. Jeśli licznik i mianownik są ograniczone przez różne filtry do różnych szeregów, dzielenie może dać puste lub nieoczekiwane wyniki.

100 * node_filesystem_avail_bytes{job=~"$job", instance=~"$instance", mountpoint=~"$mountpoint"}
/ node_filesystem_size_bytes{job=~"$job", instance=~"$instance", mountpoint=~"$mountpoint"}

Filtruj pseudoplikowe systemy plików w zależności od instalacji, zamiast sumować je na ślepo. Moduł zbierający dane o systemach plików dostarcza statystyki dotyczące systemów plików, ale nie każdy widoczny wiersz ma znaczenie dla podjęcia decyzji dotyczącej pojemności. Limity, zarezerwowane bloki, i-węzły i uprawnienia do zapisu pozostają odrębnymi elementami sprawdzania. Panel powinien zatem podawać jedynie dostępną część zgodnie z wybranymi wskaźnikami systemu plików.

W przykładzie dotyczącym sieci obliczana jest szybkość zmiany licznika bajtów, sumowana dla każdej instancji, a następnie przeliczana na bity na sekundę. Suma ma sens tylko wtedy, gdy uwzględnione interfejsy są ze sobą powiązane pod względem merytorycznym. Dlatego w swoim środowisku należy dodać zrozumiały filtr interfejsów, zamiast bezkrytycznie sumować wszystkie widoczne interfejsy.

sum by (instance) (
  rate(node_network_receive_bytes_total{job=~"$job", instance=~"$instance"}[$__rate_interval])
) * 8

Mnożnik 8 przelicza częstotliwość obliczoną na podstawie licznika bajtów na bity na sekundę. Interfejsy typu loopback, kontenerowe i tunelowe mogą generować sumę, która nie ma miarodajnego znaczenia dla połączenia fizycznego lub konkretnej usługi. Należy zatem udokumentować w panelu, które interfejsy są uwzględniane, a które wykluczone.

Zadbaj o to, by zmienne były przejrzyste i uporządkowane kaskadowo: najpierw $environment, to $job a następnie $instance; panele związane z pamięcią mogą $mountpoint uzupełnić. Grafana może dynamicznie generować zmienne ze źródła danych i ustanawiać między nimi zależności. Jednak rozbudowane zapytania o wartości etykiet przy każdym ładowaniu mogą spowolnić inicjalizację pulpitu nawigacyjnego.

Klasyfikowanie wartości progowych w oparciu o wiedzę operacyjną

Wartości progowe stają się wiarygodne, gdy przebieg czasowy jest zestawiony z wydarzeniami operacyjnymi. Adnotacje w Grafanie mogą zaznaczać na panelach prace konserwacyjne, wydania lub zmiany infrastruktury oraz odwoływać się do zmiennych pulpitu nawigacyjnego. Dzięki temu można na przykład sprawdzić, czy zmiana obciążenia zbiega się czasowo z wdrożeniem, zamiast pochopnie wnioskować o awarii na podstawie przebiegu linii.

Krótkotrwały skok obciążenia procesora można przewidzieć podczas tworzenia kopii zapasowej, rozgrzewania pamięci podręcznej lub planowanego przetwarzania danych. Staje się on istotny z punktu widzenia podejmowania działań raczej wtedy, gdy utrzymuje się przez dłuższy czas, wiąże się z opóźnieniami lub błędami i nie ma dla niego zaplanowanego wyjaśnienia w ramach roli usługi. Sam wskaźnik procentowy obciążenia procesora nie świadczy ani o obniżonej dostępności, ani o przyczynie spowolnienia aplikacji.

Rosnące zużycie pamięci wymaga innego podejścia. Kluczowe znaczenie mają: punkt montowania, którego to dotyczy, jego funkcja, tempo wzrostu oraz moment, w którym można zwiększyć pojemność. Wolumin danych z niewielką ilością wolnego miejsca może być traktowany jako pilniejszy niż podobnie zapełniony wolumin archiwalny; okna tworzenia kopii zapasowych, nadmiarowość i ścieżki odzyskiwania dodatkowo wpływają na priorytety operacyjne.

Również nietypowy ruch sieciowy nie stanowi automatycznego powodu do alarmu. Wzrost ruchu może wynikać z wydania nowej wersji, zdarzenia związanego z klientem, replikacji lub błędnie uwzględnionego interfejsu wirtualnego. Należy zatem porównać instancję, kierunek, filtr interfejsu oraz kontekst usługi w danym momencie. Dopiero ta kombinacja wskazuje, czy warto przeprowadzić szczegółową analizę danych pomiarowych dotyczących sieci, bazy danych lub serwisu internetowego.

W przypadku serwerów pocztowych widok hosta rzadko wystarcza jako jedyne wyjaśnienie. Procesor, pamięć i sieć mogą ujawniać nieprawidłowości, ale nie pozwalają ocenić ani jakości wysyłki, ani dostarczalności. Związek między hostingiem poczty elektronicznej a reputacją w tym celu uzupełnia konkretne sygnały i zależności.

Zamiast ogólnych wartości granicznych należy dla każdej roli określić, jaką reakcję powinien wywołać dany stan: obserwację, planowanie zdolności operacyjnej, poinformowanie służb gotowości lub natychmiastową kontrolę. Te Kontekst operacyjny-Zasada ta zapobiega traktowaniu identycznych wizualnie wartości procentowych w ten sam sposób. Umożliwia ona przejrzystą zmianę wartości granicznych w przypadku zmian dotyczących wzrostu, okien konserwacyjnych lub nadmiarowości środowiska.

Zapewnienie skalowalności zapytań i pulpitów nawigacyjnych

Pulpit nawigacyjny staje się trudny do odczytania i może działać wolno, jeśli każdy panel przez długi czas pobiera bardzo dużą liczbę wierszy i wielokrotnie wykonuje te same skomplikowane obliczenia. Dlatego należy ograniczyć wybór i prezentację do tych elementów, które są istotne dla danego zagadnienia operacyjnego. To, które zapytanie faktycznie obciąża system, należy sprawdzić na podstawie czasu jego wykonania i liczby wyników, a nie wyłącznie na podstawie jego wizualnej złożoności.

Również zmienne warto poddać analizie obciążenia. Lista wartości, która podczas otwierania pulpitu nawigacyjnego wykonuje rozbudowane zapytania dotyczące etykiet, może opóźniać inicjalizację. Warto zastosować sekwencję: najpierw środowisko lub rola, następnie zadanie, a dopiero potem instancja lub punkt montowania. Dzięki temu zbiory wyboru stają się mniejsze, a pulpit nawigacyjny z podsumowaniem nie próbuje udostępniać jednocześnie wszystkich historycznych i tymczasowych wartości etykiet.

W przypadku często używanych, wymagających dużej mocy obliczeniowej wyrażeń PromQL Zasady nagrywania opcja ukierunkowana. Prometheus analizuje regułę i zapisuje jej wynik jako nową serię czasową. Panele pobierają następnie tę wstępnie obliczoną serię zamiast pełnego wyrażenia źródłowego. Może to przyspieszyć powtarzające się zapytania w panelu kontrolnym, ale nie zastępuje sprawdzenia, czy wybór, agregacja i czas przechowywania są odpowiednie z merytorycznego punktu widzenia.

Reguły działają w grupach o stałych odstępach czasowych. Jeśli analiza danej grupy trwa dłużej niż jej odstęp czasowy, poszczególne iteracje mogą zostać pominięte. Dlatego też obliczenia wstępne nie powinny być traktowane jako uniwersalne rozwiązanie dla każdego zapytania: najpierw sprawdź, które panele są faktycznie często używane, ile wierszy przetwarza dane wyrażenie oraz czy widok oparty na rolach już wystarczająco zawęża zakres zapytania.

Przed wdrożeniem pliku reguł można lokalnie sprawdzić jego składnię. Poniższe polecenie terminala sprawdza podany plik, ale nie zmienia bieżącej konfiguracji Prometheusa ani nie aktywuje żadnej reguły.

promtool check rules /path/to/example.rules.yml

Ponadto należy zwracać uwagę na czas wykonania i przydatność każdej reguły. Nową serię czasową należy samodzielnie zapisać i pobrać. W przypadku niewielkiego pulpitu nawigacyjnego z niewielką liczbą hostów wyraźnie przefiltrowany wynik może być prostszy i łatwiejszy w utrzymaniu; wstępne obliczenia opłacają się przede wszystkim wtedy, gdy ta sama obciążająca obliczeniowo operacja jest niezawodnie wykonywana wielokrotnie.

Skalowalność nie wynika zatem wyłącznie z optymalizacji technicznej. Mniejsza liczba znaczących paneli, ograniczony wybór etykiet oraz oddzielne widoki szczegółowe zapobiegają również sytuacji, w której pulpit nawigacyjny staje się nieczytelny w razie awarii. Należy łącznie uwzględniać szybkość działania i wartość merytoryczną.

Zmiany w zapytaniach, takie jak zmiana trybu pracy, należy najpierw sprawdzić na wydruku z kopii pulpitu nawigacyjnego, porównać wyniki ze znanymi okresami, a dopiero potem wprowadzić do przeglądu. Dzięki temu nietypowe czasy ładowania, brakujące serie lub niezamierzone sumy pozostają widoczne i można je prześledzić, zamiast aby ujawniły się dopiero w zgłoszeniu.

Jednak zwięzłe zapytanie nie oznacza, że odpowiada ono na właściwe pytanie. Ograniczenie liczby wierszy nie może prowadzić do ukrycia kluczowych ról, punktów montowania lub interfejsów. Należy zatem świadomie udokumentować, które elementy obejmuje panel, a które pomija w widoku szczegółowym.

Interpretacja pustych paneli i fałszywych sygnałów

Pusty panel stanowi przede wszystkim wskazówkę diagnostyczną, a nie informację o tym, czy usługa działa prawidłowo, czy też uległa awarii. Sprawdź w następującej kolejności: czy metryka istnieje w Prometheusie, czy użyte etykiety i filtry są prawidłowe, czy wybrany przedział czasowy zawiera dane oraz czy zainstalowana wersja eksportera w ogóle dostarcza tę serię danych? Prometheus nie przejmuje błędnych konfiguracji podczas ponownego ładowania; dlatego też nieoczekiwany stan docelowy lub konfiguracyjny może mieć znaczenie.

Jeśli panel wskazuje nieoczekiwany stan gromadzenia danych, należy najpierw sprawdzić skonfigurowany cel zgrabiania oraz rzeczywisty zbiór danych w Prometheusie. Eksportery, ścieżkę sieciową, certyfikaty lub dane dostępowe należy traktować jedynie jako potencjalne źródła błędów, a nie jako już ustaloną przyczynę. Do oceny dostępności strony internetowej lub aplikacji niezbędne są własne, odpowiednie z technicznego punktu widzenia sygnały; sam panel monitorujący nie wystarcza do sformułowania takiego wniosku.

Nieoczekiwanie duża liczba szeregów czasowych wynika często z zastosowania zbyt szerokiego modułu dopasowującego lub dodatkowych etykiet przejętych z szablonu. Najpierw sprawdź zapytanie w postaci surowej, bez agregacji i bez zmiennej Grafana. Dzięki temu będzie można ustalić, czy np. instancja, urządzenie lub punkt montowania muszą być celowo wyświetlane oddzielnie. Agregację należy przeprowadzić dopiero wtedy, gdy będzie jasne, które elementy są porównywalne pod względem merytorycznym.

W przypadku wartości systemu plików pseudopliki, montowane kontenery lub ścieżki tymczasowe mogą zafałszować tabelę i sumę. Node Exporter dokumentuje moduł zbierający statystyki systemu plików, jednak faktycznie widoczne serie danych zależą od systemu i konfiguracji modułu zbierającego. Dlatego należy filtrować dane wyłącznie zgodnie z jasno udokumentowaną regułą i sprawdzić uwzględnione punkty montowania w konkretnym środowisku.

To samo dotyczy przepustowości sieci. Suma z wszystkich interfejsów może obejmować interfejsy typu loopback, tunelowe, wirtualne lub kontenerowe, co może skutkować uzyskaniem wartości bez znaczenia z operacyjnego punktu widzenia. Należy określić, które interfejsy należą do analizowanej ścieżki ruchu. Jeśli decyzja ta różni się w zależności od roli hosta, widok oparty na rolach jest zazwyczaj bardziej zrozumiały niż filtr globalny.

Stale rosnące wartości bajtów lub obciążenia procesora często nie oznaczają szczytowego obciążenia, lecz Licznik. Takie wskaźniki odzwierciedlają wartość skumulowaną. W przypadku przepustowości lub wykorzystania procesora konieczne jest uwzględnienie wartości średniej z odpowiedniego przedziału czasowego; Prometheus zaleca, aby w połączeniu z agregacjami rate() należy zastosować przed agregacją. Zbyt krótkie okno uwydatnia skoki, a zbyt długie może je przesłonić.

Jeśli wynik nadal wydaje się nieprawdopodobny, należy porównać go z pojedynczym przypadkiem, pojedynczym punktem montowania lub interfejsem oraz węższym przedziałem czasowym. Dopiero potem należy zmienić formułę. Takie stopniowe zawężanie zakresu zapobiega sytuacji, w której problem z wyświetlaniem zostanie zamaskowany przez coraz bardziej złożone filtry.

Zaimportowane szablony pulpitów nawigacyjnych stanowią jedynie punkt wyjścia. Nazwy wskaźników i etykiety mogą się różnić w zależności od systemu operacyjnego, wersji narzędzia eksportującego, konteneryzacji oraz aktywowanych modułów zbierających dane. Dlatego zawsze należy sprawdzać dostępne wiersze, a nie tylko składnię zaimportowanego zapytania.

Od ogólnego przeglądu do trafnej decyzji operacyjnej

Wystarczy prosty pulpit infrastrukturalny, jeśli zespół musi przede wszystkim zorientować się, który host lub która rola wymaga uwagi. Dostępność scraperów, obciążenie, dostępna pamięć i ruch sieciowy dostarczają w tym zakresie wstępnych wskazówek. Nie dają one jednak wiarygodnej odpowiedzi na pytanie, dlaczego aplikacja reaguje powoli lub czy dana usługa jest dostępna dla użytkowników. Grafana może wizualizować różne źródła danych, ale wspólny interfejs nie zastępuje analizy przyczyn.

Gdy tylko nieprawidłowość pojawia się wielokrotnie lub dotyczy kilku ról systemowych, w przeglądzie potrzebny jest Drill-down . Widoki ról połączone lub oddzielne mogą skupiać się na kluczowych wskaźnikach, takich jak serwery WWW, bazy danych, serwery pamięci podręcznej czy serwery pocztowe. Widok diagnostyczny uzupełnia szeregi czasowe dla poszczególnych instancji, tabele urządzeń lub punktów montowania, a także odniesienie czasowe do zmian. Dzięki temu strona główna pozostaje zorientowana na działanie, nie tracąc przy tym istotnych szczegółów technicznych.

Rozbudowuj bazę danych stopniowo. Po ustabilizowaniu się wskaźników dotyczących hostów można dodać wartości specyficzne dla aplikacji, takie jak wskaźniki błędów, czasy odpowiedzi, kolejki lub stany baz danych. Logi i ślady są pomocne przede wszystkim wtedy, gdy wykres metryki pozwala zawęzić zakres przyczyn, ale nie wyjaśnia ich. Nie każdy widok musi zawierać wszystkie rodzaje danych: każdy dodatkowy wiersz wymaga konkretnego pytania i odpowiedzialnej decyzji dotyczącej jego utrzymania.

Określ zakresy odpowiedzialności za pulpity nawigacyjne: kto zajmuje się aktualizacją etykiet i zmiennych, kto sprawdza filtry po zmianach w infrastrukturze, kto ustala wartości progowe i kto ocenia nieużywane panele? Zasady rejestrowania również wchodzą w zakres tych zadań, ponieważ uzupełniają pliki reguł i zapisane szeregi czasowe. Ich stałe interwały grupowe stanowią część ścieżki danych i należy je uwzględnić przy ustalaniu oczekiwanej aktualności.

Monitorowanie oddziela w tym przypadku obserwację od zobowiązań. Zielony panel nie gwarantuje ani bezpieczeństwa, ani aktualności poprawek, ani integralności danych, ani ogólnej dostępności. Procesy związane z poprawkami i bezpieczeństwem, tworzeniem kopii zapasowych, uprawnieniami oraz procedury postępowania w przypadku incydentów wymagają odrębnych mechanizmów kontroli. Pulpit nawigacyjny może dostarczać wskazówek i wspierać proces podejmowania decyzji, nie może jednak zastępować tych zadań operacyjnych wartościami procentowymi wyliczonymi na podstawie danych.

W przypadku niewielkich środowisk dobrym początkiem jest często przejrzysty zestaw spójnie oznaczonych paneli infrastruktury. Gdy rośnie liczba hostów, ról lub klientów, jasne etykiety, widoki ról i wstępnie obliczone zapytania stają się ważniejsze niż coraz większa strona główna. Kluczowe znaczenie ma to, aby każdy widok umożliwiał dalszą analizę i uwidaczniał granice swojej interpretacji.

Należy regularnie sprawdzać model operacyjny pod kątem wdrożeń, nowych eksporterów lub zmian w rolach serwerów. Usunięcie zbędnych paneli i zmiennych poprawia przejrzystość, podobnie jak dodanie nowych wskaźników. Pulpit nawigacyjny zachowuje swoją użyteczność, jeśli jego wygląd ewoluuje wraz z rzeczywistą architekturą i zakresem obowiązków.