Rola warstwy wizualizacji w inżynierii SRE: Wizualizacja danych nie jest jedynie zabiegiem estetycznym, lecz krytycznym narzędziem redukującym obciążenie poznawcze inżyniera. W rozproszonym środowisku chmurowym baza Prometheus przetwarza miliony próbek liczbowych na sekundę. Człowiek nie jest w stanie analizować surowych strumieni liczb, natomiast ludzki mózg przetwarza informacje wzrokowe tysiące razy szybciej niż tekst. Zadaniem platformy Grafana jest przekształcenie złożonych korelacji matematycznych w intuicyjny obraz, który pozwala dyżurnemu natychmiast ocenić stabilność usług i podjąć właściwe decyzje mitygacyjne.

Wizualizacja to ogniwo, które spina surowe pomiary z ludzką decyzją, i od niej warto zacząć, bo bez tego wątku cała reszta wykładu nie ma sensu. Z jednej strony mamy metrykę, czyli konkretną liczbę z etykietą i znacznikiem czasu, a z drugiej człowieka, który musi w kilka sekund ocenić, czy system działa dobrze. Pojedyncza liczba nie wystarczy - wizualizacja dokłada do niej to, czego jej brakuje: kontekst (skąd pochodzi i jakiej serii dotyczy), trend (co robi w czasie), progi (co jest jeszcze normalne, a co już groźne) oraz korelacje z innymi pomiarami. Dopiero wtedy dane stają się wiedzą decyzyjną, czyli tzw. insight, a nie zbiorem punktów na ekranie. W tym wykładzie zbudujemy cały ten potok: od zapytania PromQL, przez panel Grafany, aż po dashboard wspierający realne decyzje operacyjne.

Zanim przejdziemy do Grafany, warto zrozumieć, co dokładnie rysujemy. Wynik zapytania PromQL to wektor: wektor chwilowy (instant) zwraca wartość każdej serii w danej chwili, a wektor zakresowy (range) ciąg punktów w zadanym oknie czasowym; każdy punkt to wartość, znacznik czasu i zbiór etykiet. Grafana zamienia ten wektor na wizualizację - panel Time series rysuje linię w czasie, Stat pokazuje pojedynczą wartość z minitrendem, Gauge stawia wskaźnik z progami kolorów, Heatmap rozkłada wartości w czasie, a Table prezentuje szczegóły. Każdy z tych typów odpowiada na inne pytanie operacyjne: tendencję czytamy z linii, bieżący stan ze wskaźnika, rozkład z heatmapy, szczegóły z tabeli. Dashboard natomiast grupuje panele w hierarchię informacji - najważniejsze sygnały na górze, głębsza diagnostyka niżej. W skrócie: wizualizacja to tłumaczenie liczb na narzędzia decyzyjne, a nie tylko ozdabianie wykresów.

Teraz kluczowa rzecz: Grafana i PromQL razem tworzą platformę zunifikowanej obserwowalności. Grafana pełni rolę warstwy interfejsu użytkownika - dostarcza źródła danych, panele, zmienne, adnotacje i alerting - podczas gdy PromQL jest silnikiem zapytań o szeregi czasowe. Dzięki temu na jednym ekranie widzimy metryki z Prometheusa, obok logi z Loki i ślady z Tempo, a jeszcze obok dane biznesowe z baz SQL czy usług chmurowych. Wszystko działa w jednym interfejsie, ze wspólnym zakresem czasu, wspólnymi zmiennymi i adnotacjami. Operator nie przeskakuje między narzędziami: metryki odpowiadają na pytanie, co się stało, logi - dlaczego, a ślady - gdzie. To dziś standard ekosystemu CNCF i Grafana Labs, więc warto oswoić się z tym myśleniem od początku.

Na koniec sprecyzujmy cele tej części. Po jej przerobieniu powinieneś umieć zbudować czytelny, działający dashboard - niekoniecznie ładny, ale decyzyjny. Będziemy ćwiczyć diagnostykę przez wizualizację: widzisz skok na wykresie, schodzisz poziom niżej przez drill-down i docierasz do przyczyny. Przeanalizujemy też trendy i planowanie pojemności, czyli prognozowanie, kiedy zasoby się wyczerpią, oraz przygotujemy widoki produkcyjne: operacyjne ekrany NOC o dużej gęstości informacji i widoki zarządcze z metrykami biznesowymi oraz zgodnością ze SLA. To wykład warsztatowy - przejdziemy całą drogę od pliku prometheus.yml, przez zapytania PromQL, aż po dashboardy trzymane w Git jako kod.

Terminologia: dashboard (pulpit), panel (panel), visualization (wizualizacja), time series (szereg czasowy), instant vector (wektor chwilowy), range vector (wektor zakresowy), unified observability (zunifikowana obserwowalność), insight (wiedza decyzyjna), actionable (nadający się do działania).

Wizualizacja to ogniwo łączące surowy pomiar z decyzją, którą operator podejmuje w ciągu kilku sekund - i od tego wątku warto zacząć całą część wykładu. Grafana nie jest tu jednak tylko rysownikiem wykresów: wraz z językiem PromQL tworzy wspólną platformę obserwowalności, na której spina metryki, logi i ślady w jeden obraz systemu. Zanim zagłębimy się w szczegóły zapytań i paneli, warto zobaczyć cały potok pracy, którego się dziś nauczymy: od wektora PromQL, przez wizualizację, aż po dashboard realnie wspierający decyzje operacyjne.

Sam wynik zapytania przyjmuje postać wektora - chwilowego albo zakresowego - a Grafana zamienia go na linię czasu, wskaźnik, słupki, rozkład czy tabelę, zależnie od pytania, na które ma odpowiedzieć. Do pojedynczej liczby dokłada to, czego jej brakuje: kontekst, trend, progi i korelacje z innymi pomiarami, dzięki czemu dane stają się wiedzą, a nie zbiorem punktów na ekranie. Spójny interfejs dla metryk z Prometheusa, logów z Loki i śladów z Tempo odpowiada na trzy pytania: co się stało, dlaczego i gdzie.

Wyjaśnienie skrótów użytych na slajdzie:
SRE – Site Reliability Engineering – inżynieria niezawodności systemów; Dyscyplina techniczna wykorzystująca narzędzia wizualizacji do kontroli stabilności środowisk rozproszonych.
GUI – Graphical User Interface – graficzny interfejs użytkownika; Wizualne środowisko prezentacji danych telemetrycznych w postaci wykresów, map ciepła i wskaźników.
UX – User Experience – doświadczenie użytkownika; Ergonomia i intuicyjność interfejsu decydująca o szybkości interpretacji stanu systemu przez dyżurnego inżyniera.
TSDB – Time Series Database – baza danych szeregów czasowych; Podstawowe źródło danych dla pulpitów operacyjnych udostępniające metryki w czasie.
KPI – Key Performance Indicator – kluczowy wskaźnik efektywności; Syntetyczny miernik biznesowo-techniczny prezentowany na nadrzędnych pulpitach kierowniczych.

Wizualizacja nie jest dodatkiem do monitoringu, lecz jego fundamentem, więc warto powiedzieć sobie wyraźnie, dlaczego w ogóle ją stosujemy. Sprowadza się to do trzech filarów. Po pierwsze szybkość - ludzki wzrok wychwytuje nieprawidłowości w ułamku sekundy. Po drugie wspólny język - wszystkie zespoły patrzą na jeden, ten sam obraz systemu. Po trzecie komunikacja - techniczne metryki przekładamy na decyzje biznesowe. Każdy z tych filarów odpowiada innej stronie codziennej pracy inżyniera SRE: operacyjnej, organizacyjnej i strategicznej, więc przyjrzyjmy się każdemu z osobna.

Zacznijmy od szybkości, czyli rozpoznawania wzorców. Ludzki wzrok przetwarza obraz nawet 60 000 razy szybciej, niż czytanie tekstu - to powszechnie przytaczana wartość, którą warto traktować raczej jako regułę kciuka niż ścisły pomiar, ale dobrze oddaje sedno. Skok latencji, który przy czytaniu tabeli wymagałby przebrnięcia przez setki wierszy, na linii wykresu dostrzegasz od razu: p99 potrafi wyskoczyć ze 100 milisekund na 2 sekundy i w tym momencie cały obraz mówi wprost - dzieje się coś złego. Rozpoznawanie wzorców daje wczesne ostrzeżenie: sezonowość, trendy i korelacje widzisz „na oko", zanim alert jeszcze przekroczy próg. W efekcie wskaźnik MTTA, czyli czas do momentu przyjęcia zgłoszenia, spada z minut do sekund.

Drugi filar to wspólny obraz stanu, po angielsku common operational picture. Dashboard działa jak wspólna podstawa dla zespołów: deweloperzy śledzą nowe wdrożenia i wskaźnik błędów, operacje patrzą na nasycenie i pojemność, a zarząd na zgodność ze SLA i budżet błędów. Kluczowe jest to, że wszyscy patrzą na te same dane, ten sam zakres czasu i te same progi. Taka wspólna świadomość sytuacyjna przyspiesza MTTR: gdy incydent jest widoczny na jednym ekranie, triage trwa sekundy, a nie godziny, bo znika spór „u mnie wygląda inaczej" albo „czegoś nie widzę". W praktyce oznacza to likwidację silosów informacyjnych w organizacji.

Trzeci filar to komunikacja z zarządem, czyli tłumaczenie techniki na biznes. Widok zarządczy pokazuje zgodność ze SLA w procentach, pozostały budżet błędów, liczbę incydentów i trend MTTR - menedżer widzi wartość dla firmy, a nie techniczne szczegóły. Ekran NOC z kolei prezentuje aktywne alerty, sygnały nasycenia i najczęstsze błędy, czyli to, co operator powinien zrobić w pierwszej kolejności. Ten sam dashboard, dzięki zmiennym i adnotacjom, może obsługiwać różne role i różne zakresy czasu. Tak właśnie wygląda tłumaczenie metryk na język decyzyjny.

Terminologia: dashboard (pulpit), visualization (wizualizacja), executive view (widok zarządczy), NOC view (widok centrum operacyjnego), common operational picture (wspólny obraz operacyjny), situational awareness (świadomość sytuacyjna), MTTA (czas do przyjęcia), MTTR (czas do rozwiązania).

Zanim pokażemy narzędzia, warto postawić pytanie, po co w ogóle wizualizować metryki, skoro ich surowe wartości leżą już w bazie Prometheusa. Odpowiedź sprowadza się do trzech filarów: szybkości rozpoznawania wzorców przez ludzki wzrok, wspólnego obrazu stanu systemu dla wszystkich zespołów oraz tłumaczenia technicznych pomiarów na język decyzji biznesowych. Każdy z tych filarów odpowiada innej stronie pracy inżyniera SRE - operacyjnej, organizacyjnej i strategicznej - więc przyjrzyjmy się im po kolei.

Wzrok przetwarza obraz nawet kilkadziesiąt tysięcy razy szybciej, niż czytamy rzędy liczb, i to wystarczy, by wskaźnik MTTA, czyli czas do przyjęcia zgłoszenia, spadł z minut do sekund. Wspólny dashboard likwiduje silosy informacyjne: deweloperzy widzą wskaźnik błędów świeżo wdrożonej wersji, operacje nasycenie i pojemność, a zarząd zgodność ze SLA i pozostały budżet błędów. Wszyscy patrzą na te same dane, ten sam zakres czasu i te same progi, co przyspiesza również rozwiązywanie incydentów.

Wyjaśnienie skrótów użytych na slajdzie:
MTTR – Mean Time To Recover – średni czas naprawy; Metryka operacyjna, której redukcja jest głównym celem tworzenia ergonomicznych dashboardów awaryjnych.
MTTD – Mean Time To Detect – średni czas wykrycia; Średni czas od zaistnienia anomalii do jej zauważenia na ekranie monitoringu.
SLA – Service Level Agreement – umowa o gwarantowanym poziomie usług; Prawnie wiążące zobowiązanie, którego stan realizacji śledzony jest na pulpitach raportowych.
SLO – Service Level Objective – cel poziomu usług; Wewnętrzny próg inżynierski wyznaczający kolorystykę wskaźników jakości usługi.
NOC – Network Operations Center – centrum zarządzania siecią; Zespół operacyjny pracujący w trybie 24/7 na podstawie wielkoformatowych ekranów telemetrycznych.

Ergonomia i psychologia percepcji w projektowaniu pulpitów: Zgodnie z psychologicznym prawem Millera, ludzka pamięć robocza jest w stanie efektywnie przetwarzać jednocześnie 7 ± 2 elementy informacji. Przeładowanie pulpitu kilkudziesięcioma wykresami wywołuje paraliż analityczny – inżynier w obliczu awarii nie wie, na który panel patrzeć. Dlatego profesjonalny dashboard operacyjny stosuje ścisłą hierarchię: na samej górze umieszcza się stan realizacji celów SLO i budżetu błędów (widok syntetyczny), poniżej metryki ruchu aplikacji (RED), a na samym dole szczegóły infrastruktury (USE). Jeśli dany wykres nie prowadzi do konkretnej decyzji operacyjnej, nie powinien znajdować się na głównym pulpicie.

Projektowanie pulpitów operacyjnych podlega zasadom ergonomii interakcji określonym w normie PN-EN ISO 9241-110. Obowiązuje reguła 5 sekund: inżynier dyżurny musi w ciągu 5 sekund ocenić stan zdrowia usługi na podstawie kolorystycznych progów semantycznych. Układ elementów musi realizować zasadę odwróconej piramidy: u góry zagregowane wskaźniki SLI/SLO usługi, pośrodku dynamika żądań i błędów, a na dole szczegółowe nasycenie zasobów.

Dobry dashboard wyróżnia nie estetyka, lecz inżynieria użyteczności, dlatego zanim zaczniemy kleić panele, warto poznać kanon zasad projektowych. Limit poznawczy, spójność czasowa, semantyka kolorów i hierarchia informacji - to one odróżniają pulpit operacyjny od zwykłej kolekcji wykresów. Pamiętaj, że dashboard ma odpowiedzieć na pytanie operacyjne w sekundy, nie w minuty. Te zasady są uniwersalne: obowiązują zarówno w widokach NOC, jak i w widokach zarządczych, i powinny stać się twoją checklistą przy każdym przeglądzie dashboardu.

Pierwsza zasada dotyczy liczby paneli, bo zagadnienie to nazywa się zarządzaniem obciążeniem poznawczym, czyli cognitive load management. Ludzka pamięć robocza mieści przeciętnie 7±2 obiekty naraz - to prawo Millera, jedno z najbardziej znanych w psychologii poznawczej. Dlatego 30 paneli na jednym ekranie nie daje wiedzy, lecz tylko szum: kluczowe sygnały toną w gęstości elementów, a operator traci skupienie. Trzymaj się zakresu 5-15 paneli i grupuj je logicznie - metryki RED (Rate, Errors, Duration) dla usług, metryki USE (Utilization, Saturation, Errors) dla infrastruktury. Zasada prosta: każdy panel musi odpowiadać na jedno, jasne pytanie. Mniej znaczy więcej.

Druga zasada, spójność czasowa, czyli temporal consistency, wynika z tego, że wszystkie panele powinny pokazywać ten sam wycinek czasu. Globalny selektor czasu w prawym górnym rogu steruje wszystkimi panelami jednocześnie. Zmienne $__range i $__interval w zapytaniach PromQL sprawiają, że rozdzielczość wykresu sama dopasowuje się do wybranego okna - na krótkim zakresie mamy gęste punkty, na długim zagęszczenie maleje. Połączone dashboardy, przez które schodzimy w dół przy drill-downie, zachowują zakres czasu. Dzięki temu znika irytujące pytanie: dlaczego ten wykres pokazuje inny czas?

Trzecia zasada to czytelne etykiety i kolory, czyli semantyka kolorów. Legenda powinna zawierać czytelną nazwę metryki i jej kluczowe etykiety, na przykład instance, job czy handler - a nie surowy identyfikator serii. Kolory mają stałe znaczenie: czerwony oznacza błąd i stan krytyczny, zielony stan dobry, żółty ostrzeżenie, a niebieski neutralną informację. Wybieraj palety przyjazne dla daltonistów, jak ColorBrewer czy Viridis - są bezpieczne dla osób z deuteranopią lub protanopią, a to około 8% mężczyzn. Spójna kolorystyka na wszystkich dashboardach to duże ułatwienie poznawcze.

Czwarta zasada to hierarchia informacji, czyli information architecture. Układ podporządkowujemy decyzjom, a nie porządkowi alfabetycznemu. Na górze, w strefie „above the fold", umieszczamy sygnały krytyczne: status SLO, procent zużytego budżetu błędów, aktywne alerty i najważniejsze sygnały nasycenia. W środku metryki RED i USE w ujęciu per usługa. Na dole szczegóły - per instancja, per endpoint, per zapytanie do bazy. Taka kolejność prowadzi wzrok operatora: najpierw odpowiadamy, czy jest problem, potem gdzie, a na końcu dlaczego.

Terminologia: cognitive load (obciążenie poznawcze), information hierarchy (hierarchia informacji), time picker (selektor czasu), semantic colors (kolory semantyczne), above the fold (strefa ponad zagięciem ekranu), clarity (czytelność), layout (układ).

Dobry dashboard to nie kwestia estetyki, lecz inżynierii użyteczności - ma odpowiedzieć na pytanie operacyjne w kilka sekund, a nie w kilka minut. W tym slajdzie omówimy cztery zasady projektowe, które odróżniają pulpit operacyjny od zwykłej kolekcji wykresów: limit liczby paneli, spójność czasową, semantykę kolorów i hierarchię informacji. Każda z nich rozwiązuje konkretny problem, od przeciążenia poznawczego po zatopione w szczegółach krytyczne wskaźniki, dlatego warto potraktować je jako stałą checklistę przy każdym przeglądzie pulpitu.

Za zasadami stoją konkretne fakty. Ludzka pamięć robocza mieści przeciętnie siedem plus minus dwa obiekty naraz - to prawo Millera - stąd zalecane pięć do piętnastu paneli, a metryki dobrze jest grupować według schematów RED dla usług i USE dla infrastruktury. Globalny selektor czasu steruje wszystkimi panelami jednocześnie, a palety przyjazne daltonistom, jak Viridis czy ColorBrewer, są bezpieczne dla części odbiorców. W strefie nad zagięciem ekranu, na samej górze, umieszczamy status SLO, budżet błędów i aktywne alerty.

Wyjaśnienie skrótów użytych na slajdzie:
ISO – International Organization for Standardization – Międzynarodowa Organizacja Normalizacyjna; Instytucja definiująca międzynarodowe normy ergonomii interfejsów (np. seria ISO 9241).
UI – User Interface – interfejs użytkownika; Warstwa wizualna platformy analitycznej decydująca o czytelności prezentowanych danych.
UX – User Experience – doświadczenie użytkownika; Dobre praktyki projektowe eliminujące szum informacyjny i przeciążenie poznawcze inżyniera.
RED – Rate, Errors, Duration – metoda RED (częstotliwość, błędy, czas trwania); Wzorzec kompozycji paneli dla usług aplikacyjnych w architekturze mikroserwisowej.
USE – Utilization, Saturation, Errors – metoda USE (utylizacja, nasycenie, błędy); Wzorzec układu pulpitów dla zasobów sprzętowych (CPU, pamięć, sieć, dyski).

Dlaczego mapa cieplna (Heatmap) jest niezbędna do analizy latencji: Zwykły wykres liniowy pokazujący percentyle (np. p50 i p99) rysuje tylko wybrane punkty podziału. W rzeczywistości opóźnienia w systemach rozproszonych mają często charakter wielomodalny (bimodal distribution) – np. zapytania trafiające do pamięci cache trwają 5 ms, a zapytania odpytujące dysk trwają 200 ms. Na wykresie liniowym widzimy jedynie uśredniony przebieg, tracąc informację o strukturze ruchu. Mapa cieplna prezentuje pełny trójwymiarowy rozkład: oś X to czas, oś Y to czas trwania żądania, a intensywność koloru (jasność) odzwierciedla liczbę zapytań w danym koszyku, co pozwala natychmiast dostrzec rozwarstwienie ruchu.

W analizie czasu odpowiedzi usług mikroserwisowych tradycyjny wykres liniowy percentyla p99 jest niewystarczający, gdyż maskuje wielomodalność rozkładu (np. szybkie odpowiedzi z cache 2 ms vs wolne zapytania do bazy danych 800 ms). Standardem inżynierskim jest stosowanie mapy ciepła (Heatmap), która wizualizuje pełne widmo koszyków histogramu Prometheusa (rate(http_request_duration_seconds_bucket[$__rate_interval])), natychmiast uwypuklając rozwarstwienie ruchu i anomalie.

Nadszedł czas, aby poznać podstawowe typy paneli w Grafanie, bo każdy z nich odpowiada na inne pytanie operacyjne. Dobór formy do rodzaju danych i do decyzji, którą ma wesprzeć wizualizacja, to fundament każdego sensownego dashboardu. Mówimy tu o pięciu głównych typach: Time series dla trendów, Bar chart dla porównań, Gauge dla bieżącego stanu, Heatmap dla rozkładów i Table dla szczegółów. Nadrzędna zasada brzmi match viz to question - czyli dopasuj formę do pytania, a nie do gustu estetycznego.

Zacznijmy od wykresu liniowego, czyli Time series. To klasyczny wykres, na którym oś pozioma to czas, a oś pionowa wartość metryki. Sprawdza się do pokazywania latencji, przepustowości (RPS), wskaźnika błędów i zużycia zasobów - CPU, pamięci, dysku, sieci. Wiele serii z legendą pozwala porównywać instancje, joby czy handlery. Warianty wizualne: linia pokazuje ciągłość zmian, obszar kumuluje wartości, a słupki porównują dyskretne interwały. Wybieraj je w zależności od tego, czy pytasz o kierunek zmiany, sumę czy porównanie fragmentów czasu między sobą.

Kolejny typ to słupki, czyli Bar gauge lub Bar chart, służące do porównań dyskretnych. Słupki pionowe lub poziome porównują kategorie - na przykład dziesięć najwolniejszych endpointów po opóźnieniu p99, błędy w podziale na usługi, zajętość dysku per wolumen czy najaktywniejszych rozmówców po IP. Na osi poziomej mamy tu kategorię, a nie czas. Wariant Bar gauge łączy wskaźnik z układem słupkowym i świetnie sprawdza się w rankingach i widokach „top N".

Wskaźnik Gauge to z kolei stan w tej chwili z progami. Prezentuje pojedynczą wartość oprawioną w kolorowe progi, najczęściej w formie koła lub półkola. Idealny dla bieżącego procentu zużytego budżetu błędów, CPU, pamięci, dysku czy liczby aktywnych alertów. Progi kolorów - na przykład zielony poniżej 70 procent, żółty do 90, czerwony powyżej - czytamy jednym rzutem oka. Pamiętaj jednak: Gauge pokazuje stan teraz, a nie trend; do trendów służy wykres liniowy i tak już rozumiemy podział ról.

Dla rozkładów w czasie mamy heatmapę. Na osi poziomej czas, na pionowej wartość - na przykład przedziały latencji - a intensywność koloru oznacza liczbę obserwacji. Heatmapa pokazuje, jak zmienia się rozkład wartości w czasie: stabilne serie dają „paski", degradacja rozmycie, a gwałtowne skoki jasne piksele. Dzięki niej dostrzegasz ogon rozkładu, czyli to, co szereg czasowy narysowany jako linia potrafi skutecznie ukryć.

Na koniec tabela. Jest sortowalna, filtrowalna, a komórki potrafią być kolorowane wartościami. Sprawdza się do stanu targetów (up/down, czas scrape'a), najaktywniejszych rozmówców, najwolniejszych endpointów czy aktywnych alertów. To warstwa drill-downu - użytkownik klika, sortuje i filtruje dokładnie to, co chce zobaczyć. A więc pełna mapa: trend - Time series, porównanie - Bar chart lub Gauge, stan w tej chwili - Gauge, rozkład - Heatmap, szczegóły - Table. Zapamiętaj to mapowanie pytania decyzyjnego na typ panelu, a zaoszczędzisz sobie godzin poprawiania wykresów, które „wyglądają ładnie, ale nic nie mówią".

Nie każdy typ wykresu nadaje się do każdego pytania, a dopasowanie formy do rodzaju danych i decyzji, którą ma wesprzeć wizualizacja, przesądza o użyteczności całego dashboardu. Grafana oferuje kilkanaście typów paneli, lecz pięć z nich pokrywa większość codziennych potrzeb: Time series dla trendów, Bar chart dla porównań, Gauge dla bieżącego stanu, Heatmap dla rozkładów i Table dla szczegółów. Nadrzędna zasada brzmi prosto: formę dobieramy do pytania, a nie do gustu estetycznego autora.

Przyjrzyjmy się, co operator widzi w każdym z tych widoków. Wykres liniowy pokazuje ciągłość zmian latencji, liczby żądań na sekundę, wskaźnika błędów czy zużycia CPU. Słupki porównują dyskretne kategorie - dziesięć najwolniejszych endpointów pod względem p99 albo błędy w podziale na usługi. Gauge oprawia pojedynczą wartość w kolorowe progi czytane jednym rzutem oka, heatmapa ujawnia ogon rozkładu, który linia potrafi skutecznie ukryć, a tabela pozwala sortować i filtrować szczegóły, gdy schodzimy poziom niżej.

Wyjaśnienie skrótów użytych na slajdzie:
CDF – Cumulative Distribution Function – dystrybuanta empiryczna; Funkcja matematyczna obrazująca skumulowany rozkład czasów odpowiedzi zapytań.
PDF – Probability Density Function – funkcja gęstości prawdopodobieństwa; Funkcja rozkładu prawdopodobieństwa ujawniająca wielomodalność czasów wykonania operacji.
TSDB – Time Series Database – baza danych szeregów czasowych; Silnik bazodanowy dostarczający punkty pomiarowe dla paneli liniowych i słupkowych.
PromQL – Prometheus Query Language – język zapytań Prometheus; Język formułujący zapytania dla różnych wariantów wizualizacji metryk.
RPS – Requests Per Second – liczba żądań na sekundę; Najczęstsza jednostka osi pionowej paneli przepustowości usług sieciowych.

Oficjalne zasoby i dobre praktyki tworzenia paneli wizualizacyjnych omawia przewodnik po pulpitach Grafana Dashboards.

Grafana to nie tylko narzędzie do rysowania wykresów - to pełnoprawna platforma obserwowalności, która scala wiele źródeł danych w jeden spójny widok. Łączy źródła metryk, logów, śladów i danych biznesowych, oferuje kilkanaście typów paneli, dashboardy zapisywane w JSON, zmienne, adnotacje, alerting, kontrolę dostępu i provisioning. Można ją wręcz nazwać centrum dowodzenia: wszystko w jednym interfejsie, ze wspólnym zakresem czasu, zmiennymi i adnotacjami. Zrozumienie tej architektury warunkuje skuteczne budowanie dashboardów i sprawne troubleshooting, dlatego przyjrzyjmy się czterem najważniejszym elementom.

Zacznijmy od źródeł danych, czyli data sources. Grafana rozmawia z Prometheusem o metrykach, z Loki o logach, z Tempo, Jaegerem czy Zipkinem o śladach, a z bazami - MySQL, PostgreSQL, InfluxDB - oraz z chmurą, jak CloudWatch, Azure Monitor czy Elasticsearch, o danych biznesowych i infrastrukturze. Każde źródło ma własny język zapytań: PromQL, LogQL, TraceQL albo SQL. Co ważne, w jednym panelu możesz uruchomić zapytanie o metryki i o logi jednocześnie, w widoku podzielonym. To korelacja sygnałów bez przełączania kontekstu.

Drugi element to panele i dashboardy oraz ich model JSON. Panel to pojedyncza wizualizacja złożona ze źródła danych, zapytania i opcji wyglądu. Dashboard to zbiór paneli uzupełniony o zmienne, adnotacje, zakres czasu, interwał odświeżania i układ. Całość zapisuje się jako model JSON, dzięki czemu dashboardy można wersjonować w Git, przenosić między środowiskami i wdrażać automatycznie. W interfejsie Grafany działa też historia wersji z możliwością cofnięcia zmian. To fundament podejścia dashboard-as-code, do którego wrócimy w dalszej części wykładu.

Trzeci element to role i uprawnienia, czyli RBAC z logowaniem SSO. Viewer przegląda dashboardy w trybie tylko do odczytu, Editor tworzy i zmienia je w przypisanych folderach, a Admin zarządza użytkownikami, źródłami danych i ustawieniami organizacji. Uprawnienia można dzielić per folder i per zespół - zespół A edytuje swoje foldery, zespół B ma dostęp tylko do odczytu. Współpracownicy logują się przez SSO: SAML, OIDC, LDAP czy OAuth z GitHubem, GitLabem i Keycloakiem. Obowiązuje zasada least privilege, czyli najmniejszych uprawnień: domyślnie odczyt, a uprawnienia do zapisu dodajemy dokładnie tam, gdzie są potrzebne.

Czwarty element to ekosystem wtyczek, który czyni Grafanę platformą, a nie zamkniętym narzędziem. Wtyczki paneli dodają nowe wizualizacje - wykres kołowy, mapę świata, graf węzłów. Wtyczki źródeł danych podpinają kolejne backendy, a wtyczki aplikacji, jak Kubernetes czy AWS, przynoszą gotowe dashboardy i alerty. Rynek wtyczek znajdziesz na grafana.com/plugins. W praktyce oznacza to, że Grafanę da się rozbudować do niemal dowolnych potrzeb waszych organizacji.

Terminologia: data source (źródło danych), panel (panel), dashboard (pulpit), folder (folder), team (zespół), organization (organizacja), provisioning (aprowizacja), plugin (wtyczka), alerting (alertowanie), JSON model (model JSON).

Czas poznać głównego bohatera tej części kursu - Grafanę, platformę, która scala metryki, logi, ślady i dane biznesowe z ponad pięćdziesięciu źródeł w jeden spójny interfejs. To więcej niż rysownik wykresów: dzięki zapisowi dashboardów w modelu JSON pulpit można wersjonować w Gicie, przenosić między środowiskami i wdrażać automatycznie, co otwiera drogę do podejścia dashboard-as-code i GitOps. Zrozumienie architektury platformy warunkuje sprawne budowanie pulpitów i skuteczne rozwiązywanie problemów, dlatego przyjrzymy się czterem jej filarom.

Architektura Grafany opiera się na czterech filarach. Źródła danych - Prometheus, Loki, Tempo, MySQL czy CloudWatch - rozmawiają z platformą własnym językiem zapytań: PromQL, LogQL, TraceQL albo SQL. Panel to pojedyncza wizualizacja, a dashboard zbiór paneli wzbogacony o zmienne i adnotacje. Role Viewer, Editor i Admin wraz z uprawnieniami folderów wspierają kontrolę dostępu, a logowanie przez SSO, SAML, OIDC czy LDAP to codzienność. Wtyczki rozszerzają z kolei platformę o kolejne źródła, panele i aplikacje, jak Kubernetes czy AWS.

Wyjaśnienie skrótów użytych na slajdzie:
OSS – Open Source Software – oprogramowanie o otwartym kodzie źródłowym; Model licencyjny platformy Grafana umożliwiający bezpłatne wdrażanie w infrastrukturze własnej.
CNCF – Cloud Native Computing Foundation – Fundacja Oprogramowania Chmurowego; Środowisko projektów otwartoźródłowych, z którymi platforma Grafana ściśle współpracuje.
API – Application Programming Interface – interfejs programowania aplikacji; Programowy interfejs Grafany pozwalający na automatyzację zarządzania pulpitami i użytkownikami.
HTTP – Hypertext Transfer Protocol – protokół przesyłania dokumentów hipertekstowych; Protokół komunikacji pomiędzy przeglądarką inżyniera a serwerem Grafany.
SQL – Structured Query Language – strukturalny język zapytań; Język wspierany przez wtyczki źródeł danych do relacyjnych baz (PostgreSQL, MySQL).

Grafana to pojedynczy binarny plik napisany w Go obsługiwany przez usługę systemd. Instalacja na dystrybucjach opartych na Debianie, Ubuntu, RHEL czy Fedorze jest trywialna i nie wymaga dodatkowych zależności w czasie działania. Typowy przepływ pracy wygląda tak: instalacja pakietu, uruchomienie usługi, sprawdzenie jej statusu, dostęp do interfejsu na porcie 3000, pierwsze logowanie ze zmianą hasła i konfiguracja pliku grafana.ini. Wszystkie polecenia zweryfikowaliśmy na testowym środowisku, więc nie musisz zgadywać wyników.

Instalację wykonujemy menedżerem pakietów. Na Debianie i Ubuntu to sudo apt-get install -y grafana z oficjalnego repozytorium Grafana Labs, kluczowanego GPG. Na RHEL, Fedorze i CentOS sudo dnf install -y grafana albo wariant z yum. Do wyboru są też inne drogi: pobranie archiwum tar.gz, kontener Docker (docker run -d -p 3000:3000 grafana/grafana) czy instalacja na Kubernetesie przez Helm. Menedżer pakietów ma tę przewagę, że dba o aktualizacje, zależności i integrację z systemd. Wersję możesz sprawdzić poleceniem grafana-server -v.

Usługę uruchamiamy przez systemd: sudo systemctl start grafana-server włącza usługę, sudo systemctl enable grafana-server dodaje autostart przy starcie systemu, a sudo systemctl status grafana-server pokazuje jej stan - poprawna odpowiedź to "Active: active (running)". Logi oglądasz poleceniem journalctl -u grafana-server -f. Domyślny port to 3000, a zmienisz go w grafana.ini pod kluczem http_port. Jeśli do serwera obowiązuje zapora, otwórz port: sudo ufw allow 3000.

Interfejs otwieramy w przeglądarce na adresie http://host:3000 i logujemy się domyślnym loginem admin oraz hasłem admin, po czym system bezwzględnie wymusza ustawienie nowego hasła - to standardowa praktyka bezpieczeństwa. Nowe hasło powinno być silne, unikalne i przechowywane w menedżerze haseł. Po zalogowaniu czeka ekran powitalny z opcjami dodania źródła danych i utworzenia dashboardu. Plik konfiguracyjny /etc/grafana/grafana.ini zawiera sekcje domain, root_url i database - domyślnie sqlite3, a dla środowisk wysokiej dostępności PostgreSQL albo MySQL - oraz sekcję security z opcjami cookie_secure i csrf. Konfigurację najlepiej wersjonować w Git albo zarządzać nią przez Ansible'a.

Cały przepływ pracy w linii poleceń to sekwencja: instalacja, start usługi, włączenie autostartu, sprawdzenie statusu, otwarcie interfejsu, logowanie ze zmianą hasła i dodanie źródła danych. Wszystkie polecenia sprawdziliśmy na testowym serwerze i dają one identyczny wynik. Tak wygląda weryfikacja w praktyce.

Przechodzimy do praktyki: instalacja Grafany na Linuksie to jedna z prostszych czynności w całym narzędziu, bo cała platforma to pojedynczy binarny plik napisany w Go, uruchamiany jako usługa systemd. Na dystrybucjach opartych na Debianie i Ubuntu montaż sprowadza się do kilku poleceń - apt-get install -y grafana, a potem systemctl start grafana-server - a na RHEL czy Fedorze odpowiednikiem jest dnf. Wszystkie polecenia, które dziś omówimy, zweryfikowaliśmy na testowym środowisku, więc wyniki nie będą niespodzianką.

Po uruchomieniu usługi warto od razu włączyć autostart poleceniem systemctl enable i sprawdzić stan komendą systemctl status, a logi obejrzeć przez journalctl -u grafana-server -f. Interfejs otwieramy w przeglądarce pod adresem http://host:3000, a domyślny port zmienimy, gdy zajdzie potrzeba, w pliku /etc/grafana/grafana.ini. Pierwsze logowanie odbywa się parą admin/admin, którą system bezwzględnie każe zmienić, a jeśli środowisko wymaga wysokiej dostępności, domyślną bazę sqlite3 można zastąpić PostgreSQL albo MySQL.

Wyjaśnienie skrótów użytych na slajdzie:
FHS – Filesystem Hierarchy Standard – standard hierarchii systemu plików; Specyfikacja układu katalogów Linuksa definiująca położenie plików konfiguracyjnych (/etc/grafana).
APT – Advanced Package Tool – zaawansowane narzędzie pakietowe; Menedżer pakietów w systemach Debian/Ubuntu używany do oficjalnej instalacji pakietu Grafana.
RPM – Red Hat Package Manager – menedżer pakietów RPM; System zarządzania pakietami w dystrybucjach RHEL, CentOS i Rocky Linux.
CLI – Command Line Interface – interfejs wiersza poleceń; Konsola tekstowa wykorzystywana do zarządzania usługą grafana-server i instalacji wtyczek.
systemd – systemd system and service manager – menedżer systemu i usług systemd; Podsystem nadrzędny Linuksa zarządzający demonem Grafany w tle.

W środowiskach produkcyjnych zabrania się ręcznego konfigurowania połączeń w interfejsie przeglądarki. Źródła danych wdraża się deklaratywnie w plikach YAML w katalogu /etc/grafana/provisioning/datasources/, wersjonowanych w repozytorium kodu. Połączenie musi działać w trybie serwerowym (Proxy), co chroni dane uwierzytelniające przed ujawnieniem w przeglądarce klienta. Szczegółowe zasady opisuje dokumentacja provisioningu Grafana.

Zanim na ekranie pojawi się choćby jeden wykres, Grafana musi mieć skąd brać dane, dlatego skonfigurowanie pierwszego źródła danych to pierwszy realny krok po instalacji. Przepływ wygląda znajomo: wchodzimy do konfiguracji, dodajemy źródło typu Prometheus, podajemy adres serwera, testujemy połączenie i zapisujemy ustawienia. Do wyboru mamy tryb proxy albo tryb bezpośredni, z opcjami TLS i uwierzytelniania podstawowego, a na koniec możemy oznaczyć źródło jako domyślne. Pamiętaj, że bez poprawnie działającego źródła żaden panel nie zadziała - to pierwsze „hello world" integracji Grafany z Prometheusem.

Kroki zaczynamy od wyboru typu źródła. Pod ikoną zębatki znajdujemy Configuration, następnie Data Sources i przycisk Add. Na liście obok Prometheusa dla metryk znajdziesz Loki dla logów, Tempo dla śladów, a także MySQL, PostgreSQL, InfluxDB, CloudWatch, Azure Monitor, Elasticsearch, Jaeger czy Zipkin. Typ źródła determinuje język zapytań, którym będziesz się w nim posługiwać: Prometheus przynosi PromQL, Loki - LogQL, Tempo - TraceQL, a bazy danych - znajomy SQL. Od tej decyzji zależy też, jakie funkcje zobaczysz później w edytorze zapytań, więc już na starcie warto wiedzieć, czego faktycznie szukasz.

Następnie podajemy adres serwera. W środowisku Kubernetes wpisujesz nazwę usługi w klastrze, na przykład `http://prometheus:9090`, a przy instalacji na tym samym hoście `http://localhost:9090`. Jeśli na Prometheusie skonfigurowano TLS albo uwierzytelnianie, uzupełniamy odpowiednie pola. Teraz kluczowa decyzja - tryb dostępu: domyślny proxy sprawia, że to serwer Grafany wysyła zapytania do Prometheusa w imieniu przeglądarki, co ułatwia bezpieczeństwo, obsługę CORS i scentralizowane uwierzytelnianie. Tryb bezpośredni (direct) powoduje, że przeglądarka łączy się z Prometheusem wprost - wymaga konfiguracji CORS i w praktyce nie jest zalecany w produkcji. Wybieraj proxy, chyba że masz naprawdę dobrą przyczynę, żeby tego nie robić.

Po wypełnieniu pól naciskamy Save & Test, który wysyła do Prometheusa proste zapytanie i natychmiast pokazuje wynik. Zielony komunikat „Data source is working" oznacza sukces. Gdy coś poszło nie tak, komunikat błędu prowadzi nas do źródła problemu: connection refused mówi, że Prometheus w ogóle nie odpowiada, 401 że uwierzytelnianie się nie zgadza, 404 że adres jest po prostu zły, a błędy TLS wskazują na certyfikaty. Taki natychmiastowy feedback skraca debugowanie z minut do sekund - korzystaj z niego, zamiast zgadywać. Jeśli nadal nie działa, zajrzyj do logów Grafany, sprawdź łączność sieciową z poziomu serwera i zweryfikuj certyfikaty.

Na koniec zapisujemy źródło i ewentualnie oznaczamy je jako domyślne - wtedy nowe panele będą z niego korzystać automatycznie, bez ręcznego wybierania. Po zapisaniu źródło pojawia się w rozwijanej liście w edytorze zapytań każdego panelu. Co istotne, jeden dashboard może łączyć wiele źródeł: jeden panel z zapytaniem PromQL, drugi z LogQL, trzeci z SQL. Właśnie w tym tkwi siła Grafany - wiele źródeł w jednym, spójnym widoku.

Terminologia: data source configuration (konfiguracja źródła danych), health check (sprawdzenie zdrowia), default data source (domyślne źródło), access mode (tryb dostępu), proxy vs direct (proxy lub bezpośrednio), TLS settings (ustawienia TLS).

Zanim na ekranie pojawi się pierwszy wykres, Grafana musi mieć skąd pobierać dane, dlatego konfiguracja źródła danych to pierwszy realny krok po instalacji. Bez poprawnie działającego źródła żaden panel nie odpowie, więc warto przejść tę drogę dokładnie: wybór typu, wskazanie adresu serwera, decyzja o trybie dostępu i test połączenia. Traktujmy to jako pierwsze powitanie Grafany z Prometheusem, czyli fundament, na którym stoją wszystkie kolejne slajdy poświęcone zapytaniom i dashboardom.

Proces zaczynamy w menu Configuration, Data Sources i przycisku Add, gdzie obok Prometheusa dla metryk znajdziemy Loki dla logów, Tempo dla śladów oraz całą rodzinę baz i chmur. Adres serwera w klastrze to najczęściej http://prometheus:9090. Kluczowa jest decyzja o trybie dostępu: domyślny proxy sprawia, że zapytania do Prometheusa wysyła serwer Grafany, a nie przeglądarka, co jest bezpieczniejsze i prostsze w produkcji. Przycisk Save & Test daje natychmiastową odpowiedź - zielony komunikat albo błąd typu connection refused czy 401.

Wyjaśnienie skrótów użytych na slajdzie:
REST – Representational State Transfer – architektura interfejsu REST; Styl architektury sieciowej, w którym Grafana odpytuje punkty końcowe baz telemetrycznych.
TLS – Transport Layer Security – bezpieczeństwo warstwy transportowej; Kryptograficzny protokół szyfrujący połączenie pomiędzy serwerem Grafany a bazą danych.
HTTPS – Hypertext Transfer Protocol Secure – bezpieczny protokół HTTP; Szyfrowany kanał komunikacyjny chroniący przesyłane zapytania analityczne.
IP – Internet Protocol – protokół internetowy; Adres sieciowy węzła udostępniającego usługi bazy danych lub interfejs telemetryczny.
DNS – Domain Name System – system nazw domenowych; Usługa tłumacząca nazwy domenowe źródeł danych na adresy IP wewnątrz klastra.

Pierwszy dashboard powstaje iteracyjnie - od pustego ekranu do zapisanego, wersjonowanego pulpitu. Cały przepływ to cztery kroki: dodajemy panel, piszemy zapytanie PromQL, wybieramy wizualizację i zatwierdzamy wynik, a na końcu zapisujemy dashboard z tytułem, folderem, tagami i opisem zmian. Do dyspozycji mamy przeglądarkę metryk z autouzupełnianiem, historię wersji i organizację folderami. Ten przepływ będzie Ci towarzyszył setki razy w codziennej pracy, warto więc opanować go dokładnie na tym slajdzie.

Zaczynamy od dodania panelu. W prawym górnym rogu wybieramy "+" i opcję dodania panelu, co otwiera edytor z dwiema kolumnami: po lewej zapytania, po prawej wizualizacja. W edytorze zapytań piszemy PromQL; przeglądarka metryk pomaga przez Ctrl+Space, a skrót Shift+Enter natychmiast uruchamia zapytanie. Wizualizacja domyślnie to Time series, ale możesz ją zmienić na Stat, Gauge, Bar gauge, Table, Heatmap, a także Logs czy Traces. Przycisk Apply wstawia panel na dashboard, a praca jest w pełni iteracyjna: zmieniasz zapytanie, zatwierdzasz, dopracowujesz wygląd i zatwierdzasz ponownie. Traktuj ten edytor jak laboratorium - dokładnie tu uczysz się, co pokazuje każda metryka.

Kluczowym ułatwieniem jest autouzupełnianie, czyli coś na wzór podpowiedzi z IDE. Wciśnięcie Ctrl+Space w polu PromQL wywołuje listę nazw metryk, na przykład http_requests_total, etykiet takich jak job, instance czy handler, a także funkcji - rate, sum, histogram_quantile. Gotowy wzorzec zapytania wygląda wtedy mniej więcej tak: `rate(http_requests_total[5m])`. Ta pomoc nie tylko przyspiesza pisanie, ale też chroni przed literówkami i - co ważniejsze - pozwala odkrywać, jakie dane są w systemie naprawdę dostępne.

Gdy dashboard nabierze kształtu, zapisujemy go przyciskiem Save. Tytuł podajemy opisowo - na przykład „API Service - RED Metrics" - a folder wybieramy według schematu zespół, usługa lub środowisko. Tagi, takie jak red, api, slo czy noc, ułatwią późniejsze przeszukiwanie, a opis zmian w stylu komentarza Git - "Add CPU panel for API service" - powinien zawsze mówić, co konkretnie zmieniliśmy. Dlaczego to ważne? Bo historia wersji, dostępna pod ikoną zegara, pokazuje kto, co i kiedy zmienił, a jednym kliknięciem można wrócić do poprzedniej wersji. To jednocześnie ślad audytowy i siatka bezpieczeństwa.

Na koniec organizacja folderami, czyli swoista taksonomia dashboardów. Foldery układamy per zespół, środowisko lub usługa - team-backend, team-frontend, infra, business - i do każdego przypisujemy uprawnienia: zespół A edytuje swoje katalogi, zespół B ma dostęp tylko do odczytu. W interfejsie można szukać dashboardów po folderach i tagach. Takie uporządkowanie zapobiega gromadzeniu wszystkiego w katalogu głównym i sprawia, że zarządzanie setkami pulpitów pozostaje praktyczne.

Terminologia: add panel (dodaj panel), query editor (edytor zapytań), visualization (wizualizacja), save dashboard (zapisz pulpit), folder (folder), tags (tagi), version history (historia wersji), provisioning (aprowizacja).

Mając działające źródło, budujemy pierwszy dashboard - od pustego ekranu po zapisany, wersjonowany pulpit. Cały przepływ to iteracyjna pętla, która będzie towarzyszyć państwu w codziennej pracy, dlatego warto opanować ją właśnie teraz: dodać panel, napisać zapytanie, wybrać wizualizację, zatwierdzić wynik i zapisać całość z metadanymi. Na koniec omówimy jeszcze organizację dashboardów w folderach i działanie historii wersji, bo o uporządkowaniu pulpitów myśli się zwykle za późno.

Edytor panelu dzieli ekran na dwie kolumny - po lewej zapytania, po prawej wizualizacja - a autouzupełnianie po Ctrl+Space podpowiada nazwy metryk, etykiet i funkcji, zupełnie jak w środowisku programistycznym. Przy zapisie warto podać opisowy tytuł, folder według schematu zespół, usługa czy środowisko, tagi takie jak red albo slo oraz opis zmiany w stylu komentarza Git. Dzięki temu historia wersji dostępna pod ikoną zegara pokazuje, kto, co i kiedy zmienił, i cofa zmianę jednym kliknięciem.

Wyjaśnienie skrótów użytych na slajdzie:
JSON – JavaScript Object Notation – notacja obiektowa JavaScript; Format plikowy, w którym przechowywana jest cała definicja struktury pulpitu Grafany.
GUI – Graphical User Interface – graficzny interfejs użytkownika; Środowisko projektowania układu paneli metodą przeciągnij i upuść (drag & drop).
PromQL – Prometheus Query Language – język zapytań Prometheus; Język definiujący serie danych prezentowane na poszczególnych wykresach panelu.
TSDB – Time Series Database – baza danych szeregów czasowych; Podsystem, z którego pobierane są dane dla nowo utworzonych paneli analitycznych.
UI – User Interface – interfejs użytkownika; Warstwa prezentacji konfiguracji panelu, tytułu, osi i legendy.

Rola zmiennej $__rate_interval w Grafanie: Tradycyjnym problemem początkujących było wpisywanie w zapytaniu PromQL sztywnego okna czasowego, np. rate(http_requests_total[1m]). Jeśli użytkownik oddalił wykres do skali 30 dni, pojedynczy piksel na ekranie reprezentował kilka godzin danych. Dochodziło wówczas do zjawiska aliasingu (próbkowania rzadszego niż częstotliwość danych) i wykres stawał się poszarpany lub znikał. Grafana wprowadziła wbudowaną zmienną $__rate_interval, która dynamicznie dopasowuje długość okna do rozdzielczości ekranu i interwału pobierania danych, gwarantując idealną gładkość i matematyczną poprawność wykresów w każdej skali.

Panel Time series to najczęściej używana wizualizacja w Grafanie i podstawowe narzędzie operacyjnego dashboardu - to właśnie na nim widzisz trendy metryk w czasie. Jego potencjał buduje kilka ważnych elementów: globalny selektor czasu wraz ze zmiennymi $__range i $__interval w zapytaniach, zmienne templatingowe do dynamicznego filtrowania, konfiguracja osi Y z jednostkami i skalą logarytmiczną oraz Query Inspector do debugowania. To zestaw, z którego korzystasz przez większość czasu pracy nad dashboardami, więc poznajmy go dokładnie.

Zaczynamy od zakresu czasu. W górnym pasku dashboardu wybierasz zakres względny - ostatnie 1h, 6h, 24h, 7d czy 30d - albo konkretny przedział od-do; przyciski przesunięcia pozwalają szybko porównać teraz z godziną lub dniem temu. To jednak dopiero połowa historii, bo wybrany zakres trzeba jeszcze przenieść do zapytania. Służą do tego zmienne $__range i $__interval: `rate(http_requests_total[$__interval])` samo dostosowuje rozdzielczość do szerokości wykresu - na szerszym zakresie punktów jest proporcjonalnie mniej, co przyspiesza zapytanie. Innymi słowy, nie musisz ręcznie zmieniać okna zapytania przy każdej zmianie zakresu w interfejsie.

Kolejne ułatwienie to zmienne templatingowe, czyli dynamiczne filtry. Na górze dashboardu umieszczasz rozwijane listy, na przykład $instance = label_values(node_cpu_seconds_total, instance), które pobierają realne wartości etykiety instance z metryk. Możesz wybierać wiele naraz, dodać opcję All albo filtrować wyrażeniem regularnym. W podobny sposób definiujesz $job, $handler czy $environment. W efekcie jeden dashboard obsługuje wszystkie środowiska, usługi i instancje - to zasada DRY, powtórz swoją logikę raz, a nie pięćdziesięciokrotnie. Wartości zmiennych możesz odświeżać przy załadowaniu strony, przy zmianie zakresu czasu lub ręcznie.

Teraz konfiguracja osi i legendy, czyli dopracowanie czytelności. Dla osi Y wybierasz jednostkę: percentunit dla wartości od zera do jedności, percent_0_1 dla ułamków procentowych, a także bytes, Bps, s, ms czy reqps, z automatycznym formatowaniem przedrostków SI - k, M, G - które samemu nie musisz przeliczać. Sztywne granice osi, na przykład 0-100 procent dla CPU, stabilizują wykres, a skala logarytmiczna ratuje tam, gdzie wartości rozkładają się wykładniczo, jak choćby przy latencji. Legenda konfiguruje się pod kątem położenia - prawa, dolna albo tabela - oraz widocznych statystyk, takich jak min, max, średnia czy wartość bieżąca. Każda z tych opcji zmniejsza obciążenie poznawcze operatora.

Ostatni element to Query Inspector, kryjący się pod ikoną oka w panelu. Inspektor pokazuje surowe dane w tabeli, czas wykonania zapytania, pełne żądanie i odpowiedź HTTP do Prometheusa oraz plan wykonania - ile serii przetworzono, ile bloków, jaki jest szacowany czas. Dzięki niemu odpowiadasz na pytania, których nie widać na wykresie: dlaczego panel jest pusty albo dlaczego zapytanie działa wolno. To narzędzie równie użyteczne na produkcji, jak podczas pracy nad dashboardem.

Terminologia: time series panel (panel szeregu czasowego), legend (legenda), variables (zmienne/templating), query inspector (inspektor zapytań), time range (zakres czasu), $__range i $__interval (zmienne zakresu i kroku).

Panel Time series to najczęściej używana wizualizacja w Grafanie i podstawowe narzędzie każdego operacyjnego dashboardu - to właśnie na wykresie czasu widać trendy metryk w wybranym oknie. Jego pełna moc wymaga jednak znajomości kilku mechanizmów, które dziś omówimy: globalnego selektora czasu, zmiennych odpowiadających za dynamiczne filtrowanie, formatowania jednostek z przedrostkami SI, legendy oraz inspektora zapytań. To zestaw, z którego korzystacie państwo przez większość czasu spędzanego nad dashboardami, więc poznajmy go w szczegółach.

Wybrany w górnym pasku zakres czasu przenosimy do zapytania zmiennymi $__range i $__interval, dzięki czemu rozdzielczość wykresu sama dopasowuje się do szerokości okna. Zmienne templatingowe, jak $instance pobierane funkcją label_values, pozwalają jednym rozwijanym menu obsłużyć wszystkie środowiska i instancje. Jednostki osi - percentunit, bytes czy ms - formatują się automatycznie z przedrostkami SI, a skala logarytmiczna ratuje przy wartościach wykładniczych. Gdy coś nie gra, Query Inspector pokaże surowe dane i czas wykonania zapytania.

Wyjaśnienie skrótów użytych na slajdzie:
UTC – Coordinated Universal Time – uniwersalny czas koordynowany; Standardowy czas referencyjny na osi poziomej wykresów eliminujący błędy stref czasowych.
ISO – International Organization for Standardization – Międzynarodowa Organizacja Normalizacyjna; Standard ISO 8601 określający uniwersalny format zapisu daty i czasu na osiach wykresów.
TSDB – Time Series Database – baza danych szeregów czasowych; Silnik optymalizujący pobieranie przedziałów czasowych dla wybranego zakresu w prawym górnym rogu.
PromQL – Prometheus Query Language – język zapytań Prometheus; Silnik obliczeniowy zwracający macierze próbek czasowych dla wykresów liniowych.
FPS – Frames Per Second – klatki na sekundę; Płynność renderowania wektorowych wykresów w przeglądarce internetowej inżyniera.

W panelach platformy Grafana nie należy stosować sztywnego okna czasowego (np. [5m]), ponieważ przy zmianie przedziału analizowanego czasu krok próbkowania (step) może przekroczyć wielkość okna, powodując błędy aliasingu lub zniknięcie wykresu. Należy obligatoryjnie stosować wbudowaną zmienną $__rate_interval:

sum by (mode) (rate(node_cpu_seconds_total{instance="$instance"}[$__rate_interval]))

Zmienna ta automatycznie przyjmuje wartość równą maksimum z interwału odpytywania (scrape_interval) powiększonego o krok próbkowania, gwarantując ciągłość i poprawność statystyczną wykresu.

Edytor zapytań w Grafanie daje inżynierowi SRE doświadczenie zbliżone do pracy w IDE: autouzupełnianie po Ctrl+Space, natychmiastowe uruchamianie po Shift+Enter, podgląd wyników w tabeli albo na wykresie pod edytorem oraz iteracyjne dopracowywanie zapytań. To nie jest zwykłe pole tekstowe - to samo narzędzie, w którym spędzasz zdecydowaną większość czasu analitycznego, więc warto poznać jego możliwości na wstępie, zanim przejdziemy do składni samego PromQL.

Zacznijmy od autouzupełniania. Gdy zaczynasz wpisywać nazwę metryki i wciskasz Ctrl+Space, podpowiedzi pojawiają się natychmiast - http_requests_total, node_cpu_seconds_total. Gdy piszesz `{job=`, edytor podpowiada dostępne wartości etykiety, na przykład api, node czy cadvisor. A gdy wpisujesz `rate(`, podpowiada składnię i parametry funkcji. Takie podpowiedzi w stylu IDE chronią przed literówkami, pomagają odkryć, jakie metryki i funkcje są dostępne, a przy okazji uczą składni - niejako podczas samej pracy.

Drugim filarem edytora jest natychmiastowy podgląd wyników. Skrót Shift+Enter albo przycisk Run uruchamia zapytanie, a wynik pojawia się pod edytorem: tabela dla wektora instant, czyli bieżących wartości per seria, albo wykres dla wektora range, czyli trendu w czasie. Praca wygląda jak pętla: zmieniasz filtr etykiet, uruchamiasz, oglądasz wynik, dopracowujesz i znowu uruchamiasz. W ten sposób uczysz się przez eksperymentowanie, a nie przez czytanie dokumentacji - i to jest dokładnie ta różnica, która przyspiesza naukę.

W samym PromQL znajdziesz agregacje i funkcje budujące użyteczne serie. `sum by (job) (rate(http_requests_total[5m]))` da całkowite RPS w podziale na joby; `histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket{job="api"}[5m])))` wyliczy latencję p95 dla usługi api; a `topk(10, sum by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m])))` wskaże dziesięć instancji o najwyższym użyciu CPU. Zauważ, że każde z tych złożonych zapytań składa się z prostych klocków - to właśnie kompozycja funkcji jest sercem PromQL.

Na koniec warstwa prezentacji, czyli dopasowanie wyniku do odbiorcy. Alias w postaci `{{instance}} - {{job}}` tworzy dynamiczne nazwy serii na podstawie ich etykiet. Jednostki - percentunit, percent_0_1, bytes, Bps, s, ms, reqps czy ops - formatują się automatycznie z przedrostkami SI, a liczba miejsc po przecinku wpływa na czytelność. Progi kolorów potrafią zaś rysować na wykresie linie SLO albo ostrzeżenia. Pamiętaj: warstwa prezentacji ma służyć odbiorcy, nie autorowi - więc zawsze pytaj, kto ma z tego wykresu podjąć decyzję.

Szczegółowy PromQL rozwinie się już za chwilę: slajdy 11-15 omawiają kolejno selekcję wektorów, filtry etykiet, agregacje, funkcje czasu i progi warunkowe. To celowe stopniowanie trudności - uczymy się krok po kroku, a nie wszystkiego naraz.

Edytor zapytań PromQL w Grafanie to nie zwykłe pole tekstowe, lecz narzędzie pracujące jak środowisko programistyczne: autouzupełnianie po Ctrl+Space, natychmiastowe uruchamianie po Shift+Enter, podgląd wyników tuż pod edytorem i pełna iteracja dopracowywania. To w nim spędzicie państwo zdecydowaną większość czasu analitycznego, dlatego warto poznać jego możliwości, zanim przejdziemy do samej składni PromQL. Ten slajd ma charakter praktyczny - uczy pisać zapytania szybko i bez literówek, zamiast wracać do dokumentacji przy każdej funkcji.

Na początek najważniejsze złożenia, które będą nam towarzyszyć do końca kursu. sum by (job) z rate() da całkowitą liczbę żądań na sekundę w podziale na usługi, histogram_quantile z sum by (le) wyciągnie percentyl latencji wprost z bucketów histogramu, a funkcja topk wskaże instancje o największym użyciu CPU. Alias w formie {{instance}} - {{job}} buduje czytelne nazwy serii z ich etykiet, a jednostki i progi kolorów tworzą warstwę prezentacji dopasowaną do odbiorcy, na przykład z narysowaną linią SLO na wykresie.

Wyjaśnienie skrótów użytych na slajdzie:
PromQL – Prometheus Query Language – język zapytań Prometheus; Język zapytań łączący etykiety, wektory chwilowe i funkcje matematyczne na panelach Grafany.
TSDB – Time Series Database – baza danych szeregów czasowych; Baza danych zwracająca ustrukturyzowane serie danych w formacie oczekiwanym przez silnik wizualizacji.
SDK – Software Development Kit – pakiet programistyczny; Zestaw narzędzi w bibliotekach aplikacji zapewniający jednolite nazewnictwo metryk PromQL.
API – Application Programming Interface – interfejs programistyczny; Interfejs Prometheus HTTP API wywoływany przez moduł renderujący platformy Grafana.
HTTP – Hypertext Transfer Protocol – protokół HTTP; Protokół komunikacji bezstanowej przenoszący zapytania telemetryczne w formacie JSON.

Selekcja konkretnych serii spośród milionów dostępnych to w PromQL odpowiednik klauzuli WHERE w SQL: musimy umieć odróżnić zapytanie natychmiastowe od zakresowego, dobrze posługiwać się selektorami etykiet - dokładnymi, regexowymi i z negacją - oraz modyfikatorami czasu @ i offset. To jest alfabet PromQL. Bez pewnej selekcji nie ma agregacji, alertów ani dashboardów, dlatego każdy inżynier SRE powinien opanować ten slajd bezbłędnie.

Zacznijmy od dwóch typów wektorów. Zapytanie `metric`, na przykład `up{job="node"}`, zwraca wektor natychmiastowy, czyli jedną wartość per seria w tej chwili - wynik wygląda mniej więcej tak: `up{instance="host:9100",job="node"} 1`. Zapytanie `metric[5m]` zwraca natomiast wektor zakresowy, czyli macierz (matrix) próbek z okna pięciu minut; liczba punktów zależy od interwału scrapowania - przy zbieraniu co 15 sekund będziemy mieć 20 punktów na serię. To rozróżnienie jest kluczowe, bo funkcje rate(), increase() i histogram_quantile() przyjmują wyłącznie wektor zakresowy - zapytanie rate bez [5m] kończy się błędem składni.

Drugi element to selektory etykiet w nawiasach klamrowych. `{job="api"}` dopasowuje etykietę dokładnie, `{job!="api"}` neguje dopasowanie, `{job=~"api.*"}` używa wyrażenia regularnego w składni RE2, a `{job!~"api.*"}` to negacja wyrażenia regularnego. Warunki łączymy w koniunkcję: `{job="api", method=~"GET|POST", handler="/api/users"}` znaczy dokładnie tyle, ile się wydaje - wszystkie etykiety muszą pasować naraz. Selekcja działa jak WHERE w SQL, tyle że na etykietach. Pamiętaj jedną pułapkę wydajnościową: regex jest wolniejszy niż dokładne dopasowanie, bo silnik musi przejść wszystkie identyfikatory serii, więc tam, gdzie to możliwe, używaj znaku równości.

Trzecim elementem są modyfikatory czasu. `metric @ 1699900000` zwraca wartość metryki w konkretnym momencie podanym w sekundach od epoki Unix. `metric offset 1h` cofa widok o godzinę - tak porównujesz teraz z przeszłością bez zmiany zakresu czasu, a `metric offset 1w` cofa cię o tydzień, co świetnie sprawdza się w analizie sezonowości. Te konstrukcje przydają się w alertach porównujących ze stanem bazowym oraz w dashboardach z porównaniami.

Na koniec trzy najważniejsze wzorce praktyczne. `up{job="node"}` to sprawdzenie zdrowia targetu - jego wartość 1 oznacza, że zbieranie działa. `rate(http_requests_total{job="api"}[5m])` daje przepustowość per seria, a `histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{job="api"}[5m]))` wylicza latencję p99. To trójka zdrowie, szybkość, kwantyl - opanuj ją, a pokryjesz większość codziennej pracy z dashboardami.

Terminologia: instant query (zapytanie natychmiastowe), range query (zapytanie zakresowe), vector (wektor), matrix (macierz), label matchers (selektory etykiet), offset (przesunięcie czasowe), @ modifier (modyfikator znacznika czasu), metric browser (przeglądarka metryk), time travel (podróż w czasie).

Selekcja właściwych serii spośród milionów dostępnych to w PromQL odpowiednik klauzuli WHERE w SQL - i właśnie od niej zaczynamy naukę samego języka. U podstaw leży rozróżnienie dwóch rodzajów wektorów: chwilowego, który zwraca jedną wartość per seria na teraz, oraz zakresowego, który daje ciąg próbek z okna czasu. Ten wybór przesądza o poprawności wszystkiego, co zbudujemy dalej, bo funkcje takie jak rate() czy increase() przyjmują wyłącznie wektor zakresowy, a zapytanie rate bez okna kończy się błędem składni.

Zapytanie up{job="node"} zwraca wektor chwilowy z wartością jeden, gdy zbieranie danych działa, a dopisanie [5m] zamienia wynik w macierz próbek - przy scrapingu co piętnaście sekund to dwadzieścia punktów na serię. Selektorami etykiet zawężamy zbiór przez równość, nierówność, wyrażenie regularne RE2 lub jego negację, a warunki łączymy koniunkcją. Modyfikatory czasu pozwalają z kolei porównywać teraz z przeszłością: offset 1h albo 1w świetnie sprawdza się w analizie sezonowości oraz w alertach ze stanem bazowym.

Wyjaśnienie skrótów użytych na slajdzie:
CPU – Central Processing Unit – procesor; Główny zasób obliczeniowy serwera, którego metryki podlegają filtracji według trybów pracy.
RAM – Random Access Memory – pamięć operacyjna; Zasób pamięciowy monitorowany pod kątem podziału na pamięć wolną, dostępną i bufory.
IOPS – Input/Output Operations Per Second – operacje wejścia/wyjścia na sekundę; Metryka wydajności dyskowej wizualizowana na dedykowanych wykresach obciążenia macierzy.
NIC – Network Interface Card – karta sieciowa; Interfejs sieciowy, dla którego selekcjonuje się metryki odebranych i wysłanych pakietów.
MTU – Maximum Transmission Unit – maksymalna jednostka transmisji; Parametr interfejsu wpływający na statystyki fragmentacji i odrzuconych ramek sieciowych.

Precyzyjna selekcja to w PromQL narzędzie chirurga: wyrażenia regularne w etykietach, logika boolowska, zejście do pojedynczej instancji i arytmetyka wektorowa. Z klasycznych pułapek musicie pamiętać dwie: selektory etykiet łączy się wyłącznie koniunkcją, a alternatywę OR trzeba symulować operatorem or albo wyrażeniem regularnym; poza tym arytmetyka na wektorach działa tylko przy zgodnych etykietach. Opanuj te niuanse, a zamiast grubego topora będziesz trzymać precyzyjny skalpel.

Zacznijmy od wyrażeń regularnych w etykietach. `{handler=~"/api/.*", status=~"5.."}` wybiera endpointy zaczynające się od /api/ i jednocześnie statusy 5xx. PromQL używa składni RE2, znanej z projektu Google: gwiazdka `.*` oznacza dowolne znaki, kropka dowolny pojedynczy znak, `|` pełni rolę alternatywy, `^` i `$` pilnują początku i końca, a `[]` definiuje klasy znaków. Pamiętaj o jednej rzeczy: regex działa wolniej niż dokładne dopasowanie, bo przeszukuje wszystkie identyfikatory serii, dlatego stosuj go tam, gdzie naprawdę jest potrzebny. Zamiast negować wyjątki przez `!="/health"`, lepiej napisać dokładną listę: `handler=~"/api/(users|orders).*"`.

Druga pułapka to łączenie warunków. W nawiasach klamrowych warunki łączą się koniunkcją - `{job="api", method="GET"}` znaczy: job to api oraz method to GET. Alternatywy w selektorach etykiet nie ma w ogóle, a zapis `{job="api" || job="web"}` to po prostu błąd składni. Masz trzy wyjścia: dwa osobne zapytania połączone operatorem or, na przykład `rate(...{job="api"}[5m]) or rate(...{job="web"}[5m])`; jeden wspólny regex `{job=~"api|web"}`; albo dwa osobne panele na dashboardzie. Każde z tych rozwiązań jest poprawne - wybór zależy od tego, czy wolisz czytelność, czy minimalizację liczby zapytań.

Trzeci praktyczny przykład to zejście do pojedynczej instancji: `rate(http_requests_total{instance="web-01:8080"}[5m])` filtruje wyłącznie po konkretnej instancji. To fundament drill-downu: z ogólnego dashboardu, pokazującego wszystkie instancje, klikasz w serię i przechodzisz do szczegółowego widoku jednej maszyny. W Grafanie ten przepływ automatyzują zmienne - wystarczy filtr `instance=~"$instance"`. Tak wygląda droga od ogólnego obrazu, przez szczegóły, do przyczyny problemu.

Ostatni element to arytmetyka wektorowa z operatorem zgodności wektorów, czyli vector matching. Operatory +, -, *, /, % i ^ działają między wektorami o zgodnych etykietach. Gdy zbiory etykiet po obu stronach się różnią, sterujesz dopasowaniem modyfikatorami ignoring(label) albo on(label), a modyfikator bool zamienia warunek porównania w wektor binarny 0/1. To zwykła matematyka na szeregach: `(cpu_user + cpu_system) / cpu_total * 100` daje procent użycia CPU. Zgodność etykiet to klucz do tego, by obliczenia były poprawne - kontrolujesz ją jawnie, a nie zakładasz.

Wszystkie przykłady z tego slajdu możesz wkleić od razu do eksploratora Prometheusa albo do trybu Explore w Grafanie i wykonać na własnym środowisku. W ten sposób dokumentacja przestaje być źródłem pozornych problemów „u mnie nie działa" wynikających z literówek - kopiujesz, wklejasz i widzisz taki sam wynik.

Precyzyjne zawężanie zbioru serii to filar każdego zapytania w PromQL - im więcej instancji, endpointów i środowisk dzieli jedną usługę, tym ważniejszy jest porządek w selektorach. Ten slajd rozwija wątek z poprzedniej części: zamiast obserwować pojedynczą metrykę, składamy teraz warunki na etykietach i łączymy wektory arytmetycznie. To właśnie ta warstwa decyduje o tym, czy panel pokaże obraz całego systemu, czy tylko fragment, który naprawdę nas interesuje, i czy liczba serii w wyniku pozostanie na tyle mała, by wykres pozostawał czytelny.

Wyrażenie `{handler=~"/api/.*", status=~"5.."}` łączy warunki regexowe dla ścieżki i kodu odpowiedzi, a składnia RE2 daje kropkę, gwiazdkę, kreskę pionową jako alternatywę oraz klasy znaków. W klamrach warunki łączą się koniunkcją, a ponieważ alternatywy OR w selektorach nie ma, symulujemy ją wspólnym wyrażeniem `{job=~"api|web"}` albo operatorem or. Regex jest wolniejszy niż dopasowanie dokładne, więc do pojedynczej instancji schodzimy raczej zapytaniem `{instance="host:9100"}`, a drill-down wspierają w Grafanie zmienne.

Wyjaśnienie skrótów użytych na slajdzie:
Regex – Regular Expression – wyrażenie regularne; Wzorzec dopasowania tekstu używany w selektorach Grafany do grupowania wielu instancji lub usług.
POSIX – Portable Operating System Interface – przenośny standard systemu operacyjnego; Standard składni wyrażeń regularnych wspierany przez silnik zapytań PromQL.
ASCII – American Standard Code for Information Interchange – amerykański standard kodowania znaków; Standard znaków dozwolonych w nazwach metryk i etykiet Prometheus.
PromQL – Prometheus Query Language – język zapytań Prometheus; Silnik interpretujący operatory logiczne (and, or, unless) oraz filtry etykiet.
TSDB – Time Series Database – baza danych szeregów czasowych; Pamięć masowa dokonująca indeksowania odwróconego etykiet na potrzeby szybkich filtrów.

Funkcje agregujące redukują wymiarowość danych - z setek serii per instancja i per endpoint schodzimy do kilku wskaźników per usługa czy per cały klaster. To swoiste oddalenie kamery: im wyżej podnosimy obiektyw, tym mniej szczegółów, ale za to większy, całościowy obraz. Do dyspozycji mamy sum, avg, max, min, count, stddev, topk, bottomk i quantile, a grupowanie by i without decyduje, które etykiety zostaną w wyniku. Mechanizm dopasowania wektorów pozwala z kolei łączyć wektory o różnych wymiarach. W ten sposób budujesz kluczowe KPI z surowych metryk.

Spójrzmy najpierw na same funkcje. `sum` sumuje wartości, `avg` liczy średnią, `max` i `min` wybierają wartości skrajne, `count` zlicza serie, `stddev` i `stdvar` mierzą rozproszenie, `topk(n, ...)` i `bottomk(n, ...)` wskazują serie o najwyższych i najniższych wartościach, a `quantile(φ, ...)` wyznacza kwantyl. Wszystkie funkcje przyjmują wektor - natychmiastowy albo zakresowy - i zwracają wektor o mniejszej liczbie serii oraz okrojonym zestawie etykiet. Dzięki temu dashboard nie tonie w miliardach linii, tylko pokazuje to, co naprawdę istotne.

Drugi kluczowy mechanizm to grupowanie by i without, które decyduje o kształcie wyniku. `sum by (job, instance) (...)` zachowuje etykiety job i instance, a sumuje wszystkie pozostałe wymiary, takie jak method czy handler. `sum without (instance) (...)` robi rzecz odwrotną - usuwa etykietę instance i agreguje pozostałe wartości. W praktyce by jawnie wymienia, co chcesz zachować, a without - co usunąć. To precyzyjna kontrola nad tym, jakie zagregowane serie trafią na wykres.

Teraz sklejanie wektorów o różnych wymiarach, czyli operator zgodności wektorów. Operatory arytmetyczne wymagają zgodnych etykiet po obu stronach. Gdy wektory się różnią, modyfikator ignoring(label) każe zignorować wybrane etykiety przy dopasowaniu - przydatne, gdy jedną stronę agregowałeś inaczej niż drugą - a modyfikator on(label) każe dopasowywać wyłącznie po wymienionych etykietach. To sedno semantyki łączenia: dokładnie wiesz, po czym sklejasz wektory o różnych wymiarach, zamiast zgadywać.

Na koniec trzy praktyczne wzorce. `sum by (job) (rate(http_requests_total[5m]))` daje całkowite RPS w podziale na joby. `topk(5, sum by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m])))` wybiera pięć instancji o największym użyciu CPU. A `count_values("status", http_requests_total)` zlicza, ile serii ma wartość 200, 404 czy 500, co buduje rozkład kodów statusu. To gotowe wzorce, które od razu można wkleić do dashboardów i reguł alertowych.

Terminologia: aggregation (agregacja), vector (wektor), by (grupuj), without (bez), ignoring (ignoruj), on (na), group_left (dołącz lewy), group_right (dołącz prawy), topk (top N), bottomk (bottom N), vector matching (dopasowanie wektorów).

Z setek, a przy dużych klastrach nawet tysięcy szczegółowych serii, agregacje budują kilka wskaźników, na których można oprzeć cały dashboard i alert. To odpowiednik oddalenia kamery: podnosimy obiektyw, tracimy część szczegółów, ale zyskujemy całościowy obraz jednej usługi albo całego środowiska. Bez tej redukcji wymiarowości żaden pulpit nie byłby czytelny, dlatego funkcje sum, avg czy topk wraz z poprawnym grupowaniem należą do najczęściej używanych mechanizmów PromQL i powracają dalej w regułach nagrywających.

Funkcje agregujące przyjmują wektor i zwracają mniejszy zbiór serii: sum sumuje wartości, avg liczy średnią, count zlicza serie, stddev mierzy rozproszenie, topk i bottomk wybierają serie skrajne, a quantile wyznacza kwantyl. O kształcie wyniku decyduje grupowanie - `sum by (job)` zachowuje etykietę job i sumuje pozostałe wymiary, a `sum without (instance)` usuwa wskazaną etykietę. Wzorzec `topk(5, sum by (instance) (...))` pozwala w jednym panelu wyróżnić pięć instancji o największym użyciu CPU, co od razu wskazuje maszynę wymagającą uwagi.

Wyjaśnienie skrótów użytych na slajdzie:
PromQL – Prometheus Query Language – język zapytań Prometheus; Język realizujący przestrzenne operacje agregacji (sum, avg, min, max, count, stddev) na klastrach.
CPU – Central Processing Unit – procesor; Zasób sprzętowy, którego obciążenie agreguje się pomiędzy rdzeniami i węzłami klastra.
RAM – Random Access Memory – pamięć operacyjna; Pamięć sumowana w skali całego środowiska obliczeniowego w celu oceny globalnego zapasu.
OS – Operating System – system operacyjny; Środowisko, którego instancje grupuje się za pomocą klauzuli 'by (instance)' lub 'by (job)'.
TSDB – Time Series Database – baza danych szeregów czasowych; Silnik optymalizujący przeliczanie wielowymiarowych agregacji na poziomie zapytań.

Statyczny próg procentowy wolnej przestrzeni dyskowej jest nieskuteczny przy gwałtownych wyciekach logów lub masowym imporcie danych. W monitoringu produkcyjnym wykorzystuje się funkcję ekstrapolacji liniowej predict_linear() w języku PromQL:

predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[4h], 24 * 3600) < 0

Zapytanie to analizuje dynamikę spadku wolnego miejsca z ostatnich 4 godzin i wyzwala ostrzeżenie, jeśli przy zachowaniu obecnego trendu partycja ulegnie całkowitemu zapełnieniu w ciągu najbliższych 24 godzin.

Funkcje czasu zamieniają surowy licznik, który sam w sobie rośnie bez końca, na sensowną, użyteczną szybkość: rate() podaje tempo na sekundę, increase() całkowity przyrost w zadanym oknie, a delta() zmianę wartości miernika. To jedyne funkcje, które rozumieją upływ czasu i radzą sobie z resetami liczników. Błędne zastosowanie - na przykład rate() na mierniku - daje mylące wyniki, fałszywe alerty i popsute dashboardy, dlatego różnice między tymi funkcjami warto znać naprawdę pewnie.

Zacznijmy od najważniejszej, czyli rate(). Wyrażenie `rate(counter[5m])` to średnia szybkość na sekundę w oknie pięciu minut. Funkcja potrafi obsłużyć resety: gdy licznik spada, na przykład po restarcie aplikacji, rate() nie interpretuje tego jako ujemnej szybkości, tylko odpowiednio ekstrapoluje wartości. Gdy pierwsza albo ostatnia próbka nie wypada dokładnie na granicy okna, także ekstrapoluje wynik na pełne okno. Ważne zastrzeżenie: funkcja jest przeznaczona wyłącznie dla liczników, a rate() na mierniku daje błędne rezultaty, bo mierniki nie są monotoniczne. To najczęściej używana funkcja w PromQL.

Drugi kandydat to increase(), czyli całkowity przyrost w oknie. `increase(counter[1h])` podaje, o ile wzrósł licznik w ostatniej godzinie - na przykład, ile żądań obsłużono łącznie. Wynik jest równoważny iloczynowi rate() i liczby sekund w oknie: `rate(...[1h]) * 3600`. Ta funkcja również obsługuje resety. Sprawdza się wszędzie tam, gdzie liczysz sumy: żądania w godzinie, bajty w dniu, błędy w tygodniu. Trzymaj się takiej zasady: do raportów wybierzesz increase, a do alertów rate.

Trzecia funkcja to delta(), przeznaczona dla mierników. `delta(gauge[1h])` podaje różnicę między ostatnią a pierwszą wartością miernika w oknie - czyli o ile zmieniła się wartość w ciągu godziny. To funkcja dla mierników, a nie liczników; przydaje się do zmian użycia pamięci, głębokości kolejki czy trendu zajętości dysku. Pokrewne funkcje to derivative(), czyli tempo zmian na sekundę dla mierników, idelta() dla dwóch ostatnich próbek oraz irate(), chwilowa szybkość z dwóch ostatnich punktów licznika, użyteczna przy szybko zmieniających się wartościach.

Praktyczny wzorzec podsumuje wszystko: `rate(http_requests_total{job="api"}[5m])` daje RPS per seria, czyli w podziale na instancje, metody i handlery, a `sum(rate(http_requests_total{job="api"}[5m]))` całkowite RPS dla całego joba. To najpopularniejszy wzorzec w PromQL - rate plus sum daje metrykę od razu nadającą się do podejmowania decyzji. Opanuj rate(), a zdobędziesz klucz do większości zapytań, jakie zobaczysz w tej dziedzinie.

Terminologia: rate (szybkość), increase (przyrost), delta (zmiana), derivative (pochodna), idelta (chwilowa delta), irate (chwilowe tempo), range vector (wektor zakresowy), extrapolation (ekstrapolacja), counter reset handling (obsługa resetów licznika).

Surowy licznik rośnie bez końca i sam w sobie niewiele mówi - dopiero funkcje czasu zamieniają go na szybkość na sekundę albo przyrost w oknie, których można użyć w alertach i na wykresach. Którą funkcję wybierzemy, zależy od typu metryki: rate() i increase() dotyczą wyłącznie liczników, delta() dotyczy mierników, a pomyłka w tej klasyfikacji należy do najczęstszych błędów logicznych w zapytaniach, prowadząc do fałszywych alarmów i zniekształconych paneli, które w dodatku trudno później zdiagnozować.

Fundamentem jest rate(): `rate(counter[5m])` daje średnią szybkość na sekundę w oknie pięciu minut, obsługując resety i ekstrapolację próbek poza granicę okna. `increase(counter[1h])` podaje całkowity przyrost, równoważny pomnożeniu rate() przez liczbę sekund, i nadaje się do podsumowań dziennych czy tygodniowych. delta() liczy różnicę między skrajnymi wartościami miernika, a pokrewne irate() czy derivative() sprawdzają się przy szybkozmiennych licznikach i trendach wartości zmiennych.

Wyjaśnienie skrótów użytych na slajdzie:
TSDB – Time Series Database – baza danych szeregów czasowych; Baza przechowująca dane historyczne wykorzystywane przez funkcje przesunięcia czasowego (offset).
WAL – Write-Ahead Log – dziennik zapisu z wyprzedzeniem; Mechanizm transakcyjny zabezpieczający próbki czasowe przed awarią zasilania.
RAM – Random Access Memory – pamięć operacyjna; Pamięć podręczna serwera przyspieszająca ewaluację funkcji predykcyjnych w czasie rzeczywistym.
I/O – Input/Output – operacje wejścia/wyjścia; Operacje dyskowe generowane podczas odczytu długich zakresów czasowych z bloków archiwalnych.
PromQL – Prometheus Query Language – język zapytań Prometheus; Język udostępniający funkcje rate, irate, increase, delta, deriv oraz predict_linear.

To slajd, na którym metryka zamienia się w decyzję: ciągłą wartość przekształcamy na binarny sygnał - ALERT albo OK. Robi się to przez progowanie z modyfikatorem bool i odpowiednie przygotowanie wyrażeń pod reguły alertujące. Kluczowe jest rozróżnienie dwóch zachowań: czyste filtrowanie zwraca tylko serie powyżej progu, a wektor boolowski 0/1 utrzymuje wszystkie serie. Od tej decyzji zależy, czy alert działa na poziomie pojedynczej serii - na przykład konkretnej instancji - czy globalnie.

Rozłóżmy zatem modyfikator bool. Wyrażenie `vector > scalar`, na przykład `rate(...) > 0.01`, filtruje - w wyniku zostają wyłącznie serie spełniające warunek, a reszta znika. Wyrażenie `vector > bool scalar`, czyli `rate(...) > bool 0.01`, buduje wektor boolowski: każda seria otrzymuje 1, gdy spełnia warunek, albo 0, gdy go nie spełnia. To istotne rozróżnienie dla reguł alertowych: bez modyfikatora bool reguła jest aktywowana, gdy każda zwrócona seria przekracza próg, ale serie poniżej progu w ogóle nie istnieją w wyniku; z modyfikatorem bool reguła jest aktywowana, gdy dowolna seria przyjmuje wartość 1. Od tego wyboru zależy wprost semantyka twojego alertu.

W praktyce progowanie wygląda następująco. `rate(http_requests_total{status=~"5.."}[5m]) > bool 0.01` daje jedynkę dla serii, których wskaźnik błędów przekracza jeden procent, i zero dla pozostałych. Taka reguła to alert na poziomie serii - dla konkretnej instancji czy endpointu. Gdy potrzebujesz alertu globalnego, agregujesz przed porównaniem: `sum(...) > bool 0.01`. W ten sposób precyzyjnie definiujesz moment, w którym system ma cię zaalarmować - a nie zostawiasz tego domysłom.

Do samych reguł warto przygotować się wcześniej. W regule alertu lepiej odwołać się do uprzednio prekomputowanej reguły nagrywającej, na przykład `job:error_rate:rate5m`, niż powtarzać surowe zapytanie w każdym miejscu. Adnotacje z szablonowaniem podmieniają z kolei w treści komunikatu wartości - `summary: "High error rate on {{ $labels.instance }}"` zastąpi `{{ $labels.instance }}`, `{{ $labels.job }}` i `{{ $value }}` konkretnymi danymi. W ten sposób dyżurny od razu wie: kogo dotyczy problem - instancja, czego dotyczy - job, i jaka jest wielkość - wartość. Reguły nagrywające prekomputują wynik, bool daje precyzyjne progi, a szablonowanie czyni alerty od razu nadającymi się do działania.

Na koniec wstawmy to w szerszy kontekst, do którego wrócimy w dalszej części kursu: pełny potok alertowania wygląda tak - Prometheus zlicza reguły nagrywające, następnie ocenia reguły alertujące (wyrażenie, czas utrzymania, etykiety, adnotacje), wysyła zdarzenie do Alertmanagera, a ten deduplikuje, grupuje, tłumi i kieruje powiadomienia do punktów kontaktowych - Slacka, poczty, PagerDuty czy webhooków - skąd trafiają do dyżurnego. Wyrażenia z bool w regułach dają precyzyjne progi, a reguły nagrywające wydajność. Tak wygląda cała droga od metryki do człowieka.

Terminologia: bool modifier (modyfikator bool), thresholding (progowanie), alerting rule (reguła alertująca), recording rule (reguła nagrywająca), firing (aktywny), pending (oczekujący), resolved (rozwiązany), annotation templating (szablonowanie adnotacji).

Na tym slajdzie metryka przestaje być liczbą na wykresie i staje się decyzją: czy system jest w porządku, czy wymaga interwencji. Technika, która to umożliwia, to progowanie z modyfikatorem bool - ciągłą wartość przekształcamy w binarny sygnał ALERT albo OK. Rozróżnienie między filtrowaniem a wektorem boolowskim nie jest akademicką ciekawostką, bo bezpośrednio przesądza o tym, jak zachowa się reguła alertująca, kto zostanie zaalarmowany i czy komunikat dotyczy pojedynczej instancji, czy całej usługi.

Zapytanie `rate(...) > 0.01` filtruje - serie poniżej progu znikają z wyniku, więc alert jest wyzwalany dopiero wtedy, gdy każda zwrócona seria przekroczy próg. `rate(...) > bool 0.01` tworzy natomiast wektor zer i jedynek dla wszystkich serii, dzięki czemu reguła uruchamia się, gdy dowolna z nich osiągnie jeden, co daje alert na poziomie instancji. Do alertu globalnego agregujemy przed porównaniem, a wydajność i czytelność poprawia odwołanie do reguły nagrywającej zamiast powtarzania surowego zapytania, z szablonowanymi adnotacjami w treści komunikatu.

Wyjaśnienie skrótów użytych na slajdzie:
SLA – Service Level Agreement – umowa o gwarantowanym poziomie usług; Formalny kontrakt, którego progi krytyczne definiują czerwone strefy na panelach wizualizacyjnych.
SLO – Service Level Objective – cel poziomu usług; Wewnętrzny próg docelowy, którego naruszenie barwi panel na kolor żółty lub pomarańczowy.
SLI – Service Level Indicator – wskaźnik poziomu usług; Bieżąca metryka porównywana bezpośrednio z progami warunkowymi na wskaźnikach typu Gauge.
PromQL – Prometheus Query Language – język zapytań Prometheus; Język obliczający bieżącą wartość wskaźnika w stosunku do zdefiniowanego limitu.
KPI – Key Performance Indicator – kluczowy wskaźnik wydajności; Syntetyczny parametr biznesowy nadzorowany przy pomocy wielostopniowych progów ostrzegawczych.

Zmienne szablonowe a skalowalność monitoringu: W firmie utrzymującej setki mikroserwisów tworzenie osobnego dashboardu dla każdego z nich byłoby koszmarem utrzymaniowym. Zmienne szablonowe (Template Variables) pozwalają zamienić sztywne nazwy serwerów w kodzie zapytania na zmienne, np. node_cpu_seconds_total{instance="$host"}. Zmienna $host jest dynamicznie zasilana zapytaniem do bazy metryk (np. label_values(node_uname_info, instance)). Dzięki temu jeden wzorcowy pulpit obsługuje całą flotę maszyn, a pojawienie się nowego serwera w klastrze automatycznie dodaje go do rozwijanej listy wyboru w nagłówku strony.

Zmienne szablonowe (Variables) umożliwiają budowę dynamicznych pulpitów wieloobiektowych. Należy jednak zachować szczególną ostrożność przy włączaniu opcji wielokrotnego wyboru (Multi-value) oraz opcji „All”. W przypadku klastrów liczących setki węzłów wybranie opcji „All” powoduje wysłanie do bazy Prometheus zapytania agregującego tysiące szeregów czasowych, co może doprowadzić do wyczerpania pamięci RAM serwera i zablokowania przeglądarki użytkownika.

Zmienne, czyli templating, to w Grafanie prawdziwa zmiana zasad gry: zamiast klonować dashboard dla każdej instancji, joba czy środowiska, tworzysz jeden pulpit z dynamicznymi filtrami, które działają na wszystkich panelach naraz. Dostępne typy to zmienne zapytania oparte na PromQL, zmienna Datasource, lista niestandardowa Custom, pole tekstowe, stała, interwał oraz filtry ad hoc. To zasada DRY w wydaniu dashboardowym: bez zmiennych dashboard jest sztywny, ze zmiennymi nadaje się do codziennej produkcji.

Najczęstsze są zmienne zapytania: `$instance = label_values(node_cpu_seconds_total, instance)` pobiera realne wartości etykiety instance wprost z PromQL. Zmienna Datasource pozwala wybrać źródło danych w czasie działania, Custom to ręczna lista wartości, Text box dowolny tekst wpisany przez użytkownika, Constant stała wartość - na przykład nazwa środowiska produkcyjnego - a Interval to $__interval, czyli automatyczny krok. Filtry ad hoc dają możliwość dorzucania filtrów etykiet bezpośrednio na panelu. Wszystkie te typy razem zapewniają dużą elastyczność przy projektowaniu.

Zmienna instance działa jak dynamiczny filtr. Definiujesz ją przez `label_values(node_cpu_seconds_total, instance)`, a potem oferuje ona wielokrotny wybór ze znacznikami, opcję All dla wszystkich wartości oraz filtr regex ograniczający listę. W panelu zapisujesz zapytanie `rate(node_cpu_seconds_total{instance=~"$instance"}[5m])`, a zmienna pod spodem filtruje serie. Jeden dashboard obsługuje w ten sposób wszystkie instancje - wystarczy wybrać właściwą z rozwijanej listy. Koniec z klonowaniem pulpitów.

Warto też rozumieć, kiedy wartości odświeżają się na nowo. Wartości zmiennych odświeżają się przy załadowaniu dashboardu, przy zmianie zakresu czasu albo ręcznie przyciskiem. Opcja odświeżania przy zmianie zakresu czasu sprawia, że zmienne zawsze odpowiadają aktualnemu widokowi - a gdy infrastruktura się zmienia, nowe instancje pojawiają się automatycznie, bez dotykania dashboardu. Dashboard żyje razem z infrastrukturą, a nie zamiera w momencie zapisania.

Efekt końcowy to dashboard szablonowy: jeden pulpit dla wszystkich środowisk, usług i instancji, w którym ta sama zmienna filtruje zapytania we wszystkich panelach naraz. Zasada DRY mówi: nie powtarzaj się. Dashboardy szablonowe to jeden kod i setki wariantów - i właśnie tak w produkcji najczęściej się je buduje. Traktuj dashboard jak kod, a zmienne jak jego parametry.

Terminologia: variables (zmienne), templating (templating), query variable (zmienna zapytania), label_values (wartości etykiet), refresh (odświeżanie), multi-value (wielowartościowy), all option (opcja wszystkich), chained variables (zmienne łańcuchowane).

Zmienne templatingowe to granica między dashboardem, który żyje, a statyczną ilustracją: jedna definicja panelu obsługuje wszystkie instancje, usługi i środowiska, bo wartości filtrów są wybierane w locie, a nie wpisane na sztywno. W ten sposób realizuje się zasada DRY - nie powielamy prawie identycznych pulpitów dla każdej maszyny, tylko trzymamy jeden zestaw parametrów i setki możliwych wariantów widoku, co w produkcji jest dziś standardowym sposobem budowania monitoringu operacyjnego.

Najczęściej stosujemy zmienną zapytania: `$instance = label_values(node_cpu_seconds_total, instance)` pobiera realne wartości etykiety wprost z PromQL, oferuje wielokrotny wybór, opcję All oraz filtr regex, a w panelu używamy zapytania `rate(...{instance=~"$instance"}[5m])`. Obok niej istnieje zmienna Datasource, lista niestandardowa Custom, pole tekstowe, stała oraz zmienna Interval. Wartości odświeżają się przy załadowaniu, przy zmianie zakresu czasu albo ręcznie, dzięki czemu nowe instancje pojawiają się bez dotykania dashboardu.

Wyjaśnienie skrótów użytych na slajdzie:
Regex – Regular Expression – wyrażenie regularne; Mechanizm filtrujący listę wartości zwracanych w menu rozwijanym zmiennej szablonowej.
SQL – Structured Query Language – strukturalny język zapytań; Język używany do dynamicznego pobierania list wartości zmiennych z relacyjnych baz danych.
PromQL – Prometheus Query Language – język zapytań Prometheus; Funkcja label_values() w PromQL generująca dynamiczne listy instancji, środowisk i usług.
API – Application Programming Interface – interfejs programistyczny; Interfejs platformy Grafana umożliwiający kaskadowe przekazywanie parametrów w adresie URL.
JSON – JavaScript Object Notation – notacja obiektowa JavaScript; Format serializacji, w którym zapisywane są definicje i domyślne stany zmiennych pulpitu.

Panele Gauge i Stat pokazują stan na teraz, a nie trend - to panele streszczenia, z których korzysta między innymi menedżer. Gauge to okrągły wskaźnik z kolorowymi progami, idealny dla użycia CPU czy budżetu błędów; Stat to duża liczba uzupełniona minitrendem, naturalna dla pozostałego budżetu błędów albo liczby aktywnych alertów. Progi kolorów, formatowanie jednostek i miniwykres pozwalają przeczytać stan w ułamek sekundy - co ma ogromne znaczenie dla dyżurnego o trzeciej w nocy.

Zacznijmy od Gauge. To wskaźnik kołowy, który prezentuje wartość wraz z progami kolorów: na przykład zielony poniżej 70, żółty do 90, czerwony powyżej - albo twoje własne ustawienia. Domyślnie zakres to 0-100 procent, jednostka percentunit, a liczba miejsc po przecinku od 0 do 2. Jeden rzut oka odpowiada na pytanie, czy jest problem, czy nie. Zastosowania to między innymi CPU, pamięć, dysk, budżet błędów i liczba aktywnych alertów. Pamiętaj jednak: wskaźnik pokazuje stan w tej chwili, a nie trend - do trendów służy panel szeregu czasowego.

Stat panel działa inaczej: pod dużą liczbą, która pokazuje wartość bieżącą, średnią, maksimum, minimum, deltę albo różnicę, rysuje się miniwykres trendu. Kolor może dotyczyć samej wartości albo całego tła - zielony, żółty lub czerwony - w zależności od progów. Jednostki formatują się tak samo jak w innych panelach. Zastosowania to pozostały budżet błędów, zgodność ze SLO, liczba aktywnych alertów czy bieżące RPS. Właśnie tak prezentujesz kluczowe KPI wielką czcionką.

Sercem obu paneli są progi kolorów. Tryb progów bywa bezwzględny - według wartości, takich jak domyślne 0 i 80 - albo procentowy. Schematy kolorów obejmują zielony-żółty-czerwony, niebiesko-zielony albo własny. Semantyka jest niezmienna: czerwony oznacza błąd i stan krytyczny, żółty ostrzeżenie, zielony stan dobry, a niebieski informację neutralną. Trzymaj jej spójność na wszystkich dashboardach - to ogromnie ułatwia poznawczo odczyt, szczególnie pod presją incydentu.

A gdzie lokować te panele? Tam, gdzie operator widzi je w pierwszej kolejności. Gauge odpowiada na pytanie o stan teraz - jak wygląda CPU, pamięć, budżet błędów - a Stat prezentuje kluczowe KPI, takie jak pozostały budżet błędów czy aktywne alerty. Oba umieszczamy na górze dashboardu, w strefie above the fold, bo to pierwsze, co widzi dyżurny albo menedżer, kiedy otwiera pulpit. Działający widok to decyzja podejmowana w sekundy.

Terminologia: gauge panel (panel wskaźnikowy), stat panel (panel statystyczny), threshold (próg), color scheme (schemat kolorów), sparkline (minitrend), unit (jednostka), decimals (liczba miejsc po przecinku), value mappings (mapowanie wartości), KPI visualization (wizualizacja KPI).

Panele Gauge i Stat odpowiadają na pytanie o stan w tej chwili, a nie o przebieg w czasie - to pomost między szczegółowym wykresem a szybkim odczytem, z którego korzysta zarówno dyżurny prowadzący incydent o trzeciej w nocy, jak i menedżer zaglądający do pulpitu raz w tygodniu. Tam, gdzie liczy się czas reakcji, progi kolorów i formatowanie jednostek pozwalają ocenić sytuację w ułamek sekundy, bez czytania podpisów osi i liczb, co zmniejsza ryzyko błędnej interpretacji pod presją czasu.

Gauge to kołowy wskaźnik z progami kolorów - domyślnie zielony do progu 80, czerwony powyżej - i zakresem od zera do stu procent, idealny do użycia CPU, pamięci czy budżetu błędów. Stat pokazuje pod dużą liczbą miniwykres trendu, a sama liczba może być wartością bieżącą, średnią, maksimum albo deltą, więc naturalnie pasuje do pozostałego budżetu błędów, zgodności ze SLO albo liczby aktywnych alertów. Oba panele lokujemy na górze dashboardu, w strefie above the fold, bo to pierwsze, co widzi operator po otwarciu pulpitu.

Wyjaśnienie skrótów użytych na slajdzie:
KPI – Key Performance Indicator – kluczowy wskaźnik wydajności; Główny parametr biznesowy lub techniczny prezentowany jako pojedyncza duża liczba na panelu Stat.
SLO – Service Level Objective – cel poziomu usług; Wskaźnik docelowy, którego stopień realizacji wizualizuje się na półkolistym wskaźniku zegarowym (Gauge).
SLA – Service Level Agreement – umowa o poziomie usług; Wartość kontraktowa stanowiąca dolną granicę dopuszczalnego stanu na panelu operacyjnym.
CPU – Central Processing Unit – procesor; Procentowe obciążenie jednostki centralnej stanowiące klasyczny przykład wizualizacji na mierniku Gauge.
RAM – Random Access Memory – pamięć operacyjna; Zużycie pamięci prezentowane jako wartość bezwzględna w bajtach lub wskaźnik nasycenia.

Korelacja metryk i logów w architekturze Grafana + Loki: Podstawową zaletą zintegrowanego stosu obserwowalności jest płynne przechodzenie między poziomami szczegółowości. Gdy inżynier analizujący wykres metryk zauważy nagły skok błędów HTTP 500 o godzinie 14:15, nie musi ręcznie logować się na serwery i przeszukiwać plików /var/log. Wystarczy, że zaznaczy kursorem myszy podejrzany fragment wykresu i otworzy powiązany panel logów. Grafana automatycznie przeniesie zakres czasu i filtry etykiet (np. app="payment") do zapytania LogQL, wyświetlając dokładnie te wpisy dziennika, które powstały w momencie awarii.

Szczegółowe reguły powiadomień i progów alarmowych powiązanych z panelami logów konfiguruje moduł Grafana Alerting.

Panel logów to most między metrykami, które odpowiadają na pytanie „co się dzieje", a logami, które tłumaczą „dlaczego". Podpinamy źródło Loki, piszemy zapytanie LogQL, a w efekcie dostajemy tabelę wpisów z czasem, etykietami i treścią oraz podgląd na żywo. Filtry etykiet działają przed pobraniem danych, filtry linii po nich, a pola pochodne pozwalają linkować wpisy do śladów. Na jednym dashboardzie można zestawić panel latencji z panelem błędów i korelować oba we wspólnym zakresie czasu.

Sam panel logów korzysta z Loki albo Elasticsearch jako źródła. Zapytanie LogQL, na przykład `{job="nginx"} |= "error" | json | line_format "{{.message}}"`, zwraca tabelę z trzema kolumnami: czas, etykiety strumienia i treść wpisu. Tryb live tailing odświeża widok automatycznie, a nowe wpisy pojawiają się na górze listy - w ten sposób obserwujesz logi na żywo podczas wdrożenia canary albo debugowania trwającego incydentu.

Filtrowanie przebiega dwupoziomowo. Po pierwsze, filtry etykiet w samym zapytaniu działają przed pobraniem danych: `{job="nginx", env="prod"}` ogranicza strumienie już na poziomie Loki - szybko, bo całość korzysta z indeksu. Po drugie, filtry linii działają na pobranych treściach: `|= "error"` oznacza zawiera, `!= "health"` - nie zawiera, `|~ "timeout.*"` - dopasowanie wyrażeniem regularnym, a `!~ "debug"` - jego negację. Pola pochodne pozwalają parsować treść przez `| json`, wyciągać pola z wpisu i linkować identyfikator trace prosto do widoku Tempo. Precyzyjny filtr znajduje igłę w stogu siana.

Najciekawsze zaczyna się tam, gdzie metryki i logi pracują razem. Na jednym ekranie widzisz panel metryk ze skokiem latencji p99 i panel logów z błędami w tym samym oknie czasu, bo oba korzystają ze wspólnego selektora globalnego i wspólnych zmiennych, na przykład $instance. Widzisz skok latencji, patrzysz na logi w dokładnie tej samej chwili, znajdujesz wpis o wyczerpanej puli połączeń - i masz przyczynę w trzydzieści sekund. Tak wygląda łączenie metryk, logów i wspólnego kontekstu w jednym przepływie pracy.

Terminologia: log panel (panel logów), Explore (tryb eksploracji), LogQL (język zapytań Loki), derived fields (pola pochodne), label filters (filtry etykiet), line filters (filtry linii), live tailing (podgląd na żywo), metrics-logs correlation (korelacja metryk i logów).

Metryki odpowiadają na pytanie, co się dzieje, ale dopiero logi tłumaczą, dlaczego - dlatego panel logów jest brakującym ogniwem między obrazem systemu a jego przyczyną. Dostępne są dwa źródła, Loki i Elasticsearch, a wynik to czytelna tabela wpisów z czasem, etykietami strumienia oraz treścią komunikatu. Największą wartość daje jednak połączenie z resztą pulpitu: wspólny zakres czasu i te same zmienne pozwalają skorelować skok latencji z błędami widocznymi w logach, co przybliża nas do przyczyny źródłowej.

Filtrowanie działa dwupoziomowo: filtry etykiet, działające przed pobraniem danych i korzystające z indeksu, są szybkie - `{job="nginx", env="prod"}` zawęża strumienie już w źródle - a filtry linii działają na treści wpisu i pozwalają użyć operatorów |= jako zawiera, != jako nie zawiera oraz |~ i !~ jako dopasowania regexowego z negacją. Zapytanie `{job="nginx"} |= "error" | json | line_format "{{.message}}"` pokazuje, jak parsować pola i wyciągać treść, a tryb live tailing odświeża widok na żywo, co przydaje się przy wdrażaniu canary.

Wyjaśnienie skrótów użytych na slajdzie:
ELK – Elasticsearch, Logstash, Kibana – stos ELK; Platforma centralizacji logów integrowana z Grafaną poprzez dedykowane źródło danych.
Loki – Grafana Loki – system centralizacji logów Loki; Zoptymalizowany pod kątem chmury system agregacji logów indeksujący wyłącznie metadane (etykiety).
Promtail – Promtail log collector – agent zbierania logów Promtail; Lekki agent systemowy wysyłający strumienie logów z plików dziennika do bazy Loki.
JSON – JavaScript Object Notation – notacja obiektowa JavaScript; Format ustrukturyzowanego zapisu zdarzeń aplikacyjnych ułatwiający filtrowanie w panelu logów.
RegEx – Regular Expression – wyrażenia regularne; Wzorce parsowania tekstu w wierszach logów pozwalające na wyodrębnienie pól w locie.

Explore to laboratorium inżyniera SRE: interfejs zapytań ad hoc, który niczego nie zapisuje do dashboardu, trzyma historię odpytań, oferuje widok podzielony na dwa zapytania i pozwala przełączać się między metrykami, logami i śladami w jednym miejscu. Otwierasz, pytasz, zamykasz - nie zostawiając śladów na pulpicie. Explore uzupełnia dashboardy: dashboard służy stałemu monitorowaniu, a Explore śledztwu.

Zaczynamy od szybkiego badania zdarzeń. Bez przycisku zapisu - otwierasz Explore, wpisujesz PromQL, LogQL albo TraceQL i od razu oglądasz wynik. Historia zapytań, trzymana w pamięci przeglądarki, pamięta ostatnie kilkadziesiąt odpytań, a jedno kliknięcie uruchamia je ponownie. To inżynierski notatnik: testujesz hipotezy, sprawdzasz, zamykasz, a dashboardy zostają czyste, bez paneli próbnych, które zaśmiecają widok.

Drugim ważnym trikiem jest porównanie zakresów czasu. Ikona podziału dzieli ekran na dwie części i pozwala uruchomić dwa zapytania obok siebie. Gdy wybrany fragment czasu ma przesunięcie, lewa strona pokazuje teraz, a prawa na przykład godzinę albo tydzień temu. Różnice latencji teraz i przed godziną albo wskaźnika błędów względem tygodnia wstecz są od razu widoczne na wykresach. W ten sposób wykrywasz anomalie, zanim jeszcze odezwie się alert.

Największą siłą Explore jest płynne przechodzenie między sygnałami. Jeden interfejs, trzy zakładki: metryki w PromQL, logi w LogQL, ślady w TraceQL. Zmiana zakładki to zmiana perspektywy - metryki odpowiadają, że latencja skoczyła, logi dokładają stos błędów, a ślady wskazują konkretny span w konkretnej usłudze. Zmienne i zakres czasu są ujednolicone na wszystkich zakładkach, więc kontekst nie znika, gdy przełączasz widoki. Metryki, logi i ślady w jednym, nieprzerwanym przepływie pracy - to esencja zunifikowanej obserwowalności.

Terminologia: Explore mode (tryb eksploracji), ad-hoc query (zapytanie ad hoc), split view (widok podzielony), time shift (przesunięcie czasowe), history (historia zapytań), correlation (korelacja), trace to logs (od śladu do logów), metrics to logs (od metryk do logów).

Explore to inżynierskie laboratorium Grafany: interfejs, w którym zadajemy pytania ad hoc i nie zostawiamy po nich śladów w dashboardach. Otwieramy, odpytujemy, sprawdzamy hipotezę i zamykamy - historię zapytań przechowuje przeglądarka, więc pulpit pozostaje czysty, a my zyskujemy przestrzeń do eksperymentów w stylu prób i błędów. Dashboard pełni rolę stałego monitorowania, natomiast Explore służy śledztwu prowadzonemu w trakcie incydentu lub przed jego wybuchem.

Największą zaletą jest widok podzielony: dwa zapytania obok siebie, a przy przesunięciu czasu lewa strona pokazuje teraz, prawa na przykład godzinę albo tydzień temu, co ujawnia anomalie, zanim włączy się alert. W jednym interfejsie przełączamy się między metrykami w PromQL, logami w LogQL i śladami w TraceQL, przy czym zmienne i zakres czasu pozostają wspólne, więc kontekst nie znika przy zmianie zakładki. Tym samym przechodzimy od skoku latencji, przez stos błędów w logach, aż po konkretny span w wybranej usłudze.

Wyjaśnienie skrótów użytych na slajdzie:
PromQL – Prometheus Query Language – język zapytań Prometheus; Język eksploracji metryk w trybie Explore służący do szybkiego testowania hipotez awaryjnych.
LogQL – Log Query Language – język zapytań LogQL; Język zapytań systemu Grafana Loki wzorowany na składni PromQL, służący do filtrowania logów.
TSDB – Time Series Database – baza danych szeregów czasowych; Źródło danych odpytywane doraźnie w trybie inspekcji bez konieczności tworzenia stałego panelu.
UI – User Interface – interfejs użytkownika; Dzielony widok w trybie Explore umożliwiający jednoczesną korelację metryk i logów na jednym ekranie.
API – Application Programming Interface – interfejs programistyczny; Wewnętrzne punkty końcowe wywoływane w trakcie interaktywnego profilowania zapytań.

Adnotacje jako most między wdrożeniem a telemetrią: Jedną z najczęstszych przyczyn awarii produkcyjnych jest wdrożenie nowej wersji kodu lub zmiana konfiguracji. Adnotacje (Annotations) to pionowe znaczniki nanoszone automatycznie na wykresy w Grafanie za pośrednictwem prostego wywołania API z potoku CI/CD (np. GitHub Actions lub Jenkins). Znacznik zawiera numer wydania, autora zmiany oraz link do zatwierdzenia w Git. Gdy dyżurny inżynier widzi, że skok czasu odpowiedzi nastąpił dokładnie w minucie wdrożenia wersji v2.4.1, przyczyna problemu staje się oczywista, co skraca czas diagnozy do kilkunastu sekund.

Adnotacje stanowią kluczowe narzędzie diagnostyczne korelujące incydenty telemetryczne z działaniami zespołu programistycznego. Zamiast ręcznego dodawania wpisów w interfejsie GUI, znaczniki wdrożeń muszą być generowane automatycznie przez potoki GitHub Actions lub GitLab CI poprzez wywołanie endpointu REST API Grafany (POST /api/annotations) w momencie uruchomienia nowej wersji kontenera na produkcji.

Adnotacje to nakładka zdarzeń na wykresy - dostarczają kontekstu dla zmian, które widać na liniach metryk. Adnotacja wdrożenia niesie identyfikator commita, wersję, autora i link do pipeline, a adnotacja incydentu oznacza początek i koniec awarii, jej wagę oraz link do post-mortem. Korelacja zmian, czyli natychmiastowe skojarzenie „wdrożenie v1.2.3 i skok latencji", eliminuje w organizacji pytania, kiedy coś się stało i co wtedy dokładnie wdrożono. Adnotacje to oś zdarzeń na wykresie.

Adnotacje wdrożeń przychodzą najczęściej z systemów CI/CD - ArgoCD, Flux, GitLab CI, GitHub Actions czy Jenkins - i trafiają do Grafany przez interfejs HTTP pod adresem /api/annotations. Na wykresie pojawiają się wtedy pionowe linie albo ikony z numerem commita, tagiem wersji, autorem i linkiem do przebiegu pipeline. Widoczne są na wybranych panelach, według tagu. Jako źródło wystarczy webhook ArgoCD, kontroler notyfikacji we Fluxie albo własny webhook z potoku CI/CD - to kilka minut konfiguracji, a zysk w diagnostyce jest ogromny.

Adnotacje incydentu dodaje się ręcznie albo automatycznie. Ręcznie: klikasz na wykresie i dodajesz adnotację ze znacznikiem czasu. Automatycznie: webhook z Alertmanagera czy narzędzia do zarządzania incydentami, takiego jak PagerDuty, Opsgenie albo incident.io. Taka adnotacja niesie czas rozpoczęcia i zakończenia awarii, jej wagę - krytyczną albo ostrzegawczą - oraz link do post-mortem albo kanału incydentu w Slacku. Historia incydentów rysuje się na wykresie sama, bez prowadzenia dodatkowych rejestrów.

Dlaczego to takie cenne? Gdy na wykresie latencji widzisz pionową linię „wdrożenie v1.2.3" dokładnie w chwili skoku, nie musisz już pytać, kiedy to się stało ani co wtedy zmieniano. Korelacja zmian przyspiesza znalezienie przyczyny: zamiast zgadywać, widzisz związek wprost na wykresie. W trakcie triage'u incydentu to koniec domysłów i wielogodzinnych dyskusji - dane mówią same za siebie.

Terminologia: annotation (adnotacja), event overlay (nakładka zdarzeń), deployment annotation (adnotacja wdrożenia), incident annotation (adnotacja incydentu), annotation query (zapytanie o adnotacje ze źródła), Grafana HTTP API (interfejs API Grafany do adnotacji).

Adnotacje rysują na wykresie oś zdarzeń - pionowe linie oznaczające wdrożenia i incydenty - dzięki którym zmiana na ścieżce metryki od razu znajduje swoją przyczynę. To, co niegdyś wymagało dyskusji i domysłów, gdzie padały pytania, kiedy coś się stało i co wtedy wdrożono, dziś widać na wykresie bez słów: skok latencji dokładnie w chwili wydania nowej wersji mówi sam za siebie i usuwa konieczność prowadzenia osobnych rejestrów zmian.

Adnotacje wdrożeń przychodzą z systemów CI/CD, takich jak ArgoCD, GitLab CI czy GitHub Actions, i trafiają do Grafany przez interfejs HTTP; na wykresie widzimy numer commita, wersję, autora oraz link do pipeline. Adnotacje incydentu dodajemy ręcznie kliknięciem na wykresie albo automatycznie przez webhook z Alertmanagera, PagerDuty czy Opsgenie - niosą czas rozpoczęcia i zakończenia awarii, jej wagę oraz link do post-mortem. Konfiguracja zajmuje kilka minut, a diagnostyka zyskuje kontekst, którego bez adnotacji po prostu nie było.

Wyjaśnienie skrótów użytych na slajdzie:
CI/CD – Continuous Integration / Continuous Delivery – ciągła integracja i ciągłe wdrażanie; Zautomatyzowane potoki deweloperskie wysyłające znaczniki nowych wydań na osie wykresów.
Git – Git version control system – system kontroli wersji Git; System śledzenia zmian w kodzie, z którego sumy kontrolne commitów trafiają do adnotacji Grafany.
PR – Pull Request – propozycja włączenia kodu; Zdarzenie scalenia zmian w repozytorium oznaczane na wykresach w celu weryfikacji wpływu na wydajność.
API – Application Programming Interface – interfejs programistyczny; Interfejs REST API Grafany (endpoint /api/annotations) służący do programowego tworzenia adnotacji.
REST – Representational State Transfer – architektura interfejsu REST; Standard sieciowy, w którym agenci wdrożeniowi przesyłają dane o zdarzeniach w formacie JSON.

Dashboardy projektujemy per rola, a nie „jeden dla wszystkich" - bo inna rzecz interesuje operatora na zmianie, a inną chce zobaczyć dyrektor IT. Widok NOC jest gęsty, pracuje całą dobę i trafia na duże ekrany w pokoju operacyjnym; widok menedżerski pokazuje kluczowe wskaźniki i służy raportowaniu miesięcznemu; a dostęp rozdzielamy folderami z linkami drill-down, by nie mieszać ról. To hierarchia informacji, widoki dopasowane do odbiorcy i nawigacja w głąb.

Widok NOC, czyli Network Operations Center, operuje bardzo gęstym obrazem: wiele mniejszych paneli pokazuje status up/down, listę aktywnych alertów i krytyczne metryki - CPU, pamięć, dysk, sieć, wskaźnik błędów i latencję p99. Działa bez przerwy i zazwyczaj „zawisa" na dużych monitorach w pomieszczeniu operacyjnym. Gęstość informacji jest odważna, ale podporządkowana hierarchii: na samej górze krytyczne alerty, niżej sygnały nasycenia, jeszcze niżej szczegóły. Wersja ścienna wymaga dużej czcionki, wyraźnych kontrastów i jednoznacznych progów kolorów - operator patrzy na nią z odległości metra. To kokpit sterowniczy.

Widok menedżerski, czyli Executive View, opowiada natomiast językiem biznesu: pokazuje zgodność ze SLO, pozostały budżet błędów, liczbę incydentów w bieżącym miesiącu, trend MTTR, wydatki na chmurę i należne zwroty SLA. Kadencja raportowania to miesiąc albo kwartał, a komunikaty brzmią biznesowo - „dostępność usługi 99,97 procent przy celu 99,9" albo „pozostało 72 procent budżetu błędów" - zamiast surowych liczb technicznych. Takie tłumaczenie na język zarządu daje decydentom pełną widoczność ryzyka i kosztów.

Rozdzielenie poziomów, czyli tiered access, odbywa się przez foldery i uprawnienia: zespół operacyjny edytuje foldery operacyjne, zarząd ogląda foldery biznesowe tylko do odczytu. Linki drill-down prowadzą z widoku menedżerskiego - na przykład po złamaniu SLO - do szczegółowego dashboardu NOC z metrykami per usługa. Dostęp według ról to nie „wszystko dla wszystkich", lecz bezpieczeństwo i użyteczność jednocześnie: operator nie tonie w metrykach biznesowych, a menedżer nie grzęźnie w technicznych szczegółach.

Na samym wierzchu, w strefie above the fold, lokujemy budżet błędów, status SLO w kolorach zielonym/żółtym/czerwonym, liczbę i listę aktywnych alertów, najczęstsze błędy oraz sygnały nasycenia - użycie CPU powyżej 80 procent, pamięci powyżej 85, dysku powyżej 80. Wszystko to bez scrollowania. Priorytetyzacja wizualna oznacza, że kluczowe sygnały widać od razu; scrollowanie rozprasza i gubi kontekst. Tak projektujemy dla szybkości: operator ocenia stan systemu w trzy sekundy, nie w trzy minuty.

Jedna z najważniejszych zasad projektowania dashboardów sprowadza się dzisiaj do tezy: pulpit projektujemy dla roli, a nie dla wszystkich naraz. To, czego potrzebuje operator na zmianie, wpatrując się w duży ekran w pokoju operacyjnym, różni się od tego, co chce zobaczyć dyrektor IT w raporcie miesięcznym. Ten slajd pokazuje dwa krańce spektrum - widok NOC oraz widok menedżerski - i wyjaśnia, jak dopasowujemy do odbiorcy treść, gęstość informacji i język komunikatów.

Widok NOC jest gęsty: wiele paneli ze statusem up/down, listą aktywnych alertów oraz krytycznymi metrykami, takimi jak CPU, pamięć, dysk czy latencja p99, pracuje przez całą dobę na dużych monitorach i wymaga wyraźnych kontrastów. Widok menedżerski opowiada językiem biznesu: zgodność ze SLO, pozostały budżet błędów, liczba incydentów w miesiącu czy trend MTTR zamiast surowych liczb technicznych. Oba poziomy rozdzielamy folderami i uprawnieniami, a linki drill-down prowadzą z podsumowania do szczegółowych widoków NOC.

Wyjaśnienie skrótów użytych na slajdzie:
NOC – Network Operations Center – centrum zarządzania siecią; Zespół inżynierów operacyjnych wymagający pulpitów o wysokim kontraście i syntetycznych alertach.
SOC – Security Operations Center – centrum operacji bezpieczeństwa; Zespół monitorujący anomalie sieciowe i próby naruszenia bezpieczeństwa na dedykowanych dashboardach.
SRE – Site Reliability Engineering – inżynieria niezawodności systemów; Praktyka projektowania pulpitów ukierunkowanych na szybką dekompozycję problemu i izolację awarii.
On-call – On-call Engineer – inżynier dyżurny; Specjalista pełniący dyżur alarmowy, dla którego pulpit jest pierwszym punktem kontaktu po wybudzeniu przez pager.
P1 – Priority 1 Incident – incydent o priorytecie krytycznym; Awaria o najwyższym poziomie dotkliwości biznesowej, wymagająca natychmiastowej pracy na dedykowanym pulpicie incydentu.

Analiza trendów wyławia sygnał z szumu i wychyla się w przyszłość - działa na trzech filarach: sezonowość, czyli powtarzalne wzorce; prognozowanie pojemności; i porównania z przesunięciem czasu. To operacje proaktywne: zamiast reagować na awarie, planujesz przed nimi. W praktyce analiza trendów to planowanie pojemności, wykrywanie anomalii i prognozowanie w jednym.

Zacznijmy od sezonowości, czyli regularnych wzorców tygodniowych. Ruch rośnie w dni robocze - szczyty między dziewiątą a jedenastą oraz czternastą a szesnastą - a w weekendy spada o 60-80 procent. Dochodzi do tego nocne przetwarzanie wsadowe koło drugiej-trzeciej w nocy. Dla każdej godziny tygodnia budujesz linię bazową - średnią latencji, RPS i wskaźnika błędów - i to ona stanowi punkt odniesienia. Gdy w poniedziałek o dziesiątej latencja jest dwukrotnie wyższa niż ta linia bazowa, masz wyraźny sygnał anomalii. Sezonowość to kontekst, bez którego alerty tracą sens.

Drugi filar to prognozowanie pojemności, czyli capacity planning. Trend dysku liczony regresją liniową na metryce `node_filesystem_avail_bytes` powie ci, że dysk zapełni się za czternaście dni: `predict_linear(node_filesystem_avail_bytes[30d], 14*86400) < 0`. Trend CPU, na przykład `rate(node_cpu_seconds_total{mode!="idle"}[30d])`, podpowiada, że za trzy tygodnie będziesz potrzebować scale-outu. To skaling proaktywny: zasoby zamawiasz przed ich wyczerpaniem, a nie po awarii. Do prognozowania służy funkcja predict_linear w PromQL, a w złożonych przypadkach - modele uczenia maszynowego, jak Prophet. A pamiętaj, że czas realizacji zamówienia serwera to często dwa tygodnie - dlatego wiedza z wyprzedzeniem jest bezcenna.

Trzeci filar to porównania z przesunięciem czasu, czyli time shift comparison. W PromQL modyfikator `offset 1w` cofa widok o tydzień, `offset 4w` o miesiąc, `offset 1y` o rok. Porównanie z tym samym dniem tygodnia sprzed tygodnia lub miesiąca wykrywa anomalie - gdy latencja dziś jest dwukrotnie większa niż tydzień temu przy podobnym ruchu, coś jest nie tak. Tak działa porównanie rok do roku, tydzień do tygodnia i miesiąc do miesiąca - proste, dające się natychmiast zinterpretować i skuteczne, bez potrzeby sięgania po uczenie maszynowe.

Terminologia: trend (trend), seasonality (sezonowość), capacity planning (planowanie pojemności), forecasting (prognozowanie), time shift (przesunięcie czasowe), offset (przesunięcie), baseline (linia bazowa), anomaly detection (wykrywanie anomalii), linear regression (regresja liniowa).

Analiza trendów przesuwa działania zespołu z reakcji na awarie w stronę planowania przed nimi - zamiast czekać, aż dysk się zapełni albo skończy się podaż CPU, liczymy liniowe trendy i porównujemy z przeszłością. To podejście proaktywne, charakterystyczne dla dojrzałego SRE, opiera się na trzech filarach: sezonowości, czyli powtarzalnych wzorcach, prognozowaniu pojemności oraz porównaniach z przesunięciem czasu, które razem zamieniają historię danych w przewidywanie przyszłości.

Sezonowość daje linię bazową per godzina tygodnia - szczyty w dni robocze, spadki w weekendy nawet o 60-80 procent - a wyraźne przekroczenie tej linii przez latencję to szybki sygnał anomalii. Prognozuje predict_linear: `predict_linear(node_filesystem_avail_bytes[30d], 14*86400) < 0` ostrzega, że dysk zapełni się za czternaście dni, a planowanie pojemności pozwala zamówić zasoby, zanim ich zabraknie - realizacja serwera trwa zwykle dwa tygodnie. Porównania z offset 1w i 4w zestawiają teraz z tym samym dniem poprzedniego tygodnia czy miesiąca.

Wyjaśnienie skrótów użytych na slajdzie:
SLA – Service Level Agreement – umowa o poziomie usług; Kontrakt długoterminowy, którego dotrzymanie wymaga ciągłej analizy trendów wyczerpania zasobów.
SLO – Service Level Objective – cel poziomu usług; Wewnętrzny wskaźnik jakościowy podlegający analizie sezonowości tygodniowej i miesięcznej.
ML – Machine Learning – uczenie maszynowe; Algorytmy predykcyjne wspierające wykrywanie odchyleń od historycznych linii bazowych (baselines).
AI – Artificial Intelligence – sztuczna inteligencja; Moduły analityczne automatycznie identyfikujące nietypowe skoki metryk w wielowymiarowych zbiorach.
IQR – Interquartile Range – rozstęp międzykwartylowy; Miara rozrzutu danych wykorzystywana do odrzucania szumów pomiarowych w analizie długoterminowej.

Korelacja metryk szuka przyczyny w morzu danych, łącząc pomiary z różnych warstw obserwowalności: mapa usług zbudowana ze śladów, korelacja metryk na wykresach i w efekcie graf zależności, na którym prowadzimy diagnostykę od góry w dół. Do tego dochodzą dwie metody porządkujące pomiary - metryki RED, czyli tempo, błędy i czas trwania, dla usług, oraz metryki USE, czyli wykorzystanie, nasycenie i błędy, dla zasobów infrastruktury. To nie przypadkowe patrzenie na wykresy, lecz uporządkowany proces.

Pierwszy krok to warstwa zależności: mapa usług i korelacja metryk. Mapa, zbudowana ze śladów Jaegera albo Tempo, rysuje topologię: usługa A wywołuje usługę B, a ta bazę danych. Na mapie nakładasz metryki: gdy rosnąca latencja usługi A idzie w parze z rosnącym użyciem CPU usługi B, widzisz, że A zależy od B i to B jest wąskim gardłem. Korelacja metryk RED układa się wtedy we wzorzec degradacji: tempo rośnie, błędy rosną, czas trwania rośnie. Na krawędziach grafu pojawiają się zależności z metrykami - latencja i wskaźnik błędów przy każdym przeskoku. To mapa, po której nawigujesz podczas incydentu.

Drugi krok to hierarchiczna izolacja przyczyny, czyli top-down diagnosis, prowadząca od ogółu do szczegółu. Zaczynamy od globalnego wskaźnika błędów, następnie za pomocą topk wskazujemy, która usługa zawodzi, dalej tym samym mechanizmem sprawdzamy, który endpoint generuje problemy, potem szukamy winnej instancji, a na końcu wchodzimy w logi i ślady konkretnej instancji za pomocą LogQL albo TraceQL. W ten sposób zawęzasz obszar poszukiwań od globalnego do lokalnego, a drill-down daje przyczynę w sekundy, nie godziny.

Terminologia: correlation (korelacja), dependency (zależność), service map (mapa usług), top-down diagnosis (diagnoza od góry w dół), RED metrics (tempo, błędy, czas trwania), USE method (wykorzystanie, nasycenie, błędy), drill-down (analiza w głąb), root cause isolation (izolacja przyczyny źródłowej).

Pojedyncza metryka, nawet najdokładniejsza, rzadko wyjaśnia incydent do końca; w systemie rozproszonym to nie pojedyncze liczby, lecz relacje między nimi niosą odpowiedź, gdzie leży przyczyna. Dlatego zajmiemy się korelacją metryk, czyli świadomym wiązaniem pomiarów z różnych warstw obserwowalności. Podstawą jest mapa usług budowana ze śladów rozłożonego śledzenia, na przykład Jaegera czy Tempo: rysuje ona topologię wywołań, pokazuje, która usługa woła którą i w jakiej kolejności, i staje się tłem, na którym lokalizujemy miejsce awarii.

Na tej mapie nakładamy metryki RED i USE, czyli tempo, błędy i czas trwania dla usług oraz wykorzystanie, nasycenie i błędy dla zasobów infrastruktury, i prowadzimy diagnostykę od góry w dół. Zaczynamy od globalnego wskaźnika błędów, potem wskazujemy zawodzącą usługę, dalej winny endpoint, następnie instancję, a na końcu wchodzimy w jej logi i ślady. Gdy latencja jednej usługi rośnie razem z użyciem CPU drugiej, widzimy wąskie gardło; taki drill-down izoluje przyczynę źródłową w sekundy, nie w godziny.

Wyjaśnienie skrótów użytych na slajdzie:
CPU – Central Processing Unit – procesor; Metryka sprzętowa korelowana z czasem odpowiedzi aplikacji w celu identyfikacji pętli obliczeniowych.
RAM – Random Access Memory – pamięć operacyjna; Zasób powiązany z narastaniem opóźnień w wyniku intensywnej pracy mechanizmu odśmiecania pamięci (GC).
IOPS – Input/Output Operations Per Second – liczba operacji wejścia/wyjścia na sekundę; Wskaźnik wąskiego gardła macierzy dyskowej korelujący z wydłużeniem czasu transakcji bazodanowych.
RTT – Round Trip Time – czas podróży pakietu w obie strony; Opóźnienie sieciowe korelowane z ogólnym czasem przetwarzania żądań na serwerach brzegowych.
HTTP – Hypertext Transfer Protocol – protokół warstwy aplikacji; Protokół, którego błędy 5xx koreluje się z nasyceniem puli procesów aplikacji roboczej.

W analizie czasu odpowiedzi usług mikroserwisowych tradycyjny wykres liniowy percentyla p99 jest niewystarczający, gdyż maskuje wielomodalność rozkładu (np. szybkie odpowiedzi z cache 2 ms vs wolne zapytania do bazy danych 800 ms). Standardem inżynierskim jest stosowanie mapy ciepła (Heatmap), która wizualizuje pełne widmo koszyków histogramu Prometheusa (rate(http_request_duration_seconds_bucket[$__rate_interval])), natychmiast uwypuklając rozwarstwienie ruchu i anomalie.

Latencja ogonowa, czyli prawy ogon rozkładu, to miejsce, gdzie rodzi się frustracja użytkowników i zgłoszenia do pomocy technicznej. p99, p99.9 i p99.99 potrafią być fatalne, choć p50 i p95 wyglądają całkiem dobrze - a jeden procent klientów i tak dostaje timeout. Cel SLA w postaci „p99 poniżej 500 ms" egzekwujemy alertem i linią progu na dashboardzie, a w systemach rozproszonych trzeba dodatkowo pamiętać o amplifikacji ogona: p99 usługi odpowiada p99.9 jej zależności.

Najpierw wyjaśnijmy, o kim mówimy. p99 to najgorszy odsetek użytkowników: jeden procent, czyli jedno na sto żądań; p99.9 to jedno na tysiąc, a p99.99 - jedno na dziesięć tysięcy. Klasyczny przykład: p50 może wynosić przyjemne 100 milisekund, a p99 w tym samym czasie dziesięć sekund - i to te dziesięć sekund oznacza timeout dla co setnego klienta, który zgłosi problem, zmieni dostawcę albo straci pieniądze. Dlatego wskaźniki SLO i SLA budujemy na p99 i p99.9, a nie na medianie - mediana w statystyce SRE bywa po prostu kłamstwem.

Jak egzekwujemy taki cel? SLA, które mówi „p99 poniżej 500 ms", pilnuje reguła alertu: `histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{job="api"}[5m])) > 0.5`. Na dashboardzie rysujemy panel szeregu czasowego z linią progu na poziomie 0,5 sekundy w kolorze czerwonym - i tak działa wizualne egzekwowanie SLO: przekroczenie celu od razu widać na wykresie. Do tych trzech kroków - alert, linia progu, adnotacja chwili przekroczenia - sprowadza się praktyczne egzekwowanie celu jakościowego.

Na koniec amplifikacja ogona w systemach rozproszonych. Jeden przychodzący request rozgłasza się na wiele wywołań zależności - to fan-out - potem wyniki zbierają się z powrotem, dochodzą retries po timeoutach oraz kolejkowanie opisane prawem Little'a. Efekt jest matematyczny: p99 usługi staje się p99.9 zależności, bo prawdopodobieństwo, że przynajmniej jedno z dziesięciu wywołań będzie wolne, rośnie z każdym kolejnym wywołaniem. To wymusza następujące ustawianie celów: jeśli masz p99 na poziomie usługi, ustaw p99.9 na jej zależnościach. Tak wygląda matematyka ogona w mikroserwisach.

Terminologia: tail latency (latencja ogonowa), SLO bound (granica SLO), percentile (percentyl), histogram_quantile (kwantyl histogramu), SLA threshold (próg SLA), tail latency amplification (amplifikacja latencji ogonowej), long tail (długi ogon).

Średnia i mediana często zakłamują obraz, dlatego w SRE uwagę kierujemy na latencję ogonową, czyli na najwolniejsze odpowiedzi, których nie widać w typowej statystyce. p99 to poziom czasu odpowiedzi, który przekracza tylko najgorszy jeden procent żądań, p99.9 to jedno na tysiąc, a p99.99 jedno na dziesięć tysięcy. To właśnie ci klienci doświadczają timeoutów, tracą pieniądze albo zgłaszają problemy, dlatego cele SLO i SLA budujemy na percentylach ogonowych, a nie na medianie, która w statystyce SRE bywa po prostu myląca.

W praktyce percentyle wyznaczamy funkcją histogram_quantile, działającą na skumulowanych bucketach histogramu, na przykład histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m]))), a na wykresie rysujemy linię progu SLO, co wizualnie egzekwuje cel. W mikroserwisach trzeba pamiętać o amplifikacji ogona: jeden request rozgłasza się na wiele wywołań zależności, więc p99 usługi odpowiada p99.9 jej zależności i cele warto ustawiać z uwzględnieniem tego mnożnika.

Wyjaśnienie skrótów użytych na slajdzie:
RTT – Round Trip Time – czas podróży pakietu w obie strony; Czas obiegu pakietu w sieci komputerowej charakteryzujący się skośnym rozkładem statystycznym.
TTFB – Time To First Byte – czas do odebrania pierwszego bajtu; Wskaźnik opóźnienia serwera, dla którego wartości p95 i p99 odzwierciedlają problemy z bazą danych.
SLA – Service Level Agreement – umowa o poziomie usług; Porozumienie z klientem wyznaczające dopuszczalne limity opóźnień dla 99% transakcji.
SLO – Service Level Objective – cel poziomu usług; Parametr techniczny chroniący aplikację przed degradacją komfortu obsługi klienta.
CDF – Cumulative Distribution Function – dystrybuanta empiryczna; Funkcja matematyczna obrazująca prawdopodobieństwo obsłużenia żądania poniżej zadanego czasu.

Pulpit SLO jako centrum dowodzenia inżyniera: Dashboard dedykowany wskaźnikom SLO różni się diametralnie od pulpitów sprzętowych. Zamiast wykresów zużycia pamięci czy dysków, centralne miejsce zajmuje na nim miernik budżetu błędów oraz wskaźnik tempa spalania (Burn Rate). Pulpit ten odpowiada na fundamentalne pytanie biznesowe: „Czy jakość usługi jest obecnie zagrożona i czy zespół może bezpiecznie publikować nowe funkcje?”. Kolorowe wskaźniki natychmiast ostrzegają o przekroczeniu bezpiecznych progów, stanowiąc obiektywną podstawę do wdrożenia procedury wstrzymania wydań (release freeze).

Pulpit operacyjny zgodny z wytycznymi Google SRE musi w centralnym punkcie prezentować aktualne zużycie budżetu błędów oraz tempo jego spalania (Burn Rate). Przekroczenie progu Burn Rate sygnalizowane jest zmianą koloru panelu typu Stat z zielonego na alarmowy ceglasty, co stanowi bezpośrednią dyspozycję do wstrzymania wdrożeń nowych funkcji (Release Freeze).

Dashboard wizualnie egzekwuje SLO i zamyka całą pętlę: metryka, współczynnik SLI, cel SLO, budżet błędów, dashboard i wreszcie decyzja. Panel budżetu błędów z procentem zużycia i progami, kolorowanie zgodności ze SLO na wykresach oraz wizualizacja tempa spalania zamieniają abstrakcyjny cel jakościowy w narzędzie, które widać na pierwszy rzut oka - i którym można na co dzień podejmować decyzje.

Sercem jest panel budżetu błędów. Najprostszy sposób wyliczenia zużycia to iloraz poniesionych błędów przez błąd dopuszczalny: `(1 - SLI) / (1 - SLO)`. Gdy wskaźnik SLI równa się 99,95 procent przy celu 99,9, mamy 0,05 procent błędów zamiast dozwolonych 0,1 - czyli zużycie wynosi 50 procent, a w rezerwie zostaje drugie 50. Wskaźnik ten oprawiamy progami: zielonym, gdy zużycie nie przekracza 50 procent, żółtym w zakresie 50-80, gdy tempo spalania jest wysokie, i czerwonym powyżej 80 procent, gdy robi się naprawdę krytycznie i czas wstrzymać wydania. Operator widzi w sekundy, ile budżetu nam zostało - ta liczba to operacyjna waluta zespołu, wylana niemal dosłownie na wykres.

Kolorowanie zgodności ze SLO przenosi tę samą logikę na zwykłe panele metryk. Na wykresach latencji i wskaźnika błędów kolory egzekwują zgodność: zielony, gdy SLI nie schodzi poniżej celu, żółty, gdy jesteśmy blisko granicy i tempo spalania rośnie, czerwony, gdy cel został już przekroczony. Do wykresu dodajemy linię progu SLO i kolorujemy obszar powyżej lub poniżej tej linii. Operator dostrzega przekroczenie bez czytania liczb - i to jest istota wizualnego alertingu: decyzja podejmowana w sekundy, a nie po przeczytaniu tabeli.

Terminologia: SLO dashboard (pulpit SLO), error budget panel (panel budżetu błędów), burn rate visualization (wizualizacja tempa spalania budżetu), threshold coloring (kolorowanie progowe), SLO compliance (zgodność ze SLO), budget remaining (pozostały budżet).

Dashboard, który wizualnie egzekwuje SLO, zamyka całą pętlę zarządzania niezawodnością: metryka zamienia się w SLI, SLI porównujemy z celem SLO, z tej różnicy wynika budżet błędów, a dashboard pokazuje jego stan i kieruje decyzją. Panel budżetu błędów jest tu sercem całości, bo prezentuje procent zużycia w jednym wskaźniku, który operator czyta w ułamek sekundy. To konkretne narzędzie wiąże ten wykład z materiałem o SLI, SLO oraz budżecie błędów z poprzedniej części kursu.

Zużycie liczymy prostym wzorem (1 - SLI) / (1 - SLO), czyli poniesione błędy dzielimy przez błąd dopuszczalny; gdy SLI wynosi 99,95 procent przy celu 99,9, zużyliśmy pięćdziesiąt procent budżetu, a w rezerwie został drugi. Ten wskaźnik oprawiamy progami i kolorami: zielony oznacza zużycie poniżej 50 procent, żółty zakres od 50 do 80, a czerwony powyżej 80, gdy wypada wstrzymać wydania. Kolorowanie zgodności ze SLO na zwykłych wykresach metryk przenosi tę samą logikę na każdy panel i daje wizualny alerting.

Wyjaśnienie skrótów użytych na slajdzie:
SLO – Service Level Objective – cel poziomu usług; Kluczowy cel jakościowy prezentowany na dedykowanych pulpitach zespołów produktowych.
SLI – Service Level Indicator – wskaźnik poziomu usług; Rzeczywista miara sukcesu mierzona w czasie rzeczywistym i zestawiana z celem.
SLA – Service Level Agreement – umowa o gwarantowanym poziomie usług; Biznesowy punkt odniesienia dla pulpitów sprawozdawczych kierownictwa IT.
EB – Error Budget – budżet błędów; Dopuszczalny margines zawodności prezentowany w formie słupków wyczerpania na pulpicie SRE.
Burn Rate – Burn Rate of Error Budget – tempo spalania budżetu błędów; Wskaźnik dynamiki zużycia budżetu decydujący o natychmiastowym wstrzymaniu wydań kodu.

Auto-odświeżanie utrzymuje dashboard przy życiu - operator NOC patrzy na dane na żywo, a pamięć podręczna zapytań chroni Prometheusa przed nadmiernym obciążeniem. Grafana Alerting z kolei rozszerza możliwości samego Prometheus Alertmanagera: reguły definiujesz w Grafanie, mogą obejmować wiele źródeł naraz, a punkty kontaktowe, polityki powiadomień i wyciszenia zarządzasz z jednego miejsca. To jeden, zunifikowany interfejs alertingu nad wieloma źródłami danych.

Odświeżanie to wybór interwału. W ustawieniach dashboardu dobierasz interwał: 5 sekund, 10, 30, a potem 1, 5, 15, 30 minut lub godzinę - albo całość wyłączasz. Widok NOC działa zwykle na interwale 5-30 sekund, bo operator śledzi sytuację na żywo, a widok menedżerski dla odmiany na 5 minut do godziny, bo tam wystarczą dane buforowane. Pamięć podręczna zapytań Grafany to opcja dostępna w Grafana Enterprise i Grafana Cloud - nie jest włączona domyślnie, konfiguruje się ją per źródło danych, z czasem życia wpisów i limitem współbieżnych zapytań, a dzięki niej do Prometheusa trafia mniej żądań. To oczywisty kompromis: świeżość danych kosztuje obciążenie, a dobór interwału zależy od roli odbiorcy.

Od wersji 8 Grafana oferuje własny, zintegrowany system alertów. Reguły definiujemy w Grafanie, a nie w configu Prometheusa - i jedna reguła potrafi spytać jednocześnie PromQL, LogQL, SQL czy InfluxQL. Punkty kontaktowe obejmują Slack, e-mail, PagerDuty, Opsgenie, webhook, Telegram, Discord, VictorOps i Microsoft Teams. Polityki powiadomień sterują routingiem, grupowaniem i częstotliwością powtarzania, a wyciszenia pozwalają uciszyć alert na czas planowanej konserwacji. Masz jedną konsolę dla alertów ze wszystkich źródeł - i koniec z sytuacją, w której jeden alert żyje w Prometheusie, inny w Loki, a jeszcze inny tylko w SQL.

Terminologia: refresh interval (interwał odświeżania), live data (dane na żywo), query cache (pamięć podręczna zapytań), Grafana Alerting (alertowanie Grafany), contact point (punkt kontaktowy), notification policy (polityka powiadomień), silence (wyciszenie), alert rule (reguła alertu).

Interwał odświeżania dashboardu to nie szczegół techniczny, lecz kompromis między świeżością danych a obciążeniem źródła, dobierany do roli odbiorcy. Ekran centrum operacyjnego pracuje na danych na żywo i odświeża się co pięć do trzydziestu sekund, bo operator śledzi rozwijający się incydent; widok menedżerski wystarczy odświeżać co pięć minut do godziny, bo tam akceptowalne są dane buforowane. Pamięć podręczna zapytań chroni Prometheusa przed nadmiarem żądań, ale kosztem chwili opóźnienia, i ten wybór robimy świadomie.

Drugim wątkiem tego slajdu jest alerting. Grafana Alerting v2 przenosi reguły z konfiguracji Prometheusa do Grafany i pozwala, by jedna reguła pytała jednocześnie wiele „języków”: PromQL dla metryk, LogQL dla logów oraz SQL dla danych relacyjnych, co daje jedną konsolę dla wszystkich źródeł. Powiadomienia trafiają przez punkty kontaktowe, takie jak Slack, poczta elektroniczna, PagerDuty czy Opsgenie, a polityki powiadomień i wyciszenia zarządza się z jednego miejsca. Wizualizacja i ostrzeganie działają tu razem.

Wyjaśnienie skrótów użytych na slajdzie:
HTTP – Hypertext Transfer Protocol – protokół HTTP; Protokół przesyłania danych telemetrycznych odświeżanych cyklicznie w oknie przeglądarki.
WebSocket – WebSocket protocol – protokół WebSocket; Połączenie dwukierunkowe stosowane w nowoczesnych interfejsach do strumieniowania metryk na żywo.
CPU – Central Processing Unit – procesor; Zasób stacji roboczej obciążany przy zbyt częstym odświeżaniu wielu złożonych paneli.
RAM – Random Access Memory – pamięć operacyjna; Pamięć przeglądarki wyczerpywana przy wielogodzinnym utrzymywaniu otwartych pulpitów o wysokiej częstotliwości odświeżania.
AM – Alertmanager – menedżer alertów Prometheus; Podsystem powiadomień współpracujący z regułami alertowymi definiowanymi bezpośrednio w Grafanie.

Udostępnianie dashboardów w dojrzałej organizacji to przede wszystkim podejście Dashboard as Code - traktowanie pulpitów jak kodu: kontrola wersji, CI/CD, provisioning i dzielenie się, zamiast ręcznego klikania w interfejsie. Trzy filary takiego podejścia to automatyczne wdrażanie z Git, kontrola dostępu przez uprawnienia folderów oraz wersjonowanie ze śladem audytowym i cofaniem zmian. Dashboard to kod, a nie seria kliknięć.

Pierwszy filar to wdrażanie z repozytorium, czyli swoisty GitOps dla dashboardów. Eksportujesz JSON dashboardu przez Export i Save as JSON, wkładasz go do repozytorium Git - jednego wspólnego albo per zespół - i konfigurujesz provisioning. W tym podejściu działa kontener sidecar, który obserwuje katalog dashboardów, albo ConfigMap na Kubernetesie - a Grafana przeładowuje dashboard automatycznie po każdej zmianie pliku. Git trzyma wtedy pojedyncze źródło prawdy, a interfejs służy wyłącznie do odczytu albo bardzo ograniczonych edycji. Takie podejście jest deklaratywne, łatwe do audytu i daje pełną możliwość cofania zmian.

Drugi filar to role i uprawnienia. Uprawnienia folderów rozdzielają pracę między zespoły: zespół A edytuje swój folder, zespół B ogląda wyłącznie swój. Na poziomie całej organizacji można też udostępniać publiczne linki dające anonimowy podgląd albo tworzyć migawki - statyczne obrazy dashboardu z konkretnego momentu. To zasada najmniejszych uprawnień w praktyce: folderowe uprawnienia izolują zmiany, więc zespół A fizycznie nie może popsuć dashboardów zespołu B.

Trzeci filar to wersjonowanie. Historia wersji dashboardu, dostępna pod ikoną zegara, pokazuje kto, co i kiedy zmienił, wraz z podglądem różnic - dodany albo usunięty panel, zmienione zapytanie czy progi. Jednym kliknięciem wracamy do poprzedniej wersji. Ślad audytowy przydaje się i do zgodności z wymaganiami regulacyjnymi, i do ustalenia, kto konkretnie zepsuł dashboard. Historia ewolucji to po prostu siatka bezpieczeństwa na wypadek błędu.

Terminologia: dashboard JSON (JSON pulpitu), provisioning (aprowizacja), sidecar (kontener sidecar), ConfigMap (konfiguracja Kubernetes), version history (historia wersji), snapshot (migawka statyczna), public dashboard (publiczny pulpit), folder permissions (uprawnienia folderu).

W dojrzałej organizacji udostępnianie dashboardów to przede wszystkim podejście dashboard jako kod: model JSON pulpitu ląduje w repozytorium Git, skąd provisioning automatycznie wdraża go do Grafany. Po każdej zmianie pliku kontener sidecar albo ConfigMap w Kubernetesie przeładowuje dashboard, a Git pozostaje pojedynczym źródłem prawdy. Dzięki temu pulpit przechodzi przez kontrolę wersji, przegląd kodu i potok CI/CD jak każdy inny artefakt oprogramowania, zamiast powstawać serią kliknięć w interfejsie.

Do tego dochodzą kontrola dostępu i historia zmian. Uprawnienia folderów rozdzielają pracę między zespoły, na przykład zespół A edytuje swoje foldery, a zespół B ma dostęp tylko do odczytu, a publiczne linki i migawki pozwalają pokazać dane osobom bez konta. Historia wersji pod ikoną zegara pokazuje, kto, co i kiedy zmienił, i pozwala cofnąć zmianę jednym kliknięciem; to jednocześnie ślad audytowy i siatka bezpieczeństwa na wypadek błędu.

Wyjaśnienie skrótów użytych na slajdzie:
URL – Uniform Resource Locator – ujednolicony lokalizator zasobów; Unikalny link internetowy z parametrami zakresu czasu i zmiennych umożliwiający bezpośrednie udostępnienie widoku.
RBAC – Role-Based Access Control – kontrola dostępu oparta na rolach; Mechanizm uprawnień gwarantujący, że udostępniony link nie otworzy się dla osób nieupoważnionych.
SSO – Single Sign-On – pojedyncze logowanie; Korporacyjny mechanizm logowania weryfikujący tożsamość odbiorcy udostępnionego dashboardu.
PDF – Portable Document Format – przenośny format dokumentu; Format generowania automatycznych raportów okresowych wysyłanych do interesariuszy biznesowych.
PNG – Portable Network Graphics – format grafiki rastrowej PNG; Format renderowania pojedynczych paneli przez wtyczkę Image Renderer na potrzeby powiadomień.

Antywzorce projektowania dashboardów czynią je nieprzydatnymi, mylącymi albo wręcz groźnymi. Najczęstsze grzechy to łamanie dostępności przez nieczytelne dla daltonistów kolory, przeciążenie poznawcze przez informacyjny szum oraz izolacja - budowanie pulpitu bez kontaktu z użytkownikami. Każdy z tych błędów to realny incydent spakowany w jedną lekcję; warto traktować tę listę jak zbiór doświadczeń zbieranych przez lata.

Zacznijmy od kolorów. Wykres z dwudziestu kolorów to chaos - mózg nie nadąża z interpretacją, a semantyka znika, gdy czerwony raz oznacza problem, a innym razem „wysoki priorytet", czyli coś dobrego. Najważniejsze: około 8 procent mężczyzn ma deuteranopię albo protanopię, więc zieleń i czerwień nie zawsze różnią się dla nich wystarczająco. Rozwiązanie jest gotowe - użyj palet przyjaznych daltonistom: ColorBrewer, domyślnych palet Grafany albo Viridis. Dostępność to po prostu czytelność dla wszystkich operatorów.

Drugi grzech to panele bez kontekstu. Panel bez tytułu, jednostki, progów i opisu zmusza odbiorcę do zgadywania, co właściwie ogląda. Każdy panel powinien mieć opisowy tytuł, na przykład „CPU Usage %, per instance", jednostkę percentunit, progi - jak linia SLO na wykresie - oraz opis w Markdownie, który tłumaczy, co panel mierzy i jak go czytać. Samodokumentujące się panele sprawiają, że dashboard czyta się sam, bez przechodzenia do dokumentacji.

Trzeci problem to zbyt wolne odświeżanie. Interwały jednominutowe albo pięciominutowe dla krytycznych metryk - CPU, latencji, wskaźnika błędów - opóźniają wykrycie problemu: skok trwa trzydzieści sekund, a dashboard odświeża się po minucie, więc operator widzi wszystko już po fakcie. Widoki operacyjne działają na interwale 5-30 sekund, menedżerskie mogą być buforowane, a pamięć podręczna w Grafanie ogranicza obciążenie Prometheusa. To balans między świeżością danych a wydajnością systemu.

A na koniec najbardziej podstępny z grzechów - izolacja. Dashboard zbudowany w samotności, bez rozmowy z użytkownikami: on-call, deweloperami i zarządem, prawie nigdy nie odpowiada na ich realne pytania. Dobra praktyka jest odwrotna: zaczynać od pytań, na które pulpit ma odpowiadać, budować minimalną wersję, dodawać panele pojedynczo na podstawie opinii użytkowników i trzymać wszystko w Git. Nie próbuj od razu zbudować idealnego dashboardu - zbuduj użyteczny i ewoluuj.

Błędy w projektowaniu dashboardów czynią pulpit nieprzydatnym, mylącym albo wręcz groźnym, dlatego warto znać je na pamięć, zanim zaczniemy budować własne widoki. Najczęstsze antywzorce to zbyt wiele kolorów w jednym panelu, panele bez kontekstu, to znaczy bez tytułu, jednostki i progów, zbyt wolne odświeżanie oraz budowanie dashboardu w izolacji, bez poznania potrzeb odbiorców. Każdy z tych grzechów to realny incydent spakowany w pojedynczą, pamiętną lekcję.

Kolory bez ładu oznaczają chaos i problemy z dostępnością, bo około ośmiu procent mężczyzn nie odróżnia zieleni od czerwieni; ratunkiem są palety przyjazne daltonistom, takie jak ColorBrewer czy Viridis. Panel bez kontekstu zmusza odbiorcę do zgadywania, co właściwie ogląda, a wolny interwał odświeżania opóźnia wykrycie problemu, bo skok trwający trzydzieści sekund zniknie, zanim dashboard odświeży się po minucie. I wreszcie pulpit budowany bez rozmowy z dyżurnymi, deweloperami i zarządem prawie nigdy nie odpowiada na ich prawdziwe pytania.

Wyjaśnienie skrótów użytych na slajdzie:
OOM – Out of Memory – wyczerpanie pamięci operacyjnej; Błąd przeglądarki lub serwera wywołany próbą wyrenderowania milionów punktów danych na jednym panelu.
DoS – Denial of Service – odmowa usługi; Niezamierzone przeciążenie bazy danych przez niewydajne, powtarzane automatycznie zapytania wielu użytkowników.
UX – User Experience – doświadczenie użytkownika; Zasady projektowania łamane przez upychanie dziesiątek paneli o jaskrawych kolorach na jednym ekranie.
UI – User Interface – interfejs użytkownika; Układ elementów stający się bezużytecznym szumem informacyjnym w sytuacjach kryzysowych.
TSDB – Time Series Database – baza danych szeregów czasowych; Silnik bazodanowy ulegający degradacji w przypadku braku agregacji w zapytaniach paneli.

Lista dobrych praktyk wizualizacji to ściągawka do przeglądu i krytyki własnych dashboardów. Sprowadza się do trzech filarów: skupienie zamiast gęstości - mniej serii na wykresie, małe wielokrotności; semantyka kolorów - spójne zasady obowiązujące na wszystkich pulpitach; oraz samodokumentujące się panele - opisowe tytuły, jednostki i progi. Każdy panel powinien przejść te trzy filary, zanim trafi do produkcji. To heurystyki projektowe, czyli inżynieria użyteczności, a nie kwestia gustu.

Pierwszy filar to skupienie zamiast gęstości. Jeden panel opowiada jedną historię i odpowiada na jedno pytanie. Unikaj dwudziestu serii na jednym wykresie - agreguj do rozsądnej liczby przez topk, bottomk albo sumę. A zamiast rysować dwadzieścia linii obok siebie, skorzystaj z małych wielokrotności: panel powtarzany per $instance zwraca dziesięć małych wykresów ułożonych w siatkę i porównywanie staje się natychmiastowe. Skupienie zamiast gęstości to po prostu ułatwienie poznawcze dla odbiorcy.

Drugi filar to spójność kolorów. Kolory mają stałe znaczenie: czerwony to błąd, awaria i stan krytyczny, zielony stan dobry, żółty ostrzeżenie, a niebieski informacja neutralna. Co kluczowe, spójność musi obowiązywać w całej organizacji: ten sam kolor za każdym razem musi oznaczać to samo - niedopuszczalne jest, by na jednym dashboardzie czerwony oznaczał błąd, a na innym wysoki priorytet. Mózg uczy się mapowania koloru na znaczenie, dlatego konsekwencja wprost przyspiesza czytanie wykresów.

Trzeci filar to samodokumentujące się panele. Tytuł panelu mówi, co oglądasz: „CPU Usage (%, per instance)", a nie samego „CPU". Jednostka - percentunit dla skali 0-100 albo percent_0_1 dla ułamków, a także bytes, Bps, s, ms, reqps czy ops - formatuje się automatycznie z przedrostkami SI. Opis w Markdownie tłumaczy, czym jest metryka, jakie obowiązują progi i jak interpretować wykres. Wtedy dashboard czyta się sam - spójność, czytelność i kontekst działają w jednej linii.

Terminologia: best practice (dobra praktyka), design heuristics (heurystyki projektowe), color semantics (semantyka kolorów), unit formatting (formatowanie jednostek), panel description (opis panelu), small multiples (małe wielokrotności), repeat panel (panel powtarzany), semantic colors (kolory semantyczne).

Po antywzorcach czas na pozytywną checklistę dobrych praktyk, które czynią dashboard czytelnym i nadającym się do działania. Naczelną zasadą jest skupienie zamiast gęstości: jeden panel odpowiada na jedno pytanie i opowiada jedną historię. Zamiast dwudziestu serii na jednym wykresie stosujemy małe wielokrotności, czyli panel powtarzany per instancja, który zwraca siatkę drobnych wykresów; porównywanie wartości staje się wtedy natychmiastowe, a nie wymaga przebrnięcia przez gąszcz legendy.

Druga praktyka to spójna semantyka kolorów: czerwony zawsze oznacza błąd i stan krytyczny, zielony stan dobry, żółty ostrzeżenie, a niebieski informację neutralną, i ta zasada obowiązuje na wszystkich dashboardach w organizacji, bo mózg uczy się mapowania koloru na znaczenie. Trzecia to panele samodokumentujące się: opisowy tytuł, jednostka, progi i opis w Markdownie sprawiają, że dashboard czyta się sam, bez sięgania po dokumentację. To heurystyki projektowe, a więc inżynieria użyteczności, nie kwestia gustu.

Wyjaśnienie skrótów użytych na slajdzie:
SI – International System of Units – Międzynarodowy Układ Jednostek Miar; Układ jednostek nakazujący spójne oznaczanie osi (np. bity vs bajty, sekundy vs milisekundy).
ISO – International Organization for Standardization – Międzynarodowa Organizacja Normalizacyjna; Normy dotyczące ergonomii i czytelności informacji wizualnej w systemach informatycznych.
UX – User Experience – doświadczenie użytkownika; Standardy kompozycji polegające na umieszczaniu krytycznych wskaźników w lewym górnym rogu ekranu.
UI – User Interface – interfejs użytkownika; Spójność palety barw (np. zieleń = norma, żółty = ostrzeżenie, czerwony = awaria krytyczna).
PEP – Python Enhancement Proposal – standard ulepszeń Pythona; Konwencja czytelności i czystości kodu przekładana na deklaratywne szablony paneli.

To studium przypadku jest warsztatem, na którym zbudujesz od zera pełny dashboard systemowy i połączysz wszystko, czego nauczyłeś się do tej pory: źródło danych, PromQL, zmienne, adnotacje i różne typy paneli w jednym produkcyjnym pulpicie. Składa się na niego cztery sekcje: CPU z progami, pamięć pokazana we wskaźnikowym ujęciu, latencja z linią SLO i sieć w bajtach na sekundę. Każdy panel ma gotowe zapytanie, konfigurację wizualną, progi i jednostki - ale budujesz go od zera, a nie kopiujesz gotowca.

Zaczynamy od CPU jako szeregu czasowego per instancja. Zapytanie `avg by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m])) * 100` rysuje linię dla każdej instancji, a na wykresie ustawiamy linię progu 80 procent jako ostrzeżenie oraz regułę alertu dla tempa wzrostu. Wizualnie: panel szeregu czasowego, linie per instancja, linia progu 80 procent, jednostka percentunit - panel zdrowia procesorów najpierw w skali globalnej, potem per maszyna.

Druga sekcja to pamięć w ujęciu procentowym. `node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100` podaje procent realnie dostępnej pamięci per instancja. Warto wiedzieć, że wartość MemAvailable obejmuje pamięć podręczną, która podlega zwrotowi systemowi, więc jest dokładniejszym wskaźnikiem presji pamięci niż surowy MemFree. Wizualnie stosujemy panel wskaźnikowy albo Stat ze sparkliną, próg krytyczny poniżej 20 procent i jednostkę percentunit. Presja pamięci to wczesne ostrzeżenie przed siekierą OOM killera.

Trzecia sekcja dotyczy czasu odpowiedzi. `histogram_quantile(0.95, rate(http_request_duration_seconds_bucket{job="api"}[5m]))` daje szereg czasowy latencji p95 per job, a na wykresie rysujemy linię progu SLO - na przykład 500 milisekund. Tak w praktyce realizuje się wizualne egzekwowanie SLO. p95 to standardowy wskaźnik w SLA, a opcjonalny drugi panel pokaże p99 dla ogona rozkładu. Wizualnie: szereg czasowy, linia SLO, jednostka ms.

Na koniec ruch sieciowy. `rate(node_network_receive_bytes_total{device="eth0"}[5m])` i analogiczne zapytanie dla transmisji dają ruch w bajtach na sekundę per interfejs. Jednostka Bps automatycznie otrzyma przedrostki SI - kBps, MBps - a wynik porównujesz z prędkością łącza: gigabit to 125 MB na sekundę. Wizualnie: panel szeregu czasowego z obszarem skumulowanym dla odbioru i nadawania. Nasycenie sieci to kolejne wczesne ostrzeżenie przed degradacją usług.

Na zajęciach zbudujemy ten dashboard krok po kroku w tej właśnie kolejności: źródło danych Prometheus, pierwszy panel, zapytanie PromQL, wizualizacja, zapis, zmienne $instance i $job oraz adnotacje z markerami wdrożeń. Nauka przez działanie, a nie przez oglądanie - to naturalne zakończenie tej części kursu: wszystko, czego się nauczyłeś, ląduje w jednym, produkcyjnym dashboardzie.

Całą dotychczasową wiedzę składamy teraz w jeden, działający produkt, czyli pełny dashboard systemowy. W studium przypadku zbudujemy go od zera na zajęciach, krok po kroku, dla przykładowej usługi: zaczniemy od źródła danych i pierwszego panelu, dodamy zapytania PromQL, wizualizacje, zmienne i adnotacje, by na końcu otrzymać produkcyjny pulpit. Będziemy budować od pustego ekranu, a nie kopiować gotowca, bo tylko wtedy ten przepływ pracy zostanie z tobą na stałe.

Składa się na niego cztery sekcje: CPU jako szereg czasowy per instancja z linią progu osiemdziesiąt procent, pamięć pokazana procentem realnie dostępnej pamięci z progiem krytycznym dwadzieścia procent, latencja jako szereg p95 z linią SLO, na przykład pięćset milisekund, oraz sieć w bajtach na sekundę z obszarem skumulowanym. Każdy panel dostaje gotowe zapytanie, jednostki i progi, a całość posłuży jako szablon, który zastosujesz potem we własnych projektach.

Wyjaśnienie skrótów użytych na slajdzie:
Nginx – Nginx web server and reverse proxy – serwer WWW i reverse proxy Nginx; Oprogramowanie serwera brzegowego udostępniające metryki ruchu HTTP i kodów stanu.
Apache – Apache HTTP Server – serwer WWW Apache; Klasyczny serwer aplikacji internetowych monitorowany pod kątem liczby aktywnych procesów roboczych.
PHP-FPM – PHP FastCGI Process Manager – menedżer procesów PHP FastCGI; Środowisko wykonawcze języka PHP monitorowane pod kątem wolnych procesów i nasycenia kolejki.
MySQL – MySQL Relational Database – relacyjna baza danych MySQL; System bazodanowy, z którego metryki zapytań i blokad tabel trafiają na pulpit studium przypadku.
Redis – Remote Dictionary Server – pamięć podręczna Redis; Baza danych w pamięci RAM monitorowana pod kątem współczynnika trafień pamięci podręcznej (hit ratio).

Ściągawka PromQL to kompendium wzorców do codziennej pracy i przeglądów zapytań: selekcja przez selektory etykiet, agregacje sum/avg/topk, funkcje czasu rate/increase/delta/irate oraz filozofia samego języka. Potraktuj ten slajd jak słownik szybkiego przywoływania: piszesz alert albo dashboard, otwierasz go, znajdujesz właściwy wzorzec i modyfikujesz pod swoje potrzeby. Nie wszystko trzeba trzymać w głowie - najważniejsze, by wiedzieć, gdzie szukać.

Zacznijmy od selektorów etykiet. `{job="api", instance=~"web-.*", method!="HEAD"}` pokazuje wszystkie warianty: dokładne dopasowanie ze znakiem równości, wyrażenie regularne z `=~`, a negacje z `!=` i `!~`. W jednym selektorze warunki łączą się koniunkcją - wszystkie muszą być spełnione jednocześnie. Precyzyjna selekcja wycina interesujące nas serie spośród miliona dostępnych. I jedna dobra rada: regex w składni RE2 jest wolniejszy niż dopasowanie dokładne, więc tam, gdzie tylko się da, wybieraj znak równości.

Kolejny klocek to agregacje. `sum by (job)` daje całkowite RPS w podziale na joby, `avg without (instance)` uśrednia bez podziału na instancje, `topk(5, ...)` wybiera pięć serii o najwyższych wartościach, a `count_values("status", ...)` zlicza wartości - czyli buduje rozkład kodów statusu: ile razy pojawiło się 200, 404, a ile 500. Grupowanie sterujesz dwoma słowami: by zachowuje wymienione etykiety, a without je usuwa. W ten sposób redukujesz setki serii do kilku kluczowych KPI.

Funkcje rate i increase są przeznaczone dla liczników: `rate(counter[5m])` to średnia szybkość na sekundę z obsługą resetów i ekstrapolacją, `increase(counter[1h])` - całkowity przyrost w oknie, równoważny iloczynowi rate przez 3600, a `delta(gauge[1h])` - zmiana wartości miernika w czasie. Pamiętaj, że rate() na mierniku to błąd logiczny. Te funkcje to fundament operacyjnego PromQL.

Na koniec warto zapamiętać trzy przymiotniki opisujące PromQL. Jest funkcyjny, bo składasz funkcje w kompozycje; wektorowy, bo operuje na wektorach, a nie skalarach; i deklaratywny, bo mówisz, co chcesz otrzymać, a nie jak to osiągnąć. Myślenie wektorami i etykietami to zmiana paradygmatu względem SQL. A ćwiczenie to klucz: pisz zapytania codziennie, eksploruj w trybie Explore, analizuj wyniki w Grafanie. Krzywa uczenia jest stroma na starcie - wektory, selektory, rate - a potem łagodnieje. Opanuj fundamenty, a reszta nauczy się sama.

PromQL to język funkcyjny operujący na wektorach, a nie na pojedynczych punktach, i zanim przejdziemy do dalszych przykładów, warto zebrać jego najważniejsze elementy w jednym miejscu. Ta ściągawka ułoży w całość to, co poznaliśmy dotąd: selekcję serii przez selektory etykiet, agregacje redukujące wymiarowość danych oraz funkcje czasu przeliczające surowe liczniki na tempo zmian. Potraktuj ją jak słownik szybkiego przywoływania, do którego wracasz przy pisaniu własnych zapytań i reguł.

Filtrowania używamy przez =, !=, =~ i !~, pamiętając, że warunki w nawiasach klamrowych łączą się koniunkcją; agregacje przez sum by, avg without, topk i count_values redukują setki serii do kilku kluczowych KPI; a funkcje rate, increase i delta działają na wektorach zakresowych, przy czym rate i increase przeznaczone są wyłącznie dla liczników, a delta dla mierników. Zapamiętaj te wzorce, a nie pojedyncze składnie, bo powtarzają się w każdej metryce; biegłość przychodzi przede wszystkim z codziennych ćwiczeń w trybie Explore.

Wyjaśnienie skrótów użytych na slajdzie:
PromQL – Prometheus Query Language – język zapytań Prometheus; Zaawansowany język zapytań integrujący wektory chwilowe, macierze czasowe i wektory skalarne.
TSDB – Time Series Database – baza danych szeregów czasowych; Wielowymiarowa baza danych stanowiąca fundament analityczny zapytań PromQL.
SDK – Software Development Kit – zestaw narzędzi programistycznych; Biblioteki zapewniające właściwe typowanie metryk (Counter, Gauge, Histogram, Summary).
API – Application Programming Interface – interfejs programowania aplikacji; Programowy punkt dostępowy silnika ewaluacji reguł języka PromQL.
CLI – Command Line Interface – interfejs wiersza poleceń; Narzędzie promtool służące do weryfikacji składni zapytań PromQL przed wdrożeniem na pulpit.

Zapytania o CPU w PromQL prowadzą od szczegółowego rozkładu na tryby do uproszczonego procentu użycia, a CPU to najważniejszy zasób w monitoringu, bo jego nasycenie natychmiast objawia się skokami latencji. Dwa podejścia - szczegółowe per tryb i uproszczone jako sto minus procent bezczynności - wraz z gotowymi wzorcami tworzą kartę referencyjną do budowy alertów i dashboardów CPU.

Pierwsza opcja to rozkład CPU na poszczególne tryby. `sum by (mode) (rate(node_cpu_seconds_total[5m]))` rozbija wartość na user, czyli przestrzeń użytkownika, system, czyli jądro, iowait, czyli czekanie na wejście-wyjście, idle, irq, softirq, steal, czyli czas kradzione przez hipernadzorcę, oraz guest dla maszyn wirtualnych. Wykres ze skumulowanym obszarem per tryb pokazuje, z czego składa się obciążenie. I już widzisz problem: wysokie iowait oznacza wąskie gardło dysku, wysokie system - koszt wywołań systemowych, a wysokie steal - głośnego sąsiada w chmurze.

Druga opcja jest uproszczona i prowadzi do jednej, czytelnej liczby. `100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100` daje procent czasu poza bezczynnością per instancja. Formuła działa, bo suma wszystkich trybów to zawsze sto procent, a zatem czas zajęty to sto minus czas bezczynności. Na wykresie jedna linia per instancja, linia progu 80 procent jako ostrzeżenie i 90 procent jako stan krytyczny - taka metryka jest od razu gotowa do działania.

Zapytania zweryfikowaliśmy na testowym środowisku. Zacznij od szczegółowego `sum by (mode) (rate(node_cpu_seconds_total[5m]))` dla obszaru skumulowanego i widoku rozdzielonego per tryb, albo użyj uproszczonego `100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100` dla procentu użycia per instancja. Wreszcie kwestia wizualizacji zależy od pytania, na które odpowiadasz: linie per instancja porównują instancje między sobą, a obszar skumulowany po trybach pokazuje, co dokładnie obciąża procesor. Wybierz formę do pytania, a nie do gustu.

Praktykę zapytań zaczynamy od CPU, najczęściej monitorowanego zasobu, bo jego nasycenie natychmiast objawia się skokami latencji i zakłóceniami na wykresach. Najprostszy wzorzec sprowadza się do zapytania sto minus średni procent czasu bezczynności, policzony funkcją rate na wektorze zakresowym, czyli 100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100, które daje jedną, czytelną liczbę użycia per instancja. To najważniejsza metryka przy planowaniu pojemności i podejmowaniu decyzji o skalowaniu.

Do tego dochodzi widok szczegółowy: sum by (mode) (rate(node_cpu_seconds_total[5m])) rozbija obciążenie na tryby: user, system, iowait, irq, steal oraz idle, i w obszarze skumulowanym pokazuje, z czego składa się zużycie procesora. Wysokie iowait oznacza wąskie gardło dysku, wysokie system koszt wywołań systemowych, a wysokie steal głośnego sąsiada w chmurze. Alerty wznosimy powyżej osiemdziesięciu procent jako ostrzeżenie i powyżej dziewięćdziesięciu jako stan krytyczny.

Wyjaśnienie skrótów użytych na slajdzie:
CPU – Central Processing Unit – procesor; Podsystem obliczeniowy mierzony w podziale na czas spędzony w przestrzeni użytkownika, jądra i oczekiwania na we/wy.
SMP – Symmetric Multiprocessing – wieloprocesorowość symetryczna; Architektura serwerowa z wieloma rdzeniami CPU wymagająca zaprezentowania rozkładu obciążenia per rdzeń.
VM – Virtual Machine – maszyna wirtualna; Środowisko zwirtualizowane, w którym metryka cpu_steal wskazuje na rywalizację o zasoby na hoście fizycznym.
OS – Operating System – system operacyjny; Jądro Linuksa udostępniające surowe liczniki czasu CPU w pliku /proc/stat.
PromQL – Prometheus Query Language – język zapytań Prometheus; Język przeliczający liczniki sekund CPU na ułamkowy lub procentowy stopień utylizacji.

Zapytania o pamięć w PromQL podają wartości bezwzględne w megabajtach i procent dostępności, a wszystko opiera się na jednym, kluczowym rozróżnieniu: MemAvailable mierzy pamięć realnie dostępną bez presji ze strony pamięci podręcznej, a MemFree tylko liczbę wolnych stron, z których cache system może jeszcze odzyskać. Z tego powodu MemAvailable jest głównym wskaźnikiem presji pamięci i to na nim włączamy alerty poniżej 15-20 procent. Gotowe zapytania tworzą kartę referencyjną dla dashboardów pamięci.

Wartości bezwzględne wyglądają tak: `node_memory_MemAvailable_bytes / 1024 / 1024` pokazuje, ile pamięci w megabajtach jest dostępnej dla nowych procesów. MemAvailable uwzględnia strony cache, które system może natychmiast zwrócić, gdy zgłosi się nowy proces - to nie MemFree, która te strony pomija. Innymi słowy, MemAvailable to pamięć, którą naprawdę dostanie malloc(). Wartości bezwzględne służą głównie do planowania pojemności - ile megabajtów nam jeszcze zostało.

Procent dostępności to wskaźnik presji pamięci: `node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100`. Alert włączamy, gdy spadamy poniżej 15-20 procent - to właśnie presja pamięci. Poniżej 10 procent robi się krytycznie, bo rośnie ryzyko wyzwolenia zabójcy OOM; zakres 10-15 procent to ostrzeżenie, a wszystko powyżej 20 oznacza stan zdrowy. Na tym wskaźniku działa wczesne ostrzeganie przed OOM killerem.

Dla pełnego obrazu dodajmy perspektywę odwróconą: `1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)` razy 100 procent da procent zajętości. Obie perspektywy są poprawne, a wybór zależy od kontekstu: procent zajętości do planowania pojemności i obserwacji trendu wzrostu, procent dostępności do alertów i progów. W bloku konsoli znajdziesz oba gotowe zapytania - zweryfikowane na testowym środowisku, więc możesz je kopiować wprost do dashboardów i alertów, bez ryzyka literówek.

W zapytaniach o pamięć najważniejszy jest właściwy dobór metryki źródłowej, bo od niego zależy poprawność alertów i dashboardów. Kluczowe rozróżnienie dotyczy wartości MemAvailable i MemFree: MemAvailable obejmuje strony pamięci podręcznej, które system może natychmiast zwrócić nowemu procesowi, więc jest to pamięć realnie dostępna dla aplikacji, natomiast MemFree liczy tylko wolne strony i tę rezerwę pomija. Dlatego wskaźnikiem presji pamięci zawsze będzie MemAvailable, zgodnie z dokumentacją Prometheusa i node_exportera.

Miarą alarmową jest procent dostępności: node_memory_MemAvailable_bytes podzielone przez node_memory_MemTotal_bytes i pomnożone przez sto; gdy wynik spada poniżej dwudziestu procent, mówimy o presji pamięci, a poniżej dziesięciu włączamy stan krytyczny, bo rośnie ryzyko aktywacji zabójcy OOM. Do planowania pojemności przydają się też wartości bezwzględne w megabajtach, uzyskiwane przez dwukrotne podzielenie przez 1024. Obie perspektywy są poprawne, a wybór zależy od celu: procenty służą alertom, bajty trendom wzrostu.

Wyjaśnienie skrótów użytych na slajdzie:
RAM – Random Access Memory – pamięć operacyjna; Główny zasób pamięciowy serwera wizualizowany z uwzględnieniem pamięci buforowej i podręcznej stron.
VFS – Virtual Filesystem Switch – wirtualny przełącznik systemu plików; Warstwa jądra, której pamięć podręczna (dentry, inode) może być w razie potrzeby zwalniana dla aplikacji.
SWAP – Swap Space – przestrzeń wymiany na dysku; Partycja lub plik wymiany, której zapełnianie sygnalizuje niedobór fizycznej pamięci RAM.
OOM – Out of Memory – wyczerpanie pamięci operacyjnej; Zdarzenie systemowe, którego wystąpienie należy bezzwłocznie wyeksponować na pulpicie operacyjnym.
OS – Operating System – system operacyjny; Podsystem zarządzania pamięcią jądra dostarczający dane telemetryczne do Node Exportera.

Funkcja predict_linear() analizuje dynamikę spadku wolnego miejsca i ostrzega przed zapełnieniem dysku w horyzoncie 24 godzin.

Zapytania o dysk w PromQL śledzą wolną i zajętą przestrzeń oraz procent użycia per punkt montowania, z filtrami rodzaju systemu plików, które pomijają wolumeny wirtualne. Pokazują też różnicę między wartościami avail i free oraz prognozują moment zapchania dysku funkcją predict_linear. Alerty działają powyżej 80 i 90 procent użycia, a wizualizacja to ranking najpełniejszych wolumenów i trend dysku systemowego - czyli praktyczna karta planowania pojemności.

Na początek rozróżnienie dwóch niezwykle istotnych metryk. `node_filesystem_avail_bytes{mountpoint="/", fstype!="tmpfs"}` podaje przestrzeń dostępną dla zwykłego użytkownika - root ma bowiem zarezerwowane 5 procent, których aplikacja nie dostanie. `node_filesystem_free_bytes` to z kolei surowa wolna przestrzeń, łącznie z rezerwą roota. To rozróżnienie jest kluczowe dla alertów: aplikacja nie widzi zarezerwowanych stron, więc powinieneś ostrzegać na podstawie wartości avail.

Procent użycia wolumenu liczysz tak: `(node_filesystem_size_bytes - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100` - wynik dotyczy każdego punktu montowania z osobna. Progi przyjmujemy zwykle: powyżej 80 procent ostrzeżenie, powyżej 90 stan krytyczny, powyżej 95 awaryjny. Trend dysku systemowego prowadzi prosto do prognozy: predict_linear na `node_filesystem_avail_bytes` poda konkretną datę, kiedy wolumen będzie pełny. To planowanie pojemności z wyprzedzeniem - dodajesz dysk, zanim go zabraknie.

Filtry odgrywają tu ważną rolę. `fstype!="tmpfs|overlay|squashfs"` odsiewa systemy wirtualne: tmpfs trzymany w pamięci RAM, overlay z warstwami Dockera i squashfs tylko do odczytu. Punkt montowania `/` albo wzorce `/var|/home` zawężają listę do istotnych wolumenów. Bez tych filtrów dostaniesz sam szum: tmpfs bywa „zawsze pełny", bo to po prostu pamięć, a overlay zmienia się przy każdym wdrożeniu. Na koniec wizualizacja: bar gauge pokazuje dziesięć najpełniejszych wolumenów w rankingu, a szereg czasowy pokazuje trend dysku systemowego. Ranking odpowiada na pytanie, co jest najbardziej pełne, a trend - kiedy będzie pełne.

Pełny dysk to awaria, której nie zatrzymasz restartem usługi, dlatego monitorowanie przestrzeni dyskowej jest obowiązkowym elementem każdego dashboardu systemowego. Zanim napiszemy pierwsze zapytanie, warto rozróżnić dwie metryki: node_filesystem_avail_bytes podaje przestrzeń realnie dostępną dla aplikacji, a node_filesystem_free_bytes wartość surową, która zawiera rezerwę pięciu procent zarezerwowaną dla użytkownika root.

Procent użycia liczymy dla każdego punktu montowania z osobna i zawsze z filtrem fstype, który odsiewa wirtualne systemy plików - tmpfs trzymany w pamięci RAM, warstwy overlay kontenerów i systemy squashfs tylko do odczytu. Nad trendem dobudowujemy prognozę predict_linear, która poda konkretną datę wypełnienia wolumenu, a wizualizacja w bar gauge pokazuje dziesięć najpełniejszych dysków; alerty uruchamiamy powyżej 80 procent użycia, krytyczny powyżej 90.

Wyjaśnienie skrótów użytych na slajdzie:
SSD – Solid State Drive – dysk półprzewodnikowy; Nowoczesny nośnik pamięci masowej charakteryzujący się niskim czasem dostępu do danych.
HDD – Hard Disk Drive – klasyczny dysk magnetyczny; Dysk talerzowy podlegający monitorowaniu pod kątem nasycenia kolejki operacji we/wy.
RAID – Redundant Array of Independent Disks – nadmiarowa macierz niezależnych dysków; Technologia łączenia dysków zapewniająca odporność na awarię pojedynczego nośnika.
IOPS – Input/Output Operations Per Second – liczba operacji we/wy na sekundę; Liczba operacji dyskowych w jednostce czasu prezentowana na wykresie wydajności pamięci masowej.
VFS – Virtual Filesystem Switch – wirtualny system plików; Struktura logiczna partycji dyskowych monitorowana pod kątem wolnych bajtów i i-węzłów (inodes).

Zapytania o sieć w PromQL mierzą odbiór i nadawanie w bajtach na sekundę funkcją rate(), a mnożenie przez osiem zamienia bajty na bity, by porównywać wartości z przepustowością łącza. Filtry interfejsów odrzucają pętlę zwrotną i wirtualne karty. Ruch per interfejs oraz ostrzeżenie o nasyceniu powyżej osiemdziesięciu procent przepustowości to karta referencyjna monitoringu sieci, a w bloku konsoli znajdziesz oba gotowe zapytania.

Zaczynamy od odbioru i nadawania per interfejs. `rate(node_network_receive_bytes_total{device="eth0"}[5m])` oraz jego wariant ze transmit podają odbiór i nadawanie w bajtach na sekundę. Filtr `device="eth0"` albo wzorzec `device=~"eth.*|ens.*"` ogranicza listę do fizycznych kart. Dzięki temu dokładnie widzisz, który interfejs jest realnie obciążony, a które liczby pochodzą tylko z ruchu wewnętrznego.

Teraz rzecz najczęściej mylona - jednostki. `rate(counter[5m])` daje prędkość w bajtach na sekundę, a pomnożenie przez osiem zamienia ją na bity na sekundę, co umożliwia bezpośrednie porównanie z przepustowością łącza: gigabit to miliard bitów, czyli 125 megabajtów na sekundę. Wykorzystanie przepustowości liczysz jako stosunek ruchu do prędkości łącza, a alert ostrzega powyżej osiemdziesięciu procent i przechodzi w stan krytyczny powyżej dziewięćdziesięciu. Pamiętaj o tym rozróżnieniu, bo sieć „mówi" w bitach, a pamięć masowa w bajtach.

Filtry urządzenia mają jeszcze jedno zadanie: usuwać szum. Wybierasz fizyczne karty - eth0 albo wspomniany wzorzec - a wykluczasz pętlę zwrotną lo, karty Docker i veth oraz tunele tun, GRE czy ipip. Bez tych filtrów dostaniesz fałszywe sygnały: pętla zwrotna generuje duży ruch lokalny, a karty Dockerów dodają szum przy każdym kontenerze. Czyste dane to mniej fałszywych alertów - a w bloku konsoli masz dwa gotowe zapytania (odbiór i nadawanie) do wstawienia od razu w panel szeregu czasowego z obszarem skumulowanym.

Sieci nie opisujemy stanem interfejsu, lecz tempem przesyłanych danych, i to właśnie przepustowość decyduje o nasyceniu łącza. Podstawą jest funkcja rate() na licznikach bajtów - node_network_receive_bytes_total oraz node_network_transmit_bytes_total - która działa wyłącznie dla liczników, uwzględnia ich resety i zamienia skumulowany licznik na prędkość w bajtach na sekundę dla każdego interfejsu z osobna.

Najczęściej mylone są jednostki: sieć mówi w bitach, a Prometheus liczy w bajtach, dlatego mnożymy wynik przez osiem i dopiero wtedy porównujemy z pasmem - gigabit to 125 megabajtów na sekundę. Do tego dochodzi staranny filtr urządzeń, bo bez wykluczenia pętli zwrotnej lo, kart docker czy veth trafia na wykres sam szum; alert o nasyceniu uruchamiamy powyżej 80 procent przepustowości, a krytyczny powyżej 90.

Wyjaśnienie skrótów użytych na slajdzie:
NIC – Network Interface Card – karta sieciowa; Fizyczny interfejs ethernetowy lub interfejs wirtualny na serwerze.
MTU – Maximum Transmission Unit – maksymalny rozmiar jednostki transmisyjnej; Rozmiar pakietu sieciowego warunkujący brak fragmentacji na trasie transmisji.
CRC – Cyclic Redundancy Check – cykliczny kod nadmiarowy; Suma kontrolna ramki ethernetowej; błędy CRC wizualizowane są jako sygnał uszkodzenia kabla sieciowego.
TCP – Transmission Control Protocol – protokół sterowania transmisją; Protokół transportowy, dla którego monitoruje się retransmisje i stany gniazd sieciowych.
UDP – User Datagram Protocol – protokół datagramów użytkownika; Protokół bezpołączeniowy, którego wskaźnik utraty pakietów (packet drop) prezentowany jest na wykresie sieci.

Liczenie percentyli z histogramów przez histogram_quantile i sumowanie przedziałów po etykiecie le to jedna z najważniejszych umiejętności dla wskaźników latencji SLI i SLO. Sumę po le wykonujemy zawsze przed obliczeniem kwantyla - to warunek poprawności przy więcej niż jednej instancji. Warianty p50, p95, p99 i p99.9 oraz zmienna $quantile do szybkiej eksploracji to wiedza obowiązkowa dla każdego dashboardu i alertu latencji.

Sam wzorzec wygląda tak: `histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket{job="api"}[5m])))` daje latencję p99. Funkcja histogram_quantile interpoluje liniowo między przedziałami histogramu, a parametr phi wynoszący 0.99 oznacza p99, 0.95 - p95, a 0.5 - medianę. Pamiętaj o kolejności działań: najpierw sumujemy przedziały po le, dopiero potem liczymy kwantyl. Bez tego policzysz kwantyl dla pojedynczej instancji, a nie dla całej usługi.

Dlaczego sumowanie po le jest tak istotne? Etykieta le oznacza górną granicę przedziału - less or equal - a agregacja po niej sumuje liczniki w tych samych przedziałach ze wszystkich instancji, tworząc jeden, wspólny histogram. Dopiero taka suma przed kwantylem daje poprawny p99 dla całej usługi; jej brak przy kilku instancjach prowadzi do mylących wyników i mylących wniosków.

Na koniec kwestia wariantów. p50 to mediana, p95 standard w SLA, p99 latencja ogonowa, a p99.9 skrajny ogon. Zamiast budować cztery osobne panele, tworzysz zmienną $quantile z wartościami 0.5, 0.95, 0.99 i 0.999 i przełączasz percentyl na jednym wykresie z poziomu opcji zapytania. W ten sposób eksplorujesz ogon rozkładu bez mnożenia liczby paneli na dashboardzie.

Terminologia: histogram_quantile (kwantyl histogramu), p99 (percentyl 99), le label (etykieta górnej granicy przedziału), bucket aggregation (agregacja przedziałów), sum by (le) (sumowanie po le), latency SLI (wskaźnik latencji), SLO target (cel SLO).

Latencję usługi oceniamy percentylami z histogramów, bo mediana, czyli p50, mówi niewiele o najwolniejszych użytkownikach - to ogon rozkładu decyduje o odczuwanym komforcie. Histogram zbiera obserwacje w przedziały le, gdzie le oznacza górną granicę przedziału, a funkcja histogram_quantile interpoluje liniowo między nimi, dzięki czemu dowolny kwantyl wyliczamy po stronie serwera, bez podglądania danych z wnętrza aplikacji.

Kluczowa jest kolejność działań: najpierw sumujemy przedziały po etykiecie le ze wszystkich instancji - sum by (le) - a dopiero potem liczymy kwantyl, bo inaczej otrzymamy p99 pojedynczej maszyny zamiast całej usługi. Warianty przełączamy zmienną $quantile: mediana, p95 dla potrzeb SLA, p99 dla ogona i p99.9 dla skrajnych przypadków, co pozwala badać rozkład na jednym wykresie zamiast mnożyć liczbę paneli.

Wyjaśnienie skrótów użytych na slajdzie:
HTTP – Hypertext Transfer Protocol – protokół przesyłania dokumentów hipertekstowych; Podstawowy protokół komunikacji internetowej, którego opóźnienia podlegają rygorystycznej analizie.
REST – Representational State Transfer – architektura interfejsu REST; Standard interfejsów API, dla których czasy przetwarzania rozbija się na poszczególne metody i ścieżki.
API – Application Programming Interface – interfejs programowania aplikacji; Kluczowy punkt wejściowy do usług korporacyjnych chroniony celami jakościowymi SLO.
TTFB – Time To First Byte – czas do pierwszego bajtu; Czas oczekiwania klienta na rozpoczęcie nadawania odpowiedzi przez serwer aplikacyjny.
RTT – Round Trip Time – czas obiegu pakietu w sieci; Składnik sieciowy czasu odpowiedzi mierzony niezależnie od czasu przetwarzania logiki biznesowej.

Ten slajd obala trzy popularne mity o dashboardach: że ładne znaczy dobre, że auto-odświeżanie to czas rzeczywisty i że pulpit istnieje dla ozdoby. Każdy z tych mitów kryje się za realnym błędem popełnianym w produkcji, a zrozumienie trzech prawd za nimi stojących to zmiana nastawienia: od ładnego wykresu do prawdziwego narzędzia decyzyjnego.

Zacznijmy od urody. Estetyka jest w tym kontekście sprawą drugorzędną - liczy się działanie. Piękny dashboard dla zarządu i funkcjonalny dla operatora służą różnym celom i różnie się projektują: trzydzieści kolorów, gradienty i efekty trójwymiarowe to w praktyce obciążenie poznawcze, a nie wgląd w system. Każdy element - próg, jednostka, tytuł, opis - ma mieć operacyjny cel, a operator ma dostrzegać problem w trzy sekundy, a nie podziwiać oprawę.

Druga prawda dotyczy danych na żywo. Widoki operacyjne odświeżają się co 5-30 sekund, menedżerskie co 5 minut i rzadziej, a pamięć podręczna Grafany z własnym czasem życia i limitami współbieżnych zapytań zmniejsza obciążenie Prometheusa. Świadomość tego kompromisu oznacza wybór interwału odświeżania zależnie od roli dashboardu: świeżość kosztuje obciążenie, a dane buforowane to dane z opóźnieniem. Auto-odświeżanie nie jest więc równoznaczne z czasem rzeczywistym.

Trzecia prawda jest najważniejsza: dashboard to narzędzie wspierające decyzje. Ma odpowiadać na pytania operacyjne, a nie służyć za ozdobę: czy CPU przekracza 80 procent - pokaże linia progu; który endpoint ma najwyższy wskaźnik błędów - panel topk; ile zostało budżetu błędów - wskaźnik. To narzędzie, które pozwala podjąć decyzję bez czytania dokumentacji i bez pytania kolegi o zdanie. Dashboard to narzędzie operacyjne, nie raport do wieszania na ścianie.

Wokół dashboardów narosły mity, które w praktyce owocują realnymi błędami na produkcji, więc warto je obalić zanim zabierzemy się za kolejny pulpit. Najczęściej powtarzają się trzy: że dashboard ładny jest automatycznie dobry, że auto-odświeżanie równa się czasowi rzeczywistemu oraz że pulpit istnieje po to, by efektownie wyglądać na ścianie biura.

Każdemu mitowi przeciwstawiamy konkretną prawdę operacyjną: estetyka jest drugorzędna, bo liczy się, czy operator w trzy sekundy dostrzeże problem; buforowane dane są zawsze danymi z opóźnieniem, więc interwał odświeżania dobieramy do roli widoku - operacyjnego co 5-30 sekund, menedżerskiego co kilka minut; a sam dashboard ma odpowiadać na pytania takie jak czy CPU przekracza 80 procent zamiast tylko cieszyć oko.

Wyjaśnienie skrótów użytych na slajdzie:
SRE – Site Reliability Engineering – inżynieria niezawodności systemów; Dyscyplina techniczna, w której dashboardy są narzędziem diagnostyki, a nie bezużyteczną dekoracją biurową.
DevOps – Development and Operations – metodyka DevOps; Ruch organizacyjny promujący współdzielenie widoków telemetrycznych między deweloperami a operacjami.
ITIL – Information Technology Infrastructure Library – biblioteka infrastruktury IT; Zbiór praktyk procesowych wykorzystujący raporty z pulpitów do okresowych przeglądów usług.
NOC – Network Operations Center – centrum operacyjne sieci; Dział operacyjny, dla którego mitem jest potrzeba ciągłego wpatrywania się w setki wykresów bez alertów.
SOC – Security Operations Center – centrum operacji bezpieczeństwa; Zespół bezpieczeństwa integrujący pulpity incydentów z narzędziami klasy SIEM.

Współpraca nad dashboardami to nie praca każdej osoby w izolacji, lecz zestaw procesów, narzędzi i kultury: GitOps, przeglądy kodu, wspólne szablony i troska o higienę. Trzy filary takiej współpracy to regularne przeglądy, współdzielone panele biblioteczne i dashboard jako kod. To kultura inżynierska, w której pulpit traktuje się jak kod, a nie jak zbiór kliknięć w interfejsie.

Pierwszy filar to regularne przeglądy, czyli coś w rodzaju higieny dashboardów. Odpowiadają na proste pytania: czy panele są w ogóle używane - sprawdzisz to w statystykach użycia Grafany; czy zapytania są optymalne - po czasie wykonania i liczbie serii; czy progi są aktualne - a to pytanie, czy SLO nie zmieniło się od ostatniego przeglądu; i czy każdy panel ma jasno wskazanego właściciela, na przykład przez etykietę owner. Nieużywane panele to szum, wolne zapytania obciążają Prometheusa, a nieaktualne progi rodzą fałszywe alerty.

Drugi filar to panele biblioteczne, czyli praktyczne zastosowanie zasady DRY. Panel biblioteczny to współdzielony, wielokrotnego użytku gotowiec - jeden wspólny panel CPU z biblioteki bywa używany w pięćdziesięciu różnych dashboardach. Szablony dashboardów trzymasz w Git, parametryzujesz je zmiennymi, a provisioning przez sidecar lub ConfigMap ładuje je automatycznie. Zmiana w jednym miejscu aktualizuje wszystkie pulpity - panel biblioteczny jest po prostu jednym źródłem prawdy dla wspólnych widoków.

Trzeci filar to pełne wdrożenie podejścia Dashboard-as-code. Dashboard trafia do repozytorium Git jako JSON albo Jsonnet, przechodzi przez CI z walidacją i testami, a wdrożenie odbywa się automatycznie przez provisioning - sidecar, ConfigMap albo operator Grafany. Zmiany przechodzą przegląd we wniosku pull request: czy progi są właściwe, czy jednostki poprawne, czy tytuł opisowy. Kontrola wersji daje ślad audytowy, łatwe cofanie zmian i współpracę. Dashboard to kod, nie kliknięcia.

Terminologia: dashboard as code (pulpit jako kod), library panel (panel biblioteczny), provisioning (aprowizacja), sidecar (kontener towarzyszący), jsonnet (język szablonów), grafana/libsonnet (biblioteka Grafany), CI for dashboards (CI dla dashboardów).

Dobry dashboard nie powstaje w izolacji, tylko w zespole, w którym pulpit traktuje się jak wytwór wymagający przeglądów, współdzielenia i wrażliwości na odbiorców. Trzy filary tej współpracy to cykliczne przeglądy higieny, panele biblioteczne działające na zasadzie DRY oraz podejście dashboard-as-code z Git jako jedynym źródłem prawdy i provisioning w roli automatycznego wdrażania.

Przegląd miesięczny odpowiada na proste pytania: czy panele są w ogóle otwierane - sprawdzimy to w statystykach użycia Grafany, czy zapytania nie obciążają Prometheusa, czy progi nadal odpowiadają aktualnym SLO i czy każdy panel ma wskazanego właściciela, na przykład przez etykietę owner. Panel biblioteczny, czyli jeden współdzielony gotowiec, bywa z kolei używany w dziesiątkach dashboardów, a jego zmiana w jednym miejscu aktualizuje wszystkie kopie.

Wyjaśnienie skrótów użytych na slajdzie:
Git – Git version control system – system kontroli wersji Git; Narzędzie współpracy inżynierów umożliwiające śledzenie autorstwa i historii modyfikacji każdego panelu.
PR – Pull Request – propozycja włączenia kodu; Procedura zespołowej recenzji zmian w strukturze pulpitów przed wdrożeniem na produkcję.
CI/CD – Continuous Integration / Continuous Delivery – ciągła integracja i wdrażanie; Zautomatyzowany mechanizm testowania poprawności zapytań PromQL w pulpitach.
IaC – Infrastructure as Code – infrastruktura jako kod; Paradygmat traktujący definicje paneli i reguł alertowych na równi z kodem źródłowym aplikacji.
Wiki – Internal Technical Documentation – wewnętrzna dokumentacja techniczna; Repozytorium wiedzy inżynierskiej, do którego prowadzą odnośniki z opisów paneli analitycznych.

Zasady architektury Dashboard-as-Code: W nowoczesnej inżynierii SRE ręczne tworzenie i edytowanie pulpitów w interfejsie graficznym traktowane jest jako dług techniczny. Dashboardy powinny być traktowane z takim samym rygorem jak kod aplikacji: definiowane w postaci deklaratywnych manifestów JSON lub generowane za pomocą języka Jsonnet (narzędzie Grafonnet), wersjonowane w systemie Git i automatycznie wgrywane do serwera za pomocą wbudowanego mechanizmu provisioning. Zapewnia to pełną audytowalność zmian, możliwość recenzji modyfikacji w procesie Pull Request oraz natychmiastowe odtworzenie całego środowiska w razie awarii serwera.

Ręczne modyfikowanie pulpitów w środowisku produkcyjnym prowadzi do rozbieżności konfiguracyjnych i utraty historii zmian. Nowoczesny standard SRE zakłada definiowanie pulpitów jako kodu źródłowego przy użyciu biblioteki Grafonnet (język Jsonnet) lub oficjalnego modułu Terraform Provider for Grafana. Modele podlegają procedurze Code Review na gałęziach Git i są automatycznie synchronizowane na środowiska docelowe.

Podejście Dashboard-as-code traktuje pulpity jak zwykły kod: wersjonowanie w Git, CI/CD, Jsonnet do szablonowania i automatyczne wdrażanie zamiast klikania w interfejsie. Trzy filary to Git jako jedno źródło prawdy, Jsonnet do generowania dashboardów programowo i provisioning, czyli automatyczne ładowanie ich do Grafany. Dashboard to kod, nie seria kliknięć.

Pierwszy filar to Git jako jedyne źródło prawdy. JSON dashboardu leży w repozytorium, a ArgoCD, Flux albo operator Grafany synchronizują go do Grafany. Interfejs staje się miejscem tylko do odczytu albo bardzo ograniczonych edycji, a wszelkie zmiany przechodzą przez pull request - tak, jak to robi się z kodem aplikacji. Deklaratywne dashboardy definiują pożądany stan w kodzie, a historia Git to jednocześnie ślad audytowy, narzędzie do cofania zmian i podstawą współpracy zespołowej. Tę tematykę rozwiniesz szerzej przy okazji szerszego omówienia GitOps.

Drugi filar to automatyczne wdrażanie, czyli GitOps dla dashboardów. Wybór narzędzia zależy od środowiska: operator Grafany (grafana-operator) definiuje zasoby GrafanaDashboard jako natywne obiekty Kubernetes, grafonnet to biblioteka Jsonnet składająca komponenty Grafany, a dostawca Terraform (terraform-provider-grafana) zarządza dashboardami z poziomu infrastruktury jako kodu. Każde z tych narzędzi prowadzi potok CI/CD od walidacji, przez testy, po wdrożenie - deklaratywnie, w sposób możliwy do audytu i cofnięcia.

Trzeci filar to Jsonnet - język szablonów dla JSON. Wprowadza zmienne, funkcje, mixiny i importy, a biblioteka grafonnet dobudowuje komponenty właściwe Grafanie: panele, wiersze, zapytania, progi i zmienne. Dashboardy stają się wtedy w pełni programowalne: pętle generują sto instancji, funkcje służą jak generator powtarzalnych paneli, a parametry rozbijają konfigurację per środowisko. Koniec z kopiowaniem JSON-a ręcznie - generator piszesz raz i używasz wszędzie tam, gdzie trzeba.

Terminologia: jsonnet (język szablonów), provisioning (aprowizacja), grafana-operator (operator K8s), grafonnet (biblioteka Jsonnet), dashboard as code (pulpit jako kod), gitops for dashboards (GitOps dla dashboardów), terraform provider (provider Terraforma).

Dashboard-as-code odwraca nasz zwykły sposób myślenia o pulpitach: zamiast serii kliknięć w interfejsie mamy wersjonowany kod, który przechodzi przez przegląd, testy i automatyczne wdrożenie. Dzięki temu dashboard przestaje być prywatną własnością osoby, która go stworzyła, a staje się zwykłym artefaktem repozytorium - jednym źródłem prawdy, z historią zmian i możliwością cofnięcia każdej edycji.

W praktyce sięgamy po trzy narzędzia: operator Grafany definiuje dashboardy jako natywne obiekty Kubernetes, provider Terraforma zarządza nimi z poziomu infrastruktury jako kodu, a grafonnet to biblioteka Jsonnet, która wprowadza zmienne, funkcje, mixiny i pętle - dzięki nim jedna funkcja generuje dziesiątki podobnych instancji zamiast ręcznego kopiowania JSON. Potok CI/CD domyka całość i prowadzi od walidacji, przez testy, po wdrożenie.

Wyjaśnienie skrótów użytych na slajdzie:
IaC – Infrastructure as Code – infrastruktura jako kod; Filozofia zarządzania zasobami teleinformatycznymi za pomocą deklaratywnych plików konfiguracyjnych.
JSON – JavaScript Object Notation – notacja obiektowa JavaScript; Format reprezentacji danych wyjściowych generowany przez narzędzia programowe do opisu pulpitów.
Git – Git version control system – rozproszony system kontroli wersji; Pojedyncze źródło prawdy dla wszystkich definicji dashboardów w organizacji.
CI/CD – Continuous Integration / Continuous Deployment – ciągła integracja i automatyczne wdrażanie; Potok synchronizujący zmiany z repozytorium do środowisk Grafany bez ingerencji człowieka.
Terraform – Terraform by HashiCorp – narzędzie Terraform; Platforma orkiestracji infrastruktury zarządzająca zasobami Grafany (użytkownicy, źródła danych, panele).

Analiza danych historycznych w Grafanie i PromQL polega na porównaniu teraźniejszości z przeszłością: przesunięcie zakresów w PromQL przez offset, selektor zakresu czasu w Grafanie i przyciski przesunięcia. Takie porównania wykrywają anomalie bez uczenia maszynowego, pozwalają dostrzec sezonowość i pomagają w planowaniu pojemności. Odpowiadają na jedno proste pytanie - czy obecny stan jest normalny?

Pierwsze narzędzie to przesunięcia w PromQL, czyli modyfikator offset. Kolejne wartości cofają zapytanie w przeszłość: offset 1w cofa tydzień, offset 4w cztery tygodnie, czyli w praktyce miesiąc, a offset 1y pełny rok. Zapytanie rate(http_requests_total[5m] offset 1w) podaje zatem liczbę żądań na sekundę sprzed tygodnia, liczonym od tej samej sekundy. Kiedy porównasz to samo okno czasowe z poprzedniego dnia tygodnia i zobaczysz, że np. latencja jest dziś dwukrotnie wyższa niż przed tygodniem przy tym samym ruchu - masz bardzo prostą sygnaturę anomalii. Porównania rok do roku, tydzień do tygodnia i miesiąc do miesiąca wyłapują trendy długoterminowe i sezonowe bez uczenia maszynowego.

Drugie narzędzie to selektor zakresu czasu w Grafanie. Możesz wybrać zakres względny - ostatnia godzina, sześć godzin, 24 godziny, tydzień, miesiąc - albo bezwzględny, czyli własny przedział od-do. Na dodatek Grafana daje przyciski przesunięcia, które jednym kliknięciem cofają widok o godzinę, dzień albo tydzień, dzięki czemu natychmiast porównasz teraz z przeszłością. Selektor zakresu steruje też zmiennymi $__range i $__interval używanymi w zapytaniach, więc przyciski przesunięcia to praktycznie podróż w czasie bez pisania odpowiedniego PromQL.

Terminologia: time range compare (porównanie zakresów czasowych), offset (przesunięcie w PromQL), time shift (przesunięcie czasowe), historical comparison (porównanie historyczne), seasonality detection (wykrywanie sezonowości), year-over-year (porównanie rok do roku), week-over-week (porównanie tydzień do tygodnia).

Najprostszy sposób wykrywania anomalii nie wymaga uczenia maszynowego - wystarczy porównać teraźniejszość z przeszłością i zauważyć, co odbiega od oczekiwania. Modyfikator offset w PromQL cofa zapytanie o wybrany okres, a kiedy zestawimy dwie serie obok siebie, pytanie, czy obecny stan jest normalny, odpowiada sam wykres - bez modeli, bez kosztownej infrastruktury, a jedynie z odpowiednio dobranym zakresem porównania.

Pierwsze narzędzie to offset: wartość 1w cofa zapytanie o tydzień, 4w o cztery tygodnie, czyli w przybliżeniu miesiąc, a 1y o cały rok, co pozwala na porównania rok do roku, tydzień do tygodnia i miesiąc do miesiąca. Do tego Grafana daje selektor zakresu z przyciskami przesunięcia, które jednym kliknięciem cofają widok o wybrany interwał i sterują zmiennymi $__range oraz $__interval używanymi w zapytaniach.

Wyjaśnienie skrótów użytych na slajdzie:
LTS – Long Term Storage – długoterminowe składowanie danych; Rozwiązania (Thanos, Cortex, Mimir) umożliwiające analizę danych telemetrycznych z wielu miesięcy i lat.
S3 – Simple Storage Service – usługa magazynu obiektowego; Tanie i bezpieczne repozytorium obiektowe przechowujące archiwalne próbki telemetryczne.
TSDB – Time Series Database – baza danych szeregów czasowych; Silnik bazodanowy, którego retencja lokalna jest ograniczana w celu oszczędności pamięci masowej.
PromQL – Prometheus Query Language – język zapytań Prometheus; Język zapytań wykonujący obliczenia na danych archiwalnych w celu planowania pojemności (Capacity Planning).
BIA – Business Impact Analysis – analiza wpływu na biznes; Procedura oceny krytyczności procesów biznesowych wykorzystująca historyczne trendy obciążenia.

Raportowanie z Grafany to warstwa wyjściowa obserwowalności: dashboardy tworzy się dla ludzi, a raporty dla systemów i zarządu. Trzy filary to udostępnianie - linki, osadzenie, widoki publiczne - automatyczne raportowanie przez wtyczki i harmonogramy oraz formaty PDF, PNG i CSV. Cały potok prowadzi od dashboardu, przez raport, po interesariuszy.

Udostępnianie opiera się na linkach, osadzeniu i widokach publicznych. Opcja Udostępnij tworzy link z zapamiętanym zakresem czasu i zmiennymi albo skrócony adres. Osadzenie przez iframe dołącza widok tylko do odczytu w wiki, Confluence albo SharePoint, dając kontekst dokumentacji. Widok publiczny daje anonimowy, tylko do odczytu wgląd interesariuszom bez konta w Grafanie. Udostępnianie demokratyzuje dostęp do widoków.

Raporty okresowe działają automatycznie, na zasadzie ustaw i zapomnij. Wbudowane raportowanie Grafany (Reporting - Grafana Enterprise i Grafana Cloud) generuje PDF-y i pliki CSV oraz wysyła je e-mailem - codziennie, tygodniowo, miesięcznie, do wybranej listy odbiorców; Grafana Cloud Reports obsługuje raporty zarządzane z brandingiem i wieloma dashboardami. Do eksportu z linii poleceń w CI/CD służą między innymi społecznościowe grafana-reporter albo Grafana Image Renderer. Dashboard, harmonogram PDF i e-mail do zarządu co poniedziałek o ósmej - zero pracy ręcznej.

Terminologia: report (raport), snapshot (migawka), PDF export (eksport PDF), scheduled reports (raporty cykliczne), grafana-reporter (narzędzie eksportu), sharing (udostępnianie), embedding (osadzanie iframe), public dashboard (publiczny pulpit).

Dashboardy budujemy dla ludzi pracujących w czasie rzeczywistym, ale część odbiorców potrzebuje wiedzy w innej formie - jako cyklicznego raportu do spokojnej analizy. Grafana zamyka ten rozdział przez udostępnianie widoków: link z zapamiętanym zakresem czasu i zmiennymi, osadzenie przez iframe w wiki i dokumentacji oraz widoki publiczne, które dają interesariuszom anonimowy wgląd bez konta w systemie.

Warstwę automatyczną zapewnia wbudowane raportowanie Grafany: w Grafana Enterprise i Grafana Cloud raporty cykliczne (Reporting) wysyłają gotowe PDF-y i pliki CSV e-mailem - codziennie, tygodniowo albo miesięcznie - a eksport z linii poleceń, na przykład przez społecznościowe grafana-reporter albo Grafana Image Renderer, pozwala wpiąć generowanie raportów w potok CI/CD. Migawka z kolei zamraża widok jako statyczny obraz, który nie ulega zmianie nawet po zmianie zakresu czasu.

Wyjaśnienie skrótów użytych na slajdzie:
PDF – Portable Document Format – przenośny format dokumentu; Format generowania oficjalnych raportów dostępności usługi dla zarządu i klientów zewnętrznych.
CSV – Comma-Separated Values – wartości rozdzielane przecinkami; Format tekstowy eksportu surowych danych tabelarycznych do zewnętrznych arkuszy kalkulacyjnych.
SLA – Service Level Agreement – umowa o gwarantowanym poziomie usług; Formalne sprawozdanie z wywiązania się z kontraktu generowane automatycznie na koniec miesiąca.
KPI – Key Performance Indicator – kluczowy wskaźnik efektywności; Biznesowy wskaźnik podsumowywany w cyklicznych raportach z platformy analitycznej.
B2B – Business to Business – relacja przedsiębiorstwo-przedsiębiorstwo; Model relacji biznesowej, w którym raporty z Grafany stanowią załącznik do faktur rozliczeniowych.

Opanowanie PromQL, zasady projektowania dashboardów i analiza trendów to trzy filary pierwszej części wykładu 3 - swoista ściągawka do powtórki przed egzaminem, rozmową i certyfikacją: biegłość w zapytaniach, projektowanie zorientowane na działanie i operacje napędzane trendami.

PromQL w praktyce to przede wszystkim biegłość we wzorcach zapytań. Selekcja opiera się na wektorach chwilowych i zakresowych, filtry na dopasowaniu dokładnym, regexowym i negacji, a agregacje na funkcjach takich jak sum by, avg without czy topk. Z funkcji czasowych najważniejsze są rate, increase, histogram_quantile, delta i irate, a progi bool pozwalają zamienić filtrowanie na wartości binarne. Biegłość w PromQL to zapytanie napisane w trzydzieści sekund zamiast trzydziestu minut.

Projektowanie czytelnych pulpitów to zasady, które czynią dashboard działającym narzędziem. Hierarchia informacji trzyma krytyczne wskaźniki u góry, a szczegóły do zagłębienia na dole, a widoki per rola rozdzielają NOC i zarząd. Kolory semantyczne mówią jasno - czerwony zły, zielony dobry, żółty ostrzeżenie. Progi kreślą linie SLO, jednostki przeliczasz na format SI, zmienne służą do szablonowania, a adnotacje oznaczają wdrożenia i incydenty. To projektowanie nadające się do działania, a nie ozdabianie.

Analiza trendów prowadzi operacje naprzód, nie reaktywnie. Sezonowość rozpoznajesz przez linię bazową per godzina tygodnia, planowanie pojemności przez prognozowanie funkcją predict_linear i regresję liniową, a porównania historyczne przez przesunięcia offset 1w i 4w. Korelacja metryk RED i USE daje diagnostykę od góry w dół. Operacje napędzane trendami działają z wyprzedzeniem, nie reaktywnie.

Dobiegamy do pierwszej części podsumowania, która w trzech filarach zamyka najważniejsze treści całego wykładu trzeciego: biegłość w zapytaniach PromQL, zasady projektowania działających dashboardów oraz analizę trendów. Potraktujmy te slajdy jak ściągawkę do powtórki przed egzaminem i rozmową rekrutacyjną - każdy z filarów można przecież od razu sprawdzić w praktyce, choćby na własnym laboratorium.

W PromQL chodzi o biegłość we wzorcach: selekcja na wektorach chwilowych i zakresowych, filtry dokładne i regexowe, agregacje sum by, avg without oraz topk, a z funkcji czasowych rate, increase, delta i histogram_quantile. Projektowanie pulpitów opiera się na hierarchii, widokach per rola NOC i executive, kolorach semantycznych i liniach SLO, a analiza trendów na sezonowości, prognozie predict_linear oraz porównaniach z przesunięciem offset.

Wyjaśnienie skrótów użytych na slajdzie:
GUI – Graphical User Interface – graficzny interfejs użytkownika; Środowisko wizualnej percepcji danych telemetrycznych.
UX – User Experience – doświadczenie użytkownika; Ergonomia pulpitu operacyjnego skracająca czas reakcji w trakcie incydentów produkcyjnych.
PromQL – Prometheus Query Language – język zapytań Prometheus; Silnik logiczny zasilający panele Grafany w zagregowane dane liczbowe.
TSDB – Time Series Database – baza danych szeregów czasowych; System persystencji szeregów czasowych indeksowanych etykietami.
SRE – Site Reliability Engineering – inżynieria niezawodności systemów; Metodyka techniczna stawiająca czytelność danych ponad subiektywne przeczucia administratora.

Wzorce zapytań, dashboard jako kod i materiały do nauki to druga część podsumowania wykładu 3 - ściągawka do instrumentacji i wizualizacji, czyli warstwa zapytań i wdrażania dashboardów.

Zapytania do skopiowania i zmodyfikowania zawiera ściągawka wzorców: sum by (job), avg without (instance), topk(5, ...) oraz histogram_quantile(0.95, sum by (le) (rate(...bucket[5m]))). To kluczowe wzorce, które możesz od razu użyć w dashboardach i alertach: kopiujesz, modyfikujesz, wdrażasz. Ściągawka wzorców to biegłość w PromQL w praktyce.

Dashboard jako kod to przepływ znany z GitOps. JSON w Git trzymasz jako jedno źródło prawdy, Jsonnet i grafonnet służą do szablonowania - zmienne, funkcje, mixiny i importy - a provisioning przez sidecar, ConfigMap albo operator wdraża dashboardy automatycznie. Potok CI/CD prowadzi od walidacji, przez testy, po wdrożenie. Deklaratywne, do audytu, z testami i z możliwością cofnięcia.

Materiały do powtórki pochodzą wyłącznie z autorytatywnych źródeł. Ściągawka PromQL to prometheus.io/docs, najlepsze praktyki dashboardów - grafana.com/docs, wzorce reguł nagrywających - workbook Google SRE, a alerting - dokumentacja Grafana Alerting. Te linki to źródła pierwszej ręki, nie blogi i nie Stack Overflow. Ucz się od twórców technologii.

Druga część podsumowania dotyczy warstwy zapytań i wdrażania: wzorce, które kopiujemy i modyfikujemy, podejście dashboard-as-code oraz źródła, z których warto czerpać wiedzę. Cel jest prosty - aby po tym wykładzie państwo nie odtwarzali zapytań z pamięci, lecz sięgali po sprawdzone szablony i dokumentację pierwszej ręki, gotową do użycia w codziennej pracy.

Ściągawka wzorców obejmuje między innymi sum by (job), avg without (instance), topk(5, ...) oraz pełny wzorzec percentyla histogram_quantile(0.95, sum by (le) (rate(...bucket[5m]))), gotowy do wstawienia w panel czy alert. Wdrażanie domyka szablonowanie w Jsonnet i grafonnet oraz provisioning przez sidecar lub ConfigMap w potoku CI/CD, a autorytetem pozostają prometheus.io/docs, grafana.com/docs i sre.google/workbook.

Wyjaśnienie skrótów użytych na slajdzie:
IaC – Infrastructure as Code – infrastruktura jako kod; Praktyka zarządzania pulpitami poprzez kod wersjonowany w repozytorium.
Git – Git version control system – system kontroli wersji Git; Fundament pracy zespołowej nad dashboardami zapewniający audytowalność zmian.
CI/CD – Continuous Integration / Continuous Delivery – ciągła integracja i ciągłe wdrażanie; Automatyzacja publikacji paneli i adnotacji wdrożeniowych.
SLO – Service Level Objective – cel poziomu usług; Wskaźnik organizujący architekturę wizualną wokół budżetu błędów.
RBAC – Role-Based Access Control – kontrola dostępu oparta na rolach; Mechanizm gwarantujący bezpieczeństwo i separację uprawnień w platformie Grafana.

Antywzorce pracy z Grafaną czynią dashboardy bezużytecznymi, mylącymi albo groźnymi: łamanie dostępności przez kolory, przeciążenie poznawcze przez szum i izolacja, czyli brak kontaktu z użytkownikami. Każdy grzech to realny incydent spakowany w lekcję - lekcje dla projektantów dashboardów.

Pierwszy grzech to wartości wpisane na sztywno. Docelowa instancja albo job wpisane literalnie w zapytaniach dają dashboard działający tylko dla jednego hosta. Zmienne dają wielokrotne użycie, a szablonowanie to wymóg produkcyjny. Dashboard "dla web-01" zastępujesz dashboardem "dla wszystkich web" - jedna definicja, setki wariantów na potrzeby instancji, jobów i środowisk.

Drugi grzech to szum na pulpicie. Trzydzieści i więcej paneli bez hierarchii, z krytycznymi notowaniami nie na górze, pokazującymi wszystkie metryki naraz, to przeciążenie poznawcze - prawo Millera ogranicza pamięć roboczą do 7±2 elementów. Skupiaj się na tym, co wymaga decyzji, nie na wszystkim. Mniej znaczy więcej: maksimum 5-15 paneli, hierarchia z krytycznymi u góry i decyzje w sekundy.

Trzeci grzech to izolacja od zespołu. Dashboard budowany w izolacji przez programistę, który nie pyta dyżurnych, nie odpowiada na potrzeby nikogo: dyżurny potrzebuje kontekstu alertu, programista kontekstu debugowania, zarząd widoku biznesowego. Przegląd z udziałem użytkowników - spacer dyżurnego, opinia programisty, akceptacja zarządu - to projektowanie zorientowane na użytkownika. Bez kontaktu z odbiorcami dashboard nie służy nikomu.

Porady praktyczne sprowadzają się do rozwoju iteracyjnego. Zaczynaj od pytań - co chcemy wiedzieć, jakie decyzje podejmujemy. Zbuduj minimalną wersję z trzema-pięcioma krytycznymi panelami i iteruj, dodając panele pojedynczo na podstawie opinii. Zbieraj uwagi z retrospektywy dyżurnej, od programistów i z akceptacji zarządu, a wersje trzymaj w Git. Nie buduj idealnego dashboardu od razu - zbuduj użyteczny i ewoluuj.

Najczęstsze błędy przy pracy z Grafaną powtarzają się w niemal każdym zespole, a ich wspólnym mianownikiem jest dashboard, który w praktyce nie służy nikomu. Można je sprowadzić do trzech grzechów głównych: wartości wpisane na sztywno w zapytaniach, szum trzydziestu i więcej paneli bez hierarchii oraz praca w izolacji, bez kontaktu z dyżurnym, programistą i zarządem.

Każdy z tych błędów ma konkretną konsekwencję: literalnie wpisany host daje pulpit działający dla jednej maszyny, nadmiar paneli przeciąża pamięć roboczą ograniczoną według prawa Millera do siedmiu plus minus dwóch elementów, a brak odbiorców sprawia, że widok nie odpowiada na żadne decyzyjne pytanie. Rozwiązaniem jest rozwój iteracyjny: od pytań, przez minimalną wersję z kilkoma krytycznymi panelami, po opinie z retrospektywy i wersjonowanie w Git.

Wyjaśnienie skrótów użytych na slajdzie:
OOM – Out of Memory – awaria braku pamięci operacyjnej; Zatrzymanie procesu Grafany lub przeglądarki wywołane zapytaniem o nadmiernej kardynalności.
DoS – Denial of Service – odmowa usługi; Zablokowanie serwera bazodanowego przez brakujące agregacje i zbyt gęsty interwał odświeżania.
TLS – Transport Layer Security – bezpieczeństwo warstwy transportowej; Brak certyfikatu TLS narażający przesyłane dane telemetryczne na podsłuch w sieci.
API – Application Programming Interface – interfejs programowania aplikacji; Przeciążony interfejs serwera odpowiadający błędami 504 Gateway Timeout.
Proxy – Proxy mode in Grafana Data Source – tryb serwerowy źródła danych; Tryb odpytywania bazy chroniący poświadczenia przed wyciekiem do stacji roboczej klienta.

Zadania domowe, czyli praca ręczna w laboratorium, prowadzą od zera do produkcyjnego dashboardu: od źródła danych, przez panele, po panel SLO. Zadania są sekwencyjne - bez źródła danych nie zbudujesz panelu, a bez zapytań SLI nie powstanie panel SLO. Wszystkie polecenia zweryfikowaliśmy na testowym środowisku, więc kopiujesz, wklejasz i widzisz identyczny wynik, co buduje pewność i eliminuje hasło "u mnie nie działa".

Pierwsze zadanie to dodanie źródła Prometheus: Configuration, Data Sources, Add, wybór Prometheusa, adres http://prometheus:9090 i przycisk Save & Test, który powinien odpowiedzieć zielonym komunikatem, że źródło działa. Weryfikacja połączenia to fundament - bez źródła danych żaden panel nie zadziała. Tryb proxy, domyślny, dba o bezpieczeństwo i obsługę CORS po stronie serwera.

Drugie zadanie to zbudowanie pulpitu z metryk systemowych. CPU w panelu szeregu czasowego: avg by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m])) * 100 per instancja, z progiem 80 procent. RAM we wskaźnikowym albo statystycznym panelu: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100, z progiem krytycznym 20 procent. Sieć jako szereg czasowy: rate(node_network_receive_bytes_total{device="eth0"}[5m]) i transmit, w jednostce Bps. Dysk w bar gauge z procentem użycia per punkt montowania i progiem 80 procent. Te metryki to fundament każdego dashboardu.

Trzecie zadanie to wykonanie zapytań PromQL: powtórz zapytania ze slajdów 32-36 - CPU w procentach, RAM w procentach, dysk w procentach, sieć w bajtach na sekundę, latencja p95 i p99. Ćwiczenie buduje pamięć mięśniową: piszesz rate, sum by i histogram_quantile bez podglądania dokumentacji. Praktyka zapytań to biegłość w PromQL.

Czwarte zadanie to panel SLO. Wskaźnik budżetu błędów wyliczasz ze wzoru (1 - SLI) / (1 - SLO): przy dostępności na poziomie 99,95 procent i celu 99,9 procent zużycie budżetu wynosi (0,0005 / 0,001) czyli 50 procent. Progi: zielony poniżej 50 procent zużycia, żółty w zakresie 50-80, czerwony powyżej 80. Wizualizacja SLO pokazuje operatorowi w sekundy, ile budżetu błędów zostało - to operacyjna waluta na wykresie.

Praca własna to miejsce, w którym wiedza z całego wykładu przechodzi w umiejętności. Zadania są celowo sekwencyjne: nie zbudują państwo panelu bez działającego źródła danych, a panel SLO nie powstanie, dopóki nie opanujemy zapytań liczących SLI. Dlatego warto wykonywać je po kolei i każdy krok zaczynać od sprawdzenia poprzedniego - w ten sposób całość układa się w logiczną konfigurację przypominającą produkcyjne środowisko.

Zadanie pierwsze to połączenie z Prometheusem pod adresem http://prometheus:9090 i test Save & Test. Następnie budujemy pulpit: CPU z funkcją rate i progiem osiemdziesięciu procent, RAM z progiem krytycznym około dwudziestu, sieć w bajtach na sekundę i dysk w bar gauge. Na koniec latencja p95 oraz p99 i wskaźnik budżetu błędów liczony wzorem (1 - SLI) podzielone przez (1 - SLO), który przy dostępności 99,95 procent i celu 99,9 pokaże zużycie rzędu pięćdziesięciu procent.

Wyjaśnienie skrótów użytych na slajdzie:
VM – Virtual Machine – maszyna wirtualna; Środowisko wirtualne wykorzystywane przez studentów do uruchomienia instancji Grafany i bazy Prometheus.
LXC – Linux Containers – kontenery systemowe Linux; Lekkie kontenery środowiska ćwiczeniowego dla laboratoriów z wizualizacji danych.
Docker – Docker container platform – platforma konteneryzacji Docker; Środowisko uruchamiania gotowego stosu telemetrycznego za pomocą narzędzia docker-compose.
CLI – Command Line Interface – interfejs wiersza poleceń; Konsola tekstowa wykorzystywana do weryfikacji portów sieciowych (np. port 3000 dla Grafany).
GUI – Graphical User Interface – graficzny interfejs użytkownika; Konsola webowa, w której studenci budują swoje pierwsze panele analityczne.

Grafana to jedno okno na wiele źródeł: metryki z Prometheusa, logi z Loki, ślady z Tempo czy Jaegera, dane biznesowe z MySQL i PostgreSQL oraz dane chmurowe z CloudWatch czy Azure Monitor - wszystko z zunifikowanym alertingiem. Powiadomienia trafiają kanałami punktów kontaktowych: Slack, e-mail, PagerDuty, Opsgenie, webhook, Telegram, Discord, VictorOps i Teams. Jeden Grafana, wszystkie źródła, jeden interfejs alertów.

Źródła danych łączą cały stack obserwowalności w jednym miejscu. Prometheus z PromQL obsługuje metryki, Loki z LogQL logi, a Tempo, Jaeger i Zipkin z TraceQL ślady. MySQL i PostgreSQL dostarczają dane biznesowe przez SQL, CloudWatch metryki i logi AWS, Azure Monitor telemetrię Azure, a Elasticsearch logi i wyszukiwanie pełnotekstowe. Jeden dashboard może składać się z panelu metryk, panelu logów, panelu śladów i panelu biznesowego - ze wspólnym zakresem czasu, zmiennymi i adnotacjami. Zunifikowana obserwowalność to korelacja bez przełączania kontekstu.

Powiadomienia dostarcza zunifikowany alerting Grafany przez punkty kontaktowe. Slack przekazuje alerty na kanały ze wzmiankami, e-mail przez SMTP ze szablonami, PagerDuty z politykami eskalacji, Opsgenie z routowaniem, a webhooki pozwalają na własne integracje. Dostępne są też Telegram, Discord, VictorOps i Teams. Kanały powiadomień dostarczają alert właściwej osobie, właściwym kanałem i we właściwym czasie. Punkt kontaktowy decyduje, gdzie trafi alert.

Terminologia: plugins (wtyczki), connectors (konektory), data source plugins (wtyczki źródeł danych), panel plugins (wtyczki paneli), app plugins (aplikacje Kubernetes, AWS z gotowymi dashboardami i alertami), contact points (punkty kontaktowe), notification channels (kanały powiadomień).

Integracja to sedno zunifikowanej obserwowalności, o której mówiliśmy na początku wykładu: jedna platforma ma scalać metryki, logi, ślady i dane biznesowe, a nie zmuszać operatora do przeskakiwania między narzędziami. Ten slajd pokazuje, że Grafana nie kończy się na Prometheusie - jest hubem, do którego podłączamy kolejne źródła i systemy powiadomień bez zmiany sposobu pracy, co w praktyce oznacza korelację bez przełączania kontekstu.

Poza Prometheusem z PromQL do dyspozycji są Loki z LogQL, Tempo, Jaeger i Zipkin ze śladami oraz MySQL, PostgreSQL, CloudWatch czy Elasticsearch z danymi biznesowymi i chmurowymi. Równie ważny jest zunifikowany alerting: punkty kontaktowe Slack, e-mail, PagerDuty, Opsgenie czy webhook, każdy z własną polityką eskalacji i routowania, dostarczają alert właściwej osobie. To właśnie rozszerzalność przez wtyczki czyni z Grafany platformę, a nie zamknięte narzędzie.

Wyjaśnienie skrótów użytych na slajdzie:
Slack – Slack messaging platform – komunikator zespołowy Slack; Platforma powiadomień operacyjnych odbierająca zrzuty paneli z alertami z Grafany.
Teams – Microsoft Teams – platforma komunikacji Microsoft Teams; Komunikator korporacyjny zintegrowany z webhookami powiadomień telemetrycznych.
PagerDuty – PagerDuty incident response platform – platforma reagowania na incydenty; System przywoławczy dla inżynierów dyżurnych wyzwalany w przypadku naruszenia progów na panelach.
Webhook – HTTP Webhook – zwrotne wywołanie HTTP; Mechanizm powiadamiania zewnętrznych systemów za pomocą asynchronicznego żądania HTTP POST.
REST – Representational State Transfer – architektura REST; Standard interfejsu umożliwiający dwukierunkową integrację Grafany z zewnętrznymi bazami wiedzy.

Dashboard menedżerski tłumaczy techniczne metryki na język biznesu: zamiast "CPU 85 procent, p99 800 ms" menedżer widzi "dostępność usługi 99,97 procent przy celu 99,9" i "pozostało 72 procent budżetu błędów". To prosty język bez żargonu, raportowanie zgodności ze SLA - procent dostępności, minuty przestoju, incydenty, MTTR, zwroty - czyli przekład z inżynierskiego na biznesowy.

Prosty język bez żargonu to podstawa. Dashboard menedżerski nie mówi "latencja p99", tylko "99 procent użytkowników ma odpowiedź poniżej 500 milisekund". Zamiast surowych liczb widzi stwierdzenia: "dostępność usługi 99,97 procent (cel 99,9)", "pozostało 72 procent budżetu błędów", "w tym miesiącu 3 incydenty (cel poniżej 5)". Język biznesu to decyzje bez tłumaczenia - menedżer podejmuje decyzje o budżecie, personelu i priorytetach, patrząc na dashboard, i nie pyta, co to znaczy.

Raportowanie zgodności ze SLA obejmuje miesięczne sprawozdania: procent dostępności, minuty przestoju, liczbę incydentów, MTTR oraz należne zwroty, gdy umowa SLA została naruszona. Raportowanie biznesowe trzyma zarząd w świadomości ryzyka i kosztów. Raport to wkład w decyzje budżetowe i strategiczne.

Terminologia: executive dashboard (pulpit zarządczy), business metrics (metryki biznesowe), SLA reporting (raportowanie SLA), uptime report (raport o dostępności), error budget remaining (pozostały budżet błędów), management visibility (widoczność dla zarządu).

Dashboard menedżerski zamyka temat komunikacji z zarządem, który pojawił się przy okazji zasad dobrych pulpitów. To tutaj techniczne metryki, takie jak CPU czy p99, zamieniają się w język biznesu: dostępność, minuty przestoju, liczbę incydentów i pozostały budżet błędów. Chodzi o to, by decydent widział stan niezawodności usługi i podejmował decyzje bez pytania inżyniera, co właściwie oznacza dana liczba z wykresu.

Kluczem jest prosty język bez żargonu: zamiast p99 menedżer widzi stwierdzenie, że 99 procent użytkowników otrzymuje odpowiedź poniżej pięciuset milisekund. Raportowanie zgodności ze SLA obejmuje procent dostępności, minuty przestoju, incydenty, MTTR i należne zwroty przy naruszeniu umowy, a pozostały budżet błędów, na przykład 72 procent, staje się argumentem w decyzjach budżetowych i strategicznych organizacji.

Wyjaśnienie skrótów użytych na slajdzie:
CAPEX – Capital Expenditure – nakłady inwestycyjne; Wydatki na sprzęt fizyczny planowane na podstawie wykresów długoterminowego nasycenia serwerów.
OPEX – Operational Expenditure – wydatki operacyjne; Koszty bieżące utrzymania chmury optymalizowane dzięki identyfikacji nieużywanych maszyn wirtualnych.
TCO – Total Cost of Ownership – całkowity koszt posiadania; Łączny koszt infrastruktury teleinformatycznej raportowany kadrze zarządzającej.
ROI – Return on Investment – zwrot z inwestycji; Wskaźnik efektywności finansowej wdrożenia automatyzacji i monitoringu SRE.
SLA – Service Level Agreement – umowa o gwarantowanym poziomie usług; Dokument biznesowy, którego ryzyka kar finansowych są minimalizowane dzięki predykcji trendów.

Grafana Cloud, czyli zarządzana obserwowalność jako usługa, to alternatywa dla samodzielnych instalacji Grafany, Prometheusa, Loki i Tempo: zero operacji, bo infrastrukturą zarządza Grafana Labs, automatyczne skalowanie, wbudowaną wysoką dostępność i - na planach płatnych - umowę SLA na poziomie 99,5 procent. Darmowy poziom z 10 tysiącami serii, 50 gigabajtami logów i 50 gigabajtami śladów wystarczy na start i dla małych zespołów. Płacisz za zużycie, nie za infrastrukturę; decyzja kupuj a buduj rozstrzyga między usługą zarządzaną a własną instalacją.

Zarządzane instancje oznaczają zero operacji po Twojej stronie. Grafana Cloud w darmowym poziomie to zarządzany Prometheus do przyjmowania, przechowywania i odpytywania metryk, zarządzany Loki z przechowywaniem opartym na etykietach i tanią pamięcią masową oraz zarządzany Tempo ze śladami w magazynie obiektowym. Grafana Labs dba o aktualizacje, kopie zapasowe, wysoką dostępność, skalowanie i łatki bezpieczeństwa. Ty skupiasz się na dashboardach i alertach, nie na utrzymaniu stosu obserwowalności.

Skalowanie jest w pełni automatyczne i chmurowe. Przyjmowanie danych rośnie wraz z liczbą serii - więcej serii to po prostu więcej mocy przyjmowania. Magazyn rośnie w magazynie obiektowym, jak S3 czy GCS, właściwie bez limitu. Warstwa zapytań skaluje się przez query frontend i szardowanie. Architektura jest wielodzierżawcza z izolacją dzierżawców, a wysoka dostępność jest wbudowana - Grafana Labs gwarantuje na planach płatnych SLA na poziomie 99,5 procent. Przy automatycznym skalowaniu nie martwisz się o planowanie pojemności stosu obserwowalności.

Terminologia: Grafana Cloud (chmura Grafany), managed service (usługa zarządzana), hosted Prometheus (zarządzany Prometheus), hosted Loki (zarządzany Loki), hosted Tempo (zarządzany Tempo), multi-tenant (wielodzierżawczy), SaaS observability (obserwowalność jako usługa).

Grafana Cloud to odpowiedź na pytanie, które pojawia się przy każdej samodzielnej instalacji: kto będzie utrzymywać, skalować i aktualizować cały stos obserwowalności. Tutaj infrastrukturą zarządza Grafana Labs, a państwo otrzymują obserwowalność jako usługę z automatycznym skalowaniem i wbudowaną wysoką dostępnością. To naturalne dopełnienie tematów instalacyjnych oraz praktyczna okazja do decyzji kupuj a buduj.

W darmowym poziomie dostajemy dziesięć tysięcy serii metryk, pięćdziesiąt gigabajtów logów i tyle samo śladów, co wystarcza na start małego zespołu. Po stronie chmury pracują zarządzany Prometheus do przyjmowania danych, Loki z tanim magazynem obiektowym i Tempo, a architektura, wielodzierżawcza z izolacją dzierżawców, gwarantuje na planach płatnych SLA na poziomie 99,5 procent. Płaci się za zużycie, nie za infrastrukturę, co uwalnia nas od planowania pojemności stosu.

Wyjaśnienie skrótów użytych na slajdzie:
SaaS – Software as a Service – oprogramowanie jako usługa; Model chmurowy (np. Grafana Cloud), w którym zarządzanie serwerem i bazą leży po stronie dostawcy.
PaaS – Platform as a Service – platforma jako usługa; Środowisko chmurowe udostępniające gotowe bazy danych i środowiska uruchomieniowe dla telemetrii.
IaaS – Infrastructure as Service – infrastruktura jako usługa; Model wirtualnych maszyn w chmurze, na których administrator samodzielnie wdraża stos Grafany.
AWS – Amazon Web Services – chmura Amazon Web Services; Platforma chmurowa oferująca zarządzaną usługę Amazon Managed Grafana.
GCP – Google Cloud Platform – platforma chmurowa Google; Chmura obliczeniowa integrowana z Grafaną poprzez wtyczki telemetryczne Google Cloud Monitoring.

Instancja Grafany w środowisku korporacyjnym musi integrować się z centralnym systemem zarządzania tożsamością (IdP), takim jak Keycloak, z wykorzystaniem protokołów OpenID Connect (OIDC) i standardu tokenów IETF RFC 7519 (JWT). Obowiązuje ścisła separacja uprawnień (RBAC). Zgodnie z wytycznymi UODO, pulpity udostępniane szerokiej publiczności nie mogą prezentować danych identyfikujących użytkowników ani wewnętrznej topologii adresowej sieci.

Uprawnienia użytkowników opieramy na RBAC - Viewer, Editor i Admin per folder - oraz na uprawnieniach źródeł danych, które pozwalają tylko na zapytania, a nie na zarządzanie API. Logowanie jednokrotne działa przez SAML, OIDC i LDAP, a zasadą jest najmniejszy przywilej: domyślnie odczyt.

Ukrywanie wrażliwych danych polega na prostych regułach. Nie logujemy danych osobowych w metrykach ani etykietach, zmienne dashboardu nie zdradzają sekretów, adnotacje pozostają bez tajemnic, a wrażliwe pola podlegają maskowaniu. Tam, gdzie metryka niesie identyfikator użytkownika, zamieniamy go na hasz, a pełne dane zostawiamy poza obserwowanym stackiem.

Ten temat łączy się z kompetencjami etycznymi i poufnością: dane na dashboardach to dane operacyjne, nie biznesowe ani osobowe, a maskowanie i minimalizacja danych to również wymóg zgodności. Granica prywatności to część kultury pracy inżyniera obserwowalności.

Dashboardy pokazują informacje operacyjne o systemach, które bywają wrażliwe, dlatego kontrola dostępu nie jest tu dodatkiem, lecz fundamentem bezpiecznego monitoringu. Uwaga spoczywa na dwóch warstwach: kto i co może zobaczyć oraz jakie dane w ogóle trafiają do metryk i etykiet. Ta druga kwestia bywa niedoceniana, a to właśnie w niej leży największe ryzyko naruszenia prywatności i zgodności.

Dostęp sterujemy przez RBAC: Viewer czyta, Editor tworzy i modyfikuje w przypisanych folderach, a Admin zarządza użytkownikami i źródłami danych, przy czym uprawnienia źródeł ograniczają się do zapytań. Logowanie jednokrotne przez SAML, OIDC i LDAP, z domyślnym odczytem, realizuje zasadę najmniejszych uprawnień. W metrykach nie umieszczamy danych osobowych - tam, gdzie pojawia się identyfikator użytkownika, zastępujemy go haszem, a pełne dane zostają poza obserwowanym stosem.

Wyjaśnienie skrótów użytych na slajdzie:
RBAC – Role-Based Access Control – kontrola dostępu oparta na rolach; System uprawnień przydzielający role (Viewer, Editor, Admin) na poziomie organizacji i folderów.
OIDC – OpenID Connect – standard tożsamości OpenID Connect; Nowoczesna warstwa tożsamości na bazie OAuth 2.0 zapewniająca bezpieczne logowanie federacyjne.
OAuth2 – Open Authorization 2.0 – standard autoryzacji OAuth 2.0; Protokół autoryzacji pozwalający na logowanie do Grafany za pomocą kont GitHub, GitLab lub Google.
LDAP – Lightweight Directory Access Protocol – lekki protokół dostępu do usług katalogowych; Protokół integrujący Grafanę z korporacyjną bazą Active Directory.
RODO – Rozporządzenie o Ochronie Danych Osobowych – unijne rozporządzenie o ochronie danych; Regulacja prawna wymuszająca anonimizację adresów IP i danych osobowych prezentowanych na pulpitach.

Diagnostyka przez wizualizację to przepływ pracy: wykrycie anomalii na wykresie, zejście do logów i znalezienie przyczyny. Widzisz skok latencji, klikasz panel, wchodzisz w Explore logów w tym samym czasie, dostrzegasz ślad błędu ERROR i masz przyczynę w trzydzieści sekund. Zgrubne porównanie z normą, a potem zagłębienie w logi i ślady, to most do wykładu 4 o logach.

Najpierw wykrywasz anomalię w porównaniu z normą. Wykres latencji p99 z linią progu SLO pokazuje skok natychmiast. Linia bazowa z ostatnich siedmiu dni porównana z teraźniejszością daje odchylenie większe niż dwie sigmy - sygnał anomalii. Zgrubne porównanie odpowiada w sekundy, czy coś jest normalne: nie analizujesz logów, tylko patrzysz na wykres. Triage w sekundy.

Następnie zchodzisz do logów przez korelację metryk i logów. Klikasz punkt skoku na wykresie i wybierasz "logi dla tego śladu" albo otwierasz Explore w tym samym czasie. Zapytanie LogQL, na przykład {job="api"} |= "ERROR" | json | line_format "{{.message}}", pokazuje wpisy o wyczerpaniu puli połączeń i wolnych zapytaniach powyżej pięciu sekund. Korelacja metryk i logów daje przyczynę w trzydzieści sekund. Metryka mówi co, logi dlaczego, a przejście jest płynne dzięki wspólnemu zakresowi czasu i zmiennym.

Wątek diagnozy rozwija się w wykładzie 4 poświęconym logom. Tam poznasz zapytania LogQL, wykrywanie wzorców i anomalii, korelację metryk z logami oraz analizę przyczyn przez logi w Loki i ELK. Diagnostyka napędzana logami to kolejny poziom obserwowalności. Przygotuj się: uruchom Loki i Promtail, skonfiguruj zbieranie z katalogu /var/log i zapisuj logi aplikacji w Pythonie do Loki. Takie przygotowanie sprawia, że jesteś gotowy na wykład 4.

Ten slajd pokazuje, jak wizualizacja wspiera cały proces diagnostyczny, a nie tylko prezentację stanu systemu. Przepływ jest prosty: na wykresie dostrzegamy anomalię, schodzimy do logów w tym samym zakresie czasu i znajdujemy przyczynę. W tej logice metryki odpowiadają na pytanie, co się stało, a logi - dlaczego, co stanowi jednocześnie płynne przejście do tematyki czwartego wykładu.

Praktycznie wygląda to tak: skok latencji p99 ponad linię progu SLO widać natychmiast, porównujemy go z linią bazową z ostatnich siedmiu dni, a odchylenie większe niż dwie sigmy traktujemy jako sygnał anomalii. Kliknięcie punktu na wykresie otwiera logi dla tego samego czasu, a zapytanie LogQL z filtrem ERROR ujawnia wpisy o wyczerpanej puli połączeń i wolnych zapytaniach. Przyczynę znajdujemy w trzydzieści sekund.

Wyjaśnienie skrótów użytych na slajdzie:
RCA – Root Cause Analysis – analiza przyczyn źródłowych; Systematyczny proces dochodzenia do pierwotnej przyczyny incydentu prowadzony w oparciu o wykresy.
MTTR – Mean Time To Recover – średni czas usunięcia awarii; Podstawowy parametr sprawności zespołu operacyjnego skracany dzięki szybkiej wizualizacji korelacji.
MTTD – Mean Time To Detect – średni czas wykrycia problemu; Czas od początku anomalii do jej zauważenia na ekranie monitoringu.
SRE – Site Reliability Engineering – inżynieria niezawodności systemów; Kultura inżynierska opierająca diagnostykę na obiektywnych dowodach telemetrycznych.
Post-mortem – Blameless Post-mortem – analiza poawaryjna bez obwiniania; Raport z awarii, do którego dołącza się zrzuty wykresów z Grafany dokumentujące przebieg incydentu.

Analiza trendów zamyka całą pętlę: trend prowadzi do prognozy, prognoza do planowania pojemności, planowanie do optymalizacji, a optymalizacja do oszczędności. Dwa filary to prognozowanie z wyprzedzeniem i zmniejszanie rozmiaru zasobów, a integracja FinOps czyni inżynierię świadomą kosztów. Trend → prognoza → plan → optymalizacja.

Planowanie pojemności opiera się na prognozowaniu. Trend dysku, pamięci i CPU prowadzi do prognozy przez regresję liniową predict_linear albo modele ML, jak Prophet. Wzorzec predict_linear(node_filesystem_avail_bytes[30d], 14*86400) < 0 mówi, kiedy dysk się wyczerpie, a to przekłada się na decyzję, kiedy dodać pojemność. Planowanie budżetowe operuje kapitałem i kosztami operacyjnymi, a czas realizacji zamówienia serwera to często dwa-cztery tygodnie, więc zamawiasz z wyprzedzeniem. To skaling proaktywny.

Optymalizacja zasobów zajmuje się bezczynnym sprzętem i kosztami. CPU poniżej dziesięciu procent przez tydzień albo pamięć wolna powyżej osiemdziesięciu procent to sygnał, że instancja nadaje się do zmniejszenia rozmiaru albo zmiany typu. Przewymiarowane zasoby to zmarnowane pieniądze w rachunku za chmurę. Integracja FinOps to alokacja kosztów per usługa i zespół, pokaz i obciążenie zwrotne oraz rekomendacje optymalizacyjne. Optymalizacja kosztów to odpowiedzialność inżynierii, nie tylko finansów.

Terminologia: capacity planning (planowanie pojemności), forecasting (prognozowanie), resource optimization (optymalizacja zasobów), right-sizing (dopasowanie rozmiaru), FinOps (finanse operacyjne), cost optimization (optymalizacja kosztów), trend analysis (analiza trendów).

Analiza trendów domyka cykl, którym zajmowaliśmy się w tej części - od pomiaru, przez wizualizację, po decyzję. Trend prowadzi do prognozy, prognoza do planowania pojemności, a planowanie do optymalizacji kosztów. To wykazuje różnicę między inżynierią reaktywną, która czeka na awarię, a inżynierią proaktywną, która przewiduje wyczerpanie zasobów zanim nastąpi i planuje zakupy, zanim będzie za późno.

Prognozy wykonujemy funkcją predict_linear, która na podstawie trzydziestodniowego trendu potrafi orzec, że dysk będzie pełny za czternaście dni - a skoro czas realizacji zamówienia serwera wynosi od dwóch do czterech tygodni, pojemność zamawiamy odpowiednio wcześniej. Uzupełnia to zmniejszanie rozmiaru bezczynnych zasobów, gdy CPU spada poniżej dziesięciu procent, oraz FinOps z alokacją kosztów per usługa i zespół.

Wyjaśnienie skrótów użytych na slajdzie:
TSDB – Time Series Database – baza danych szeregów czasowych; Silnik analityczny realizujący obliczenia trendów na wielomiesięcznych zbiorach danych.
ML – Machine Learning – uczenie maszynowe; Metody statystyczne prognozujące trendy zapotrzebowania na pasmo sieciowe i moc obliczeniową.
SLO – Service Level Objective – cel poziomu usług; Punkt odniesienia dla długoterminowej analizy stabilności parametrów jakościowych.
Burn Rate – Burn Rate of Error Budget – tempo spalania budżetu błędów; Wskaźnik dynamiki zużycia marginesu błędów analizowany w horyzoncie tygodniowym i miesięcznym.
SRE – Site Reliability Engineering – inżynieria niezawodności systemów; Praktyka wyciągania wniosków z analizy trendów w celu planowania rozwoju architektury.

Bibliografia wykładu 3 to kuratowana lista autorytatywnych źródeł, która eliminuje przypadkowe googlowanie, przestarzałe blogi i błędy ze Stack Overflow - wszystkie linki działają, są aktualne i pochodzą z pierwszej ręki. To lista lektur obowiązkowych wykładu, pozwalająca uczyć się głęboko, nie powierzchownie.

Ściągawka terminów obejmuje pełny słownik kluczowych pojęć. SLI, czyli wskaźnik poziomu usługi; SLO, czyli cel poziomu usługi; SLA, czyli umowa poziomu usług; budżet błędów jako jeden minus SLO; tempo spalania budżetu; kardynalność, czyli liczba unikalnych serii; kwantyl i percentyl; histogram z przedziałami, sumą i licznikiem; summary z kwantylami po stronie klienta; miernik dla wartości góra/dół; licznik monotoniczny; reguła nagrywająca do wstępnego przetwarzania zapytań; reguła alertująca z wyrażeniem, czasem utrzymania, etykietami i adnotacjami. Każde pojęcie ma definicję, wzór tam, gdzie dotyczy, przykład w PromQL i powiązania. To słownik SRE - bez niego nie przeczytasz dokumentacji, nie zrobisz przeglądu kodu ani nie porozmawiasz z zespołem.

Artykuły o SLI/SLO pochodzą od twórców modelu SRE. Rozdział drugi workbooka Google SRE "Implementing SLOs" to kanon definicji, przykładów, budżetu błędów i tempa spalania. Artykuł "SLOs vs SLAs vs SLIs" z bloga Google Cloud tłumaczy różnice prostym językiem. Poradnik, jak wybierać SLO, prowadzi od ścieżki użytkownika, przez SLI i SLO, po budżet błędów i alerting. Praktyka wdrażania SLO w Prometheusie i Grafanie pokazuje reguły nagrywające, alerty na SLI i dashboardy. To autorytatywne źródła - nie opinie, nie case studies przypadkowych firm, nie marketing. Ucz się od twórców modelu SRE.

Wszystkie linki zostały zweryfikowane i działają. Dokumentacja Prometheusa obejmuje konfigurację, PromQL, przechowywanie, federację, dobre praktyki, biblioteki klientów, reguły alertujące i wykrywanie usług. Dokumentacja Grafany obejmuje źródła danych, panele, zmienne, adnotacje, provisioning, alerting, Loki i Tempo. Workbook SRE prowadzi przez rozdziały o wdrażaniu SLO, studiach przypadków SLO, monitorowaniu, alerting na SLO, eliminowaniu toil i prostocie. Rurociąg metryk Kubernetes łączy metrics-server, kube-state-metrics i adapter Prometheusa z automatycznym skalowaniem. Wszystkie adresy przetestowane - działają w wariancie HTTPS, bez błędów 404 i bez pętli przekierowań. To żywy dokument.

Bibliografia, którą państwo znajdą na tym slajdzie, to nie obowiązkowa lista odesłań, lecz praktyczny filtr jakości wiedzy. Uczenie się PromQL i Grafany z przypadkowych wpisów czy przestarzałych blogów szybko prowadzi do błędnych założeń, dlatego stawiamy na dokumentację twórców tych technologii. Te źródła pozostaną aktualne dłużej niż jakiekolwiek notatki z wykładu, więc warto do nich wracać przy każdym przeglądzie i aktualizacji konfiguracji.

Trzon bibliografii stanowią trzy dokumenty: prometheus.io z konfiguracją, PromQL i dobrymi praktykami, grafana.com z panelami, zmiennymi i provisioningiem oraz rozdział drugi workbooka Google SRE (Implementing SLOs) o celach poziomu usługi i budżecie błędów. Całość uzupełnia mini-słownik terminów - od SLI, SLO i tempa spalania po kardynalność i reguły nagrywające. Wszystkie adresy są zweryfikowane, aktualne i działają bez żadnych przekierowań.

Wyjaśnienie skrótów użytych na slajdzie:
ISO – International Organization for Standardization – Międzynarodowa Organizacja Normalizacyjna; Wydawca norm dotyczących ergonomii oprogramowania i jakości systemów teleinformatycznych.
IETF – Internet Engineering Task Force – Grupa Robocza Inżynierii Internetowej; Organizacja tworząca standardy protokołów sieciowych, w tym specyfikacje formatu JWT (RFC 7519).
RFC – Request for Comments – dokument standaryzacyjny RFC; Seria oficjalnych specyfikacji protokołów internetowych.
CNCF – Cloud Native Computing Foundation – Fundacja Oprogramowania Chmurowego; Środowisko otwartych technologii telemetrycznych i orkiestracji chmurowej.
PKN – Polski Komitet Normalizacyjny – krajowa jednostka normalizacyjna; Instytucja wprowadzająca europejskie standardy ergonomii i jakości oprogramowania do polskich przepisów.

Wykład 4 przechodzi od metryk, które mówią co, do logów, które mówią dlaczego. Postawimy obok siebie Loki z Grafana Labs - oparty na etykietach, tani, z natywną integracją z Grafaną - oraz ELK, czyli Elasticsearch, Logstash lub Fluentd i Kibana z wyszukiwaniem pełnotekstowym, bogatszą analizą i większym ciężarem utrzymania. Diagnostyka awarii obejmie zapytania LogQL, wykrywanie wzorców i anomalii, korelację metryk z logami i analizę przyczyn. Przygotowanie to uruchomienie Loki i Promtaila na maszynie wirtualnej, zbieranie z katalogu /var/log i logi aplikacji przez logowanie w Pythonie do Loki - ręczne przygotowanie oznacza, że będziecie gotowi na wykład 4.

Tak jak w tej części wykładu poznaliśmy metryki, tak czwarty wykład w całości poświęcimy logom - drugiemu filarowi obserwowalności, który powinien wspierać opisaną już diagnostykę wizualną. Jeśli metryki mówią, co się stało, to logi mówią, dlaczego. Na wstępie postawimy obok siebie dwa podejścia: lekki, oparty na etykietach Loki oraz pełnotekstowy, ale cięższy w utrzymaniu ELK.

Loki, wywodzący się z Grafana Labs, jest tani, indeksuje etykiety i natywnie łączy się z Grafaną, natomiast ELK składa się z Elasticsearcha, Logstasha lub Fluentda oraz Kibany, dając bogatszą analizę pełnotekstową kosztem większego ciężaru utrzymania. Poznamy LogQL, korelację metryk z logami, wykrywanie wzorców i analizę przyczyn, dlatego proszę przygotować Loki i Promtail oraz zbieranie logów z katalogu /var/log przed kolejnymi zajęciami.

Wyjaśnienie skrótów użytych na slajdzie:
Loki – Grafana Loki – system gromadzenia logów Loki; Horyzontalnie skalowalny system logów indeksujący wyłącznie metadane, omawiany na wykładzie 4.
ELK – Elasticsearch, Logstash, Kibana – stos technologiczny ELK; Platforma pełnotekstowego indeksowania i analizy logów w systemach IT.
Promtail – Promtail log shipping agent – agent przesyłania logów Promtail; Narzędzie zbierające logi z plików systemowych i przesyłające je do bazy Loki.
Vector – Vector log data pipeline – potok danych telemetrycznych Vector; Wysokowydajny kolektor i router logów oraz metryk napisany w języku Rust.
JSON – JavaScript Object Notation – strukturalny format zapisu danych; Format logów aplikacyjnych zapewniający optymalne parsowanie i wyszukiwanie w bazach logów.

Pytania kontrolne sprawdzają wiedzę przed egzaminem i przygotowują do rozwiązywania zadań: jak zbudować panel krok po kroku i czym jest zmienna w szablonowaniu. To samoocena - czy potrafisz to zrobić samodzielnie - oraz zaproszenie do dyskusji o dobrych praktykach, antywzorcach i narzędziach.

Budowa panelu to czytelny przepływ: dodaj panel, napisz zapytanie PromQL w edytorze, wybierz wizualizację - szereg czasowy, wskaźnik, statystyka, bar gauge, heatmapa, tabela, logi, ślady - zatwierdź i zapisz dashboard. Każdy panel odpowiada na jedno pytanie operacyjne i ma tytuł, jednostkę, progi i opis. Od zera do zapisanego panelu w dwie minuty.

Zmienna to dynamiczny filtr - instancja, job, środowisko, handler - stosowany w zapytaniach paneli. Przykładowa zmienna zapytania: $instance = label_values(node_cpu_seconds_total, instance) z trybem wielokrotnego wyboru, opcją All i filtrem regex. Szablonowanie dashboardu to jeden dashboard dla wszystkich. Zmienna to parametr, nie wartość wpisana na sztywno.

Dyskusja opiera się na otwartych pytaniach. Dobre praktyki - mniej paneli, kolory semantyczne. Antywzorce - wartości na sztywno, brak progów, brak zmiennych. Wyzwania z produkcji - wysoka kardynalność, wolne zapytania, zmęczenie alertami. Wybór narzędzi - Grafana, Kibana albo własne. Uczymy się od siebie nawzajem.

Zanim państwo przystąpią do pracy własnej i egzaminu, warto zrobić uczciwy przegląd tego, co naprawdę umiemy wykonać samodzielnie. Pytania kontrolne koncentrują się na dwóch umiejętnościach bazowych: płynnym budowaniu panelu oraz rozumieniu zmiennych w szablonowaniu dashboardu. Jeśli któregokolwiek z procesów nie zrobimy bez podglądania notatek, to wyraźny sygnał, że warto wrócić do odpowiednich slajdów.

Budowa panelu to ścieżka dodaj panel, zapytanie PromQL, wybór wizualizacji, Apply i zapis, przy czym każdy panel powinien odpowiadać na jedno pytanie operacyjne i mieć tytuł, jednostkę oraz progi. Zmienna z kolei to dynamiczny filtr, na przykład $instance pobierane z etykiet node_cpu_seconds_total, z opcją wielokrotnego wyboru, All i filtrem regex - dzięki niemu jeden dashboard obsługuje wszystkie środowiska. W dyskusji zwróćmy uwagę na antywzorce, takie jak wartości na sztywno i zmęczenie alertami.

Wyjaśnienie skrótów użytych na slajdzie:
PromQL – Prometheus Query Language – język zapytań Prometheus; Język formułowania zapytań analitycznych stanowiący przedmiot pytań kontrolnych.
UX – User Experience – doświadczenie użytkownika; Zasady projektowania czytelnych i ergonomicznych pulpitów weryfikowane w teście wiedzy.
SLO – Service Level Objective – cel poziomu usług; Kluczowa koncepcja łącząca dashboardy z inżynierią niezawodności systemów.
IaC – Infrastructure as Code – infrastruktura jako kod; Praktyka wdrażania pulpitów jako kodu źródłowego weryfikowana w pytaniach sprawdzających.
RBAC – Role-Based Access Control – kontrola dostępu oparta na rolach; Zasady bezpieczeństwa i autoryzacji użytkowników w platformie Grafana.

Podziękowania, przypomnienie o pracy własnej i kontakt zamykają wykład 3: co robić dalej, gdzie szukać pomocy - Slack, e-mail, dyżury i wsparcie kolegów. To nie koniec nauki - to początek praktyki.

Praca własna to zadanie zbudowania dashboardu. Składa się na niego zbiór metryk systemowych - CPU, RAM, dysk, sieć - oraz metryk aplikacyjnych, czyli latencji p95/p99 i wskaźnika błędów, a uzupełnia go panel SLO ze wskaźnikiem budżetu błędów. Termin to wykład 4. Nauka przez działanie - to nie teoria, to praktyka.

Kontakt i wsparcie są dostępne na kilku kanałach. Prowadzący odpowiada na Slacku w kanale #sre-course, e-mailem pod adresem prowadzacy@uczelnia.pl oraz w godzinach dyżurów - poniedziałek 14-16, sala 205. Kanał wsparcia koleżeńskiego #sre-course-peers pozwala studentom pomagać studentom - to najlepsza forma uczenia. Wsparcie środowiska oznacza, że nie jesteś sam.

Podziękowanie za uwagę i aktywność podczas wykładu 3. Następny raz: wykład 4 - Logi, Loki, ELK, LogQL, diagnostyka awarii. Dziękuję za uwagę.

Wykład zamykamy tam, gdzie ta nauka przechodzi w codzienną praktykę. Najważniejsze jest jedno: osobiście zbudowany dashboard z metrykami CPU, RAM, sieci i dysku oraz panelem SLO, bo właśnie ta praca własna utrwala całą wiedzę z dzisiejszych slajdów. Jest to zadanie warsztatowe, a nie tylko teoria do przeczytania, dlatego jego wykonanie decyduje o tym, ile faktycznie zostało z wykładu.

Gdy państwo utkną w którymś miejscu, pomoc czeka na kilku kanałach: Slack #sre-course, adres e-mail prowadzacy@uczelnia.pl oraz dyżury w poniedziałki od czternastej do szesnastej. Wartościowy jest też kanał koleżeński, na którym studenci pomagają studentom. Przygotowany pulpit będzie punktem startowym do wykładu o logach, Loki i ELK, dlatego zachęcam do doprowadzenia zadań do końca jeszcze przed kolejnymi zajęciami.

Wyjaśnienie skrótów użytych na slajdzie:
SRE – Site Reliability Engineering – inżynieria niezawodności systemów; Koncepcja nadrzędna łącząca obserwowalność, wizualizację i stabilność usług produkcyjnych.
Grafana – Grafana visualization platform – platforma analityczno-wizualizacyjna Grafana; Podstawowe narzędzie inżyniera SRE w zakresie prezentacji i korelacji metryk.
PromQL – Prometheus Query Language – język zapytań Prometheus; Język analityczny leżący u podstaw dynamicznych paneli telemetrycznych.
GitOps – GitOps operational framework – model operacyjny GitOps; Praktyka zarządzania konfiguracją pulpitów i monitoringu za pośrednictwem repozytorium Git.
CI/CD – Continuous Integration / Continuous Delivery – ciągła integracja i ciągłe wdrażanie; Automatyzacja wydań oprogramowania sprzężona z adnotacjami na pulpitach telemetrycznych.