Spis treści

Wyobraź sobie typowy poranek inżyniera dyżurnego. Na czacie pojawia się wiadomość: "Wszystko u nas zamula". Co dokładnie zamula? Cała pula czy tylko jeden wycinek? Proxy w konkretnym kraju czy u konkretnego operatora? Wolno odpowiada docelowa strona czy rośnie kolejka ponowień? Bez liczb to nie incydent, a wróżenie z fusów. A gdy zespół zgaduje, czas ucieka, a pieniądze wyciekają.

Ten artykuł jest o tym, jak zamienić mgliste uczucie "zamula" w precyzyjną diagnozę w ciągu jednej minuty. Omówimy, jakie metryki zbierać wokół puli proxy, co zapisywać w logach przy każdym żądaniu, a czego kategorycznie nie wolno zapisywać, dlaczego percentyle są ważniejsze od średniej, jak oznaczać dane według wymiarów i jak skonfigurować alerty, które nie budzą cię bez powodu. Na końcu znajdziesz tabelę szybkiego reagowania i praktyczny FAQ.

Ważne zastrzeżenie co do granic tematu. Mówimy tu wyłącznie o pomiarze i powiadamianiu. Wybór konkretnego IP pod żądanie, health-check węzłów i logika kwarantanny wewnątrz puli to osobny, duży temat, któremu poświęcono oddzielny materiał. Tutaj nasze zadanie jest węższe: dostrzec degradację, zlokalizować ją i podnieść alarm na czas. W przykładach wykorzystano infrastrukturę Proxeon, ale zasady są uniwersalne.

Podstawy: czym jest obserwowalność i dlaczego proxy wymagają jej szczególnie pilnie

Zacznijmy od fundamentu. Obserwowalność (observability) to właściwość systemu, dzięki której na podstawie jego zewnętrznych danych wyjściowych można zrozumieć stan wewnętrzny bez konieczności wchodzenia do środka z debuggerem. Klasyczna triada obserwowalności: metryki, logi i tracy. Metryki odpowiadają na pytanie "co się dzieje" w agregacie, logi na pytanie "co dokładnie stało się z konkretnym żądaniem", a tracy na pytanie "jak żądanie przeszło przez cały łańcuch".

Czym proxy różnią się od zwykłego serwisu webowego? Tym, że masz trzecią stronę, której nie kontrolujesz w pełni: sam węzeł proxy, kanał do niego i zasób docelowy za nim. Zwykłą aplikację można profilować do ostatniej funkcji. A proxy dodaje warstwę niepewności sieciowej, w której degradacja może przyjść skądkolwiek: od operatora telekomunikacyjnego, od routingu, od przeciążenia konkretnego węzła, od zmienionego zachowania docelowej strony.

Właśnie dlatego obserwowalność wokół puli proxy to nie luksus, a higiena. Bez niej pracujesz po ciemku. Z nią widzisz strukturę problemu: nie "wszystko jest źle", ale "zdegradował się wycinek mobilnych proxy jednego operatora w jednym regionie, reszta w normie". To różnica między paniką a chirurgiczną precyzją.

Trzy poziomy, na których żyją problemy

Warto od samego początku mieć w głowie trzy poziomy, na których rodzi się degradacja:

  • Poziom transportu: kanał do proxy, utrata pakietów, czas nawiązania połączenia. Tutaj żyją timeouty i wolny TTFB.
  • Poziom węzła proxy: przeciążenie konkretnego IP, wyczerpanie limitów, problemy u operatora. Tutaj żyje wzrost odsetka błędów na konkretnym wycinku.
  • Poziom zasobu docelowego: strona zaczęła odpowiadać wolniej, zwróciła niestandardowe kody, zmieniła limity. Tutaj ważne jest, by nie pomylić problemu strony z problemem puli.

Dobry system obserwowalności pozwala na pierwszy rzut oka zrozumieć, na którym z trzech poziomów jest problem. To jest właśnie ta "minuta do diagnozy", dla której to wszystko robimy.

Cztery sygnały dla proxy: dlaczego właśnie one

Istnieje pokusa, by zbierać wszystko po kolei. Setki metryk, dziesiątki dashboardów, kilometry wykresów. To pułapka. Wiele metryk oznacza szum, a szum oznacza, że w momencie incydentu nie znajdziesz tego, czego potrzebujesz. Doświadczona praktyka inżynierska mówi coś przeciwnego: zacznij od minimalnego zestawu sygnałów, które pokrywają większość problemów. Dla puli proxy takich sygnałów jest cztery.

Sygnał pierwszy: wskaźnik sukcesu

Wskaźnik sukcesu (success rate) to odsetek żądań zakończonych zgodnie z oczekiwaniem w stosunku do ogólnej liczby. To główny wskaźnik zdrowia. Jeśli success rate spada, coś zepsuło się tu i teraz, i to u użytkownika.

Kluczowe pytanie: co uznać za sukces? Naiwna odpowiedź "kod 200" jest błędna. Lepiej definiować sukces przez kontrakt twojego użycia. Często za sukces uznaje się wszystkie kody 2xx i 3xx, a także sensowne 4xx, które są prawidłową odpowiedzią zasobu docelowego, a nie problemem proxy. Natomiast timeouty, zerwania połączenia, błędy na poziomie proxy i masowe 5xx to porażka.

Formalnie success rate należy do rodziny metryk "dostępność" w modelu SLI (Service Level Indicator). To ten sam wskaźnik, wokół którego buduje się później SLO (cele poziomu usługi) i budżet błędów.

Sygnał drugi: opóźnienie według percentyli

Opóźnienie (latency) to czas od wysłania żądania do otrzymania odpowiedzi. Ale jedna liczba latency jest bezsensowna. Potrzebne są percentyle: p50, p95, p99. Dlaczego właśnie percentyle, a nie średnia, omówimy szczegółowo w osobnym rozdziale, bo to jeden z najbardziej niedocenianych tematów w całym monitoringu.

Dla proxy szczególnie cenny jest TTFB (Time To First Byte, czas do pierwszego bajtu). Oddziela opóźnienie sieciowe i czas reakcji serwera od czasu transmisji treści odpowiedzi. Jeśli rośnie TTFB, to problem sieci lub węzła. Jeśli rośnie całkowity czas, ale TTFB jest stabilny, być może po prostu wzrosły odpowiedzi albo spadła przepustowość kanału.

Sygnał trzeci: odsetek ponowień

Odsetek ponowień (retry rate) to procent żądań, które wymagały ponownej próby. To wczesny zwiastun kłopotów. Często success rate jest jeszcze w normie, bo ponowienia ratują sytuację, ale odsetek ponowień już pełznie w górę. To jak temperatura 37 i 2: formalnie jeszcze pracujesz, ale organizm już walczy.

Ponowienia maskują degradację dla końcowego użytkownika, ale pożerają zasoby: czas, ruch, pojemność puli. Ignorowanie tego sygnału jest podwójnie niebezpieczne, bo wzrost ponowień może lawinowo zawalić system, gdy powtórne żądania dodadzą obciążenia do i tak przeciążonych węzłów.

Sygnał czwarty: zużycie ruchu

Zużycie ruchu (bandwidth) to objętość przesłanych danych. Po co on w czwórce najważniejszych? Po pierwsze, to bezpośrednie pieniądze, bo ruch jest taryfikowany. Po drugie, anomalne zużycie to sygnał: nagły wzrost może oznaczać, że ktoś ciągnie za dużo, odpowiedzi spuchły albo ponowienia gonią te same dane w kółko. Nagły spadek do zera na wycinku, gdzie zwykle jest aktywność, oznacza, że wycinek po prostu przestał działać.

Te cztery sygnały nie są przypadkowe. Nawiązują do metodologii "złotych sygnałów" obserwowalności, spopularyzowanej przez inżynierów niezawodności: opóźnienie, ruch, błędy, nasycenie. Zaadaptowaliśmy ją do specyfiki proxy, gdzie ponowienia zasługują na osobne miejsce jako unikalny dla tej dziedziny zwiastun.

Głębokie zanurzenie: co zapisywać w logu przy każdym żądaniu

Metryki pokazują trendy. Ale gdy trzeba zrozumieć, co stało się z konkretnym żądaniem, ratują logi. Odpowiednio zaprojektowany log żądania to twoja czarna skrzynka, do której sięgasz przy analizie incydentu. Przeanalizujmy, co zapisywać obowiązkowo, a czego nie wolno zapisywać nigdy.

Co zapisywać obowiązkowo

  • Identyfikator proxy: nie sam IP w jawnej formie, ale stabilny identyfikator węzła lub puli. Pozwala powiązać żądanie z konkretnym zasobem i zobaczyć, które węzły sprawiają problemy.
  • Kod odpowiedzi: status HTTP lub kod błędu transportu (timeout, odmowa połączenia, zerwanie). To podstawa do obliczenia success rate.
  • Czas do pierwszego bajtu (TTFB): w milisekundach. Jeden z najbardziej informacyjnych wskaźników do lokalizacji problemów sieciowych.
  • Całkowity czas żądania: od startu do zakończenia, też w milisekundach.
  • Rozmiar odpowiedzi: w bajtach. Zasila metrykę ruchu i pomaga zauważyć anomalnie duże lub puste odpowiedzi.
  • Numer próby: pierwsza to próba czy już ponowienie, i które z kolei. Bez tego pola nie da się policzyć odsetka ponowień.
  • Wymiary do oznaczania: kraj, operator, typ proxy. O nich osobny rozdział, ale w logu muszą być.
  • Znacznik czasu i identyfikator tracy: by powiązać wpisy między sobą i z systemami zewnętrznymi.

Oto jak może wyglądać ustrukturyzowany wpis logu w formacie JSON. Zwróć uwagę: jest maszynowo czytelny, co jest krytyczne dla późniejszej analizy.

{"ts":"2026-02-14T08:12:33Z","trace_id":"a1b2c3","proxy_id":"pool7-node042","country":"RU","carrier":"op-a","proxy_type":"mobile","status":200,"ttfb_ms":187,"total_ms":342,"bytes":20481,"attempt":1,"outcome":"success"}

Czego NIE WOLNO zapisywać nigdy

To nie mniej ważne niż to, co zapisywać trzeba. Logi mają zwyczaj wyciekać, być kopiowane do systemów analitycznych, trafiać do kopii zapasowych. Wszystko, co tam włożysz, żyje długo i w nieoczekiwanych miejscach.

  • Dane uwierzytelniające (creds): loginy, hasła, tokeny autoryzacji do proxy, klucze API. Nigdy. Nawet częściowo. Nawet "na czas debugowania".
  • Treść odpowiedzi w całości: po pierwsze, to gigantyczna objętość, po drugie, mogą tam być dane osobowe i wrażliwe. Zapisuj tylko rozmiar i, w razie potrzeby, hash lub krótką sygnaturę.
  • Nagłówki z sekretami: Authorization, Cookie, Set-Cookie i podobne. Trzeba je wyczyścić przed zapisem.
  • Pełne URL-e z wrażliwymi parametrami: jeśli w query-stringu są tokeny lub identyfikatory osobowe, trzeba je zamaskować.
  • Dane osobowe użytkowników: wszystko, co podlega wymogom prawa o ochronie danych osobowych, powinno albo nie trafiać do logu, albo być zanonimizowane.

Praktyczny trik maskowania na etapie formowania logu:

def sanitize(entry):  secret_keys = {"authorization", "cookie", "set-cookie", "proxy-authorization"}  headers = {k: ("***" if k.lower() in secret_keys else v) for k, v in entry.get("headers", {}).items()}  entry["headers"] = headers  entry.pop("body", None)  entry.pop("proxy_credentials", None)  return entry

Złota zasada: log powinien pozwalać zdiagnozować problem, ale nie powinien zamieniać się w bazę wyciekłych sekretów. Jeśli masz wątpliwości, czy zapisać pole, nie zapisuj go. Wartość diagnostyczną prawie zawsze można uzyskać przez bezpieczne surogaty: hashe, rozmiary, flagi, kategorie.

Percentyle zamiast średniej: dlaczego średnia ukrywa problem

To rozdział, który warto przeczytać dwa razy. Bo kryje się tu najczęstszy i najbardziej podstępny błąd w monitoringu wydajności.

Dlaczego średnia kłamie

Wyobraź sobie: masz sto żądań. Dziewięćdziesiąt dziewięć z nich wykonało się w 100 milisekund, a jedno w 10 sekund. Średni czas wyniesie około 199 milisekund. Wygląda świetnie, prawie nic się nie zmieniło. A tymczasem jeden twój użytkownik czekał dziesięć sekund i najprawdopodobniej już sobie poszedł, klnąc pod nosem.

Średnia to aparat, który rozmywa wartości odstające po całej próbce. Jest wrażliwa na ekstrema, ale niewrażliwa na strukturę rozkładu. A wydajność systemów sieciowych prawie zawsze ma rozkład z długim ogonem: większość żądań jest szybka, ale jest mniejszość bardzo wolnych. I właśnie ten ogon determinuje realne doświadczenie użytkownika i obecność problemów.

Czym są percentyle i jak je czytać

Percentyl to wartość, poniżej której leży zadany procent obserwacji. Omówmy trzy główne:

  • p50 (mediana): połowa żądań jest szybsza od tej wartości, połowa wolniejsza. To "typowe" doświadczenie.
  • p95: 95 procent żądań zmieściło się w tym czasie. To doświadczenie "prawie najgorszego przypadku", które dotyka zauważalną część użytkowników.
  • p99: 99 procent żądań jest szybsze. To ten długi ogon, w którym żyją timeouty, ponowienia i wściekli użytkownicy.

W naszym przykładzie ze stu żądaniami p50 i p95 pozostaną około 100 milisekund, ale p99 podskoczy do 10 sekund. Percentyl uczciwie pokazał problem, który średnia ukryła. Dlatego doświadczeni inżynierowie patrzą przede wszystkim na p95 i p99, a średniej prawie nie używają do oceny latencji.

Jak liczyć percentyle poprawnie

Naiwny sposób: zebrać wszystkie wartości, posortować i wziąć potrzebną pozycję. Jest dokładny, ale nie skaluje się: przy milionach żądań przechowywanie całej tablicy jest niemożliwe. W praktyce używa się struktur przybliżonego zliczania: histogramów ze stałymi kubełkami lub specjalnych algorytmów, takich jak t-digest i histogramy HDR.

Idea histogramu jest prosta: z góry definiujesz przedziały (kubełki) czasu i po prostu liczysz, ile żądań trafiło do każdego. Z nagromadzonych liczników łatwo odtworzyć dowolny percentyl z akceptowalną dokładnością, a pamięć zajmuje stałą ilość.

import bisectclass PercentileTracker:  def __init__(self):    self.buckets = [10, 25, 50, 100, 200, 500, 1000, 2000, 5000]    self.counts = [0] * (len(self.buckets) + 1)  def add(self, ms):    i = bisect.bisect_left(self.buckets, ms)    self.counts[i] += 1  def percentile(self, p):    total = sum(self.counts)    if total == 0:      return None    target = total * p / 100    acc = 0    for i, c in enumerate(self.counts):      acc += c      if acc >= target:        return self.buckets[min(i, len(self.buckets) - 1)]    return self.buckets[-1]

Jedno ważne ostrzeżenie o agregacji. Percentyli nie wolno uśredniać. Jeśli masz p95 na dziesięciu węzłach, nie możesz wziąć średniej tych p95 i nazwać wyniku ogólnym p95. To matematycznie niepoprawne. Do poprawnej agregacji trzeba sumować histogramy, a z sumarycznego histogramu obliczyć percentyl. Właśnie dlatego nowoczesne systemy monitoringu przechowują histogramy, a nie gotowe percentyle.

Oznaczanie według wymiarów: widzieć wycinek, a nie całą pulę

To moment, w którym obserwowalność zmienia się z wykresu w narzędzie diagnostyczne. Jedna liczba success rate dla całej puli mówi niewiele. Może wynosić 97 procent i wyglądać normalnie, ukrywając, że jeden wycinek spadł do 40 procent, a reszta wyciąga średnią.

Trzy kluczowe wymiary dla proxy

  • Kraj (country): geografia proxy. Degradacja jest często zlokalizowana geograficznie: problem routingu w jednym regionie, zmiany po stronie zasobu docelowego dla określonych krajów.
  • Operator (carrier): dla mobilnych proxy Proxeon to krytycznie ważny wymiar. Problem u konkretnego operatora telekomunikacyjnego objawi się właśnie tutaj, i od razu zrozumiesz jego skalę.
  • Typ proxy (proxy_type): mobilne, serwerowe, rezydencjalne. Różne typy zachowują się inaczej, a degradacja jednego typu nie powinna ginąć w ogólnej masie.

Kardynalność: gdzie się zatrzymać

Istnieje pokusa, by oznaczać dane wszystkim po kolei: każdym IP, każdą domeną docelową, każdym użytkownikiem. To prowadzi do eksplozji kardynalności liczby unikalnych kombinacji etykiet. Wysoka kardynalność zabija systemy monitoringu: rośnie objętość przechowywania, zwalniają zapytania, drożeje infrastruktura.

Praktyczna zasada: oznaczaj według wymiarów o ograniczonym i stabilnym zestawie wartości. Krajów są dziesiątki, operatorów kilka lub kilkanaście, typów proxy kilka. To bezpieczne. Natomiast osobne IP lub pełny URL jako etykieta w metrykach są niedopuszczalne, bo są unikalne w ogromnych ilościach. Takie szczegóły to miejsce w logach, gdzie są przechowywane wiersz po wierszu, a nie w metrykach, gdzie mnożą szeregi danych.

from prometheus_client import Counter, Histogramrequests_total = Counter(  "proxy_requests_total",  "Total proxy requests",  ["country", "carrier", "proxy_type", "outcome"])latency_ms = Histogram(  "proxy_latency_ms",  "Request latency",  ["country", "carrier", "proxy_type"],  buckets=[10, 25, 50, 100, 200, 500, 1000, 2000, 5000])def record(country, carrier, ptype, outcome, ms):  requests_total.labels(country, carrier, ptype, outcome).inc()  latency_ms.labels(country, carrier, ptype).observe(ms)

Z takim oznaczaniem możesz w sekundach zbudować zapytanie: pokaż success rate według operatorów za ostatnią godzinę. I od razu zobaczyć, że zdegradowała się nie cała pula, a jeden wycinek. To właśnie lokalizacja. Piękno tego podejścia polega na tym, że zamienia panikę "wszystko się zepsuło" w spokojne "wycinek X operatora Y wymaga uwagi".

Alerty, które nie szumią

Najczęstsza przyczyna, dla której zespoły przestają ufać monitoringowi, to hałaśliwe alerty. Gdy system budzi cię pięć razy w nocy bez powodu, wkrótce zaczniesz go ignorować. A potem przegapisz prawdziwy incydent. To się nazywa zmęczenie alertami, i zabija obserwowalność skuteczniej niż całkowity brak monitoringu.

Trzy zasady cichych alertów

Zasada pierwsza: progi na objawy, nie na przyczyny. Alertować należy na to, co czuje użytkownik: spadek success rate, wzrost p99 opóźnienia. Nie na pośrednie wahania techniczne, które same w sobie nie oznaczają problemu.

Zasada druga: okna obserwacji. Nie reaguj na pojedynczy skok. Jedno wolne żądanie to szum. Utrzymujące się odchylenie przez okno czasu to sygnał. Skonfiguruj alert tak, by uruchamiał się, gdy warunek utrzymuje się, na przykład, pięć minut z rzędu, a nie w jednej chwili.

Zasada trzecia: histereza. To termin zapożyczony z inżynierii, oznaczający różne progi dla uruchomienia i wyłączenia. Alert zapala się, gdy success rate spada poniżej 90 procent, ale gaśnie dopiero, gdy wzrośnie powyżej 95. Przerwa między progami zapobiega "drganiu", gdy metryka oscyluje wokół jednej wartości i alert miga, włączając się i wyłączając.

Przykład konfiguracji alertu

Oto przykład reguły w stylu zrozumiałym dla większości systemów monitoringu. Uruchamia się, jeśli wskaźnik sukcesu na dowolnym wycinku operatora utrzymuje się poniżej progu przez okno obserwacji.

groups:- name: proxy-health  rules:  - alert: LowSuccessRateByCarrier    expr: |      sum by (carrier) (rate(proxy_requests_total{outcome="success"}[5m]))      /      sum by (carrier) (rate(proxy_requests_total[5m]))      < 0.90    for: 5m    labels:      severity: warning    annotations:      summary: "Success rate below 90 percent for carrier"

Poziomy istotności i routing

Nie wszystkie alerty są równe. Podziel je według istotności:

  • Warning: coś się odchyliło, warto spojrzeć w godzinach pracy. Nie budzi w nocy.
  • Critical: użytkownicy cierpią tu i teraz, potrzebna natychmiastowa reakcja. Budzi dyżurnego.

Rozsądny zestaw na start obejmuje dosłownie kilka alertów: krytyczny spadek ogólnego success rate, degradacja success rate na wycinku, gwałtowny wzrost p99 opóźnienia, anomalny skok odsetka ponowień. Nie więcej. Każdy nowy alert to obietnica, że ktoś na niego zareaguje. Nie składaj obietnic, których nie możesz dotrzymać.

Budżet błędów jako rama

Zaawansowany trik: zamiast sztywnych progów na wartości chwilowe używać budżetu błędów. Jeśli twoim celem jest 99 procent udanych żądań miesięcznie, budżet błędów to ten jeden procent, który możesz "wydać". Alert na tempo wydatkowania budżetu (burn rate) reaguje nie na fakt pojedynczego błędu, ale na to, że wydajesz dopuszczalny limit błędów zbyt szybko. Takie alerty są znacznie spokojniejsze i trafniej odzwierciedlają realne zagrożenie dla SLO.

Szybka diagnostyka po dashboardzie: trzy typowe obrazy

Teraz najciekawsze. Jak w minutę zrozumieć, gdzie jest degradacja? Odpowiedź tkwi w wytrenowaniu oka na kilka typowych wzorców. Dobry dashboard to nie wysypisko wykresów, a narzędzie rozpoznawania obrazów. Omówmy trzy klasyczne obrazy.

Obraz pierwszy: spadł jeden wycinek, reszta w normie

Patrzysz na success rate rozbity według operatorów. Ogólny wskaźnik nieco spadł, ale patrząc na rozbicie, widać: jeden operator runął do 50 procent, reszta trzyma 98. Opóźnienie na problematycznym wycinku wzrosło, na pozostałych stabilne.

Co to znaczy: zlokalizowany problem na poziomie węzła lub operatora. Przyczyna nie leży w twoim systemie ani w zasobie docelowym jako całości, a w konkretnym wycinku puli. Problem transportu lub samego węzła.

Pierwsze działanie: wyłączyć problematyczny wycinek z aktywnej rotacji (to już obszar kwarantanny, osobny temat) i kontynuować obserwację. Sprawdzić, czy degradacja nie jest związana z konkretnym regionem wewnątrz operatora.

Obraz drugi: wzrosło opóźnienie wszędzie, ale błędów nie ma

Success rate stabilny, bliski stu procentom. A p95 i p99 opóźnienia wzrosły na wszystkich wycinkach jednocześnie i równomiernie. Odsetek ponowień podrósł nieznacznie.

Co to znaczy: gdy degraduje się wszystko naraz i równomiernie, szukaj wspólnego czynnika. Najczęściej to albo twoja własna infrastruktura (przeciążenie, brak zasobów, wąskie gardło w twoim kodzie), albo zasób docelowy zaczął odpowiadać wolniej dla wszystkich. Węzły proxy nie mają tu nic do rzeczy, inaczej degradacja byłaby nierównomierna.

Pierwsze działanie: spojrzeć osobno na TTFB. Jeśli wzrosło TTFB, to sieć lub serwer. Jeśli TTFB stabilne, a całkowity czas rośnie, problem w transmisji lub przetwarzaniu treści. Sprawdzić obciążenie po swojej stronie i metryki zasobu docelowego.

Obraz trzeci: rośnie odsetek ponowień przy stabilnym success rate

Success rate wygląda normalnie, około 97 procent. Ale odsetek ponowień pełznie w górę: było 3 procent, jest 15. Opóźnienie też podrosło, bo ponowienia dodają czasu.

Co to znaczy: to najbardziej podstępny wzorzec, bo wynik końcowy jest jeszcze w normie. Ale system pracuje na granicy: wydaje coraz więcej powtórnych prób, by utrzymać success rate. To zwiastun zawału. Jeśli tendencja się utrzyma, ponowienia przestaną ratować i success rate runie.

Pierwsze działanie: nie czekać, aż runie success rate. Znaleźć, na którym wycinku rosną ponowienia (znowu rozbicie według wymiarów), i zrozumieć pierwotną przyczynę, zanim będzie za późno. Sprawdzić, czy same ponowienia nie tworzą dodatkowego obciążenia, które nakręca spiralę.

Kompozycja dashboardu do minutowej diagnostyki

Aby te wzorce czytały się w minutę, umieść na głównym ekranie tylko cztery panele, odpowiadające czterem sygnałom, i każdy z możliwością szybkiego rozbicia według wymiarów:

  1. Success rate: ogólny i z rozbiciem według operatorów i krajów.
  2. Opóźnienie: p50, p95, p99 na jednym wykresie, by widzieć rozjazd ogona.
  3. Odsetek ponowień: trend z ostatnich godzin.
  4. Zużycie ruchu: według wycinków, by łapać anomalie.

Wszystko inne jest drugorzędne i żyje na osobnych ekranach. Główny ekran powinien odpowiadać na jedno pytanie: czy wszystko jest w porządku, a jeśli nie, to gdzie dokładnie. Nic zbędnego.

Tabela szybkiego reagowania: metryka, jej wzrost i pierwsze działanie

Tę tabelę warto wydrukować i powiesić obok miejsca pracy dyżurnego. Zamienia obserwację w działanie bez zbędnego zastanowienia.

Metryka: spadek wskaźnika sukcesu (w całej puli)

Co oznacza: masowa awaria dotykająca większości żądań. Problem na poziomie systemowym.
Pierwsze działanie: sprawdzić własną infrastrukturę i zasób docelowy, bo równomierny spadek rzadko idzie od pojedynczych węzłów.

Metryka: spadek wskaźnika sukcesu (na jednym wycinku)

Co oznacza: zlokalizowana degradacja operatora, kraju lub typu proxy.
Pierwsze działanie: zlokalizować wycinek po rozbiciu i wyłączyć go z rotacji, obserwując dynamikę.

Metryka: wzrost p99 opóźnienia przy stabilnym p50

Co oznacza: wydłużył się ogon, część żądań stała się bardzo wolna, przy czym typowe żądanie jest w normie.
Pierwsze działanie: znaleźć wycinek z rosnącym ogonem, sprawdzić timeouty i węzły dające skoki.

Metryka: wzrost p50 i p95 jednocześnie i równomiernie

Co oznacza: ogólna degradacja wydajności, prawdopodobnie infrastruktura lub zasób docelowy.
Pierwsze działanie: rozdzielić TTFB i czas transmisji treści, sprawdzić obciążenie po swojej stronie.

Metryka: wzrost odsetka ponowień przy stabilnym success rate

Co oznacza: system maskuje degradację powtórzeniami, zwiastun zawału.
Pierwsze działanie: znaleźć wycinek ze wzrostem ponowień i usunąć pierwotną przyczynę przed załamaniem success rate.

Metryka: anomalny wzrost zużycia ruchu

Co oznacza: spuchnięte odpowiedzi, zbędne powtórzenia lub nieplanowana aktywność.
Pierwsze działanie: zestawić wzrost ruchu z liczbą żądań i rozmiarem odpowiedzi, znaleźć źródło.

Metryka: spadek zużycia ruchu do zera na aktywnym wycinku

Co oznacza: wycinek przestał całkowicie obsługiwać żądania.
Pierwsze działanie: sprawdzić dostępność węzłów wycinka i łączność, eskalować po potwierdzeniu.

Typowe błędy obserwowalności proxy

Doświadczenie z analizy dziesiątek incydentów pozwala zebrać kolekcję grabi, na które się najczęściej wchodzi. Znajomość tych błędów oszczędza miesiące bólu.

Błąd 1: patrzeć na średnią zamiast na percentyle

Już to omawialiśmy, ale powtórzmy, bo błąd jest tak rozpowszechniony. Średni czas odpowiedzi nie pokazuje problemów długiego ogona. Zespół widzi stabilną średnią i jest przekonany, że wszystko jest dobrze, dopóki użytkownicy nie poskarżą się na zawieszki. Zawsze p95 i p99.

Błąd 2: logować sekrety "na czas debugowania"

To, co tymczasowe, ma zwyczaj stawać się trwałe. Token zalogowany "na pięć minut do sprawdzenia" osiada w systemie przechowywania logów na miesiące i trafia do backupów. Maskowanie sekretów musi być twardą regułą na poziomie biblioteki logowania, a nie decyzją każdego dewelopera w danej chwili.

Błąd 3: eksplozja kardynalności etykiet

Oznaczenie metryk po każdym IP lub URL wydaje się wygodne, dopóki system monitoringu nie zacznie się dusić i wymagać coraz więcej zasobów. Etykiety tylko dla wymiarów o ograniczonym zestawie wartości. Szczegóły do logów.

Błąd 4: zbyt wiele alertów

Zespół, dumny ze swojego monitoringu, konfiguruje czterdzieści alertów. Po miesiącu połowa z nich szumi, dyżurni wyłączają je w powiadomieniach, i pewnego dnia przegapiają prawdziwy incydent, bo zaginął w strumieniu. Mniej alertów, ale trafniejszych.

Błąd 5: alerty bez okna i histerezy

Alert uruchamia się na wartość chwilową i zaraz gaśnie, potem znowu się uruchamia. Drganie powiadomień denerwuje i dewaluuje system. Okna obserwacji i histereza są obowiązkowe.

Błąd 6: uznawać za sukces tylko kod 200

Tak albo zaniżasz success rate, uznając za porażkę prawidłowe odpowiedzi, albo, odwrotnie, przeoczasz problemy. Definiuj sukces przez kontrakt użycia sensownie, a nie mechanicznie po jednym kodzie.

Błąd 7: brak rozbicia według wymiarów

Jeden ogólny wykres success rate ukrywa lokalne problemy. Bez rozbicia widzisz, że "ogólnie jest normalnie", i przepuszczasz spadnięty wycinek. Oznaczanie to nie opcja, a konieczność.

Błąd 8: ignorować ponowienia

Wielu w ogóle nie liczy odsetka ponowień, opierając się tylko na końcowym success rate. I tracą najwcześniejszy zwiastun. Do momentu, gdy success rate spada, ponowienia już dawno krzyczały o problemie.

Błąd 9: przechowywać percentyle zamiast histogramów

Jeśli zapisujesz gotowe p95 według wycinków, nie będziesz mógł poprawnie obliczyć ogólnego p95, bo percentyle się nie sumują. Przechowuj histogramy, obliczaj percentyle przy zapytaniu.

Błąd 10: dashboard jako wysypisko

Pięćdziesiąt paneli na jednym ekranie to nie obserwowalność, a szum informacyjny. W momencie incydentu oko się gubi. Główny ekran minimalistyczny, szczegóły po kliknięciu.

Narzędzia i zasoby

Dobra wiadomość: do jakościowej obserwowalności wokół puli proxy nie potrzebujesz drogiego i skomplikowanego stacku. Omówmy minimalnie wystarczający zestaw i logikę wyboru.

Zbieranie i przechowywanie metryk

Do metryk świetnie nadają się systemy oparte na modelu szeregów czasowych z obsługą etykiet i histogramów. Kluczowe wymaganie to obsługa histogramów do poprawnego obliczania percentyli i oznaczania według wymiarów bez eksplozji kardynalności. Takie systemy pozwalają robić zapytania typu "success rate według operatorów za godzinę" na bieżąco.

Wizualizacja

Do dashboardów potrzebne jest narzędzie umiejące rysować wykresy szeregów czasowych, nakładać kilka percentyli na jeden wykres i szybko przełączać rozbicie według wymiarów. Ważna jest możliwość robienia zmiennych filtrów: wybrałeś operatora i wszystkie panele przebudowały się pod niego. To przyspiesza diagnostykę wielokrotnie.

Zbieranie i przechowywanie logów

Logi żądań powinny być ustrukturyzowane (JSON) i trafiać do systemu pozwalającego filtrować po polach: po identyfikatorze proxy, po kodzie odpowiedzi, po wycinku. Obowiązkowe wymaganie to polityka przechowywania z automatycznym usuwaniem po upływie terminu, by wrażliwe dane nie gromadziły się wiecznie.

Alerting

System alertów powinien obsługiwać okna obserwacji (warunek utrzymuje się N minut), poziomy istotności i routing po kanałach. Osobno cenna jest obsługa alertów na tempo wydatkowania budżetu błędów dla spokojnych, ale trafnych uruchomień.

Biblioteki do instrumentowania kodu

W kodzie klienta proxy używaj bibliotek metryk obsługujących liczniki i histogramy z etykietami. Owiń każde żądanie w pomiar: zapisz czas startu, po zakończeniu zapisz wynik, opóźnienie i ruch. Instrumentowanie powinno być scentralizowane, w jednym miejscu, by nowy deweloper nie mógł przypadkiem go pominąć.

import timedef instrumented_request(client, url, meta):  start = time.monotonic()  attempt = meta["attempt"]  try:    resp = client.get(url)    elapsed = (time.monotonic() - start) * 1000    outcome = "success" if resp.status_code < 500 else "server_error"    record(meta["country"], meta["carrier"], meta["type"], outcome, elapsed)    log_request(meta, resp.status_code, elapsed, len(resp.content), attempt, outcome)    return resp  except TimeoutError:    elapsed = (time.monotonic() - start) * 1000    record(meta["country"], meta["carrier"], meta["type"], "timeout", elapsed)    log_request(meta, None, elapsed, 0, attempt, "timeout")    raise

Trendy 2026 roku

Branża obserwowalności w 2026 roku zmierza w kilku zauważalnych kierunkach. Po pierwsze, standaryzacja telemetrii oparta na otwartych protokołach, co ułatwia integrację metryk, logów i traców w jeden obraz. Po drugie, rosnące zainteresowanie histogramami wykładniczymi, które dają dokładne percentyle przy minimalnym zużyciu pamięci. Po trzecie, zastosowanie automatycznego wykrywania anomalii opartego na modelach statystycznych, które uzupełnia alerty progowe, zauważając nietypowe wzorce, dla których nie da się z góry ustalić progu. I po czwarte, przesunięcie fokusu z ilości zbieranych danych na ich sensowność: mniej metryk, ale trafnych. To dokładnie to, o czym mówimy w tym artykule.

Case studies i wyniki

Aby zasady nabrały ciała, omówmy kilka uogólnionych scenariuszy, zbudowanych na typowej praktyce eksploatacji pul proxy. Liczby są ilustracyjne, ale wzorce realne.

Case 1: niewidzialna degradacja jednego operatora

Zespół pracował z pulą mobilnych proxy Proxeon i opierał się na ogólnym success rate. Wskaźnik trzymał się około 96 procent, alarmu nie było. Przy tym użytkownicy jednego z kierunków skarżyli się na awarie. Po wdrożeniu rozbicia według operatorów obraz wyjaśnił się natychmiast: jeden operator dawał success rate 62 procent, reszta około 99. Ogólna liczba maskowała załamanie całego wycinka.

Wynik: po dodaniu oznaczania według operatorów i alertu na degradację po wycinku czas wykrywania podobnych problemów skrócił się z kilku godzin (po skargach) do kilku minut (po alercie). Problematyczny wycinek zaczął być na czas wyłączany z rotacji, a ogólny success rate na kierunku wzrósł do 98 procent.

Case 2: długi ogon ukryty za średnią

Inny zespół monitorował średnie opóźnienie, które trzymało się na komfortowych 240 milisekundach. Okresowe skargi na "zawieszki" spisywano na kaprysy. Przejście na percentyle otworzyło oczy: p50 rzeczywiście był około 190 milisekund, ale p99 sięgał 8 sekund. Co setne żądanie było boleśnie wolne.

Wynik: po tym, jak zespół zaczął śledzić p99 i skonfigurował alert na jego wzrost, odkryto, że ogon generują żądania do określonej grupy węzłów w godzinach szczytu. Problem zlokalizowano po rozbiciu. p99 udało się obniżyć do 1,2 sekundy, a liczba skarg na zawieszki spadła praktycznie do zera.

Case 3: spirala ponowień

Trzeci scenariusz jest pouczający ze względu na swoje niebezpieczeństwo. System z agresywną polityką powtórzeń utrzymywał success rate około 97 procent, i wszystko wydawało się stabilne. Ale nikt nie śledził odsetka ponowień. Pewnego dnia przy niewielkim skoku obciążenia odsetek ponowień w ciągu pół godziny wzrósł z 5 do 40 procent. Powtórne żądania dodały obciążenia, węzły przeciążyły się bardziej, ponowień było jeszcze więcej, klasyczna spirala. Po godzinie success rate runął do 60 procent.

Wynik: analiza incydentu doprowadziła do wdrożenia osobnej metryki odsetka ponowień i wczesnego alertu na jego wzrost. Teraz po osiągnięciu progu ponowień zespół otrzymuje ostrzeżenie na długo przed załamaniem success rate. Podobne sytuacje zaczęto łapać na etapie zwiastuna, nie dopuszczając do awarii. To obrazowa ilustracja, dlaczego ponowienia zasługują na miejsce wśród czterech głównych sygnałów.

Ogólny wniosek z case studies

Trzy historie, trzy różne problemy, ale jedna prawidłowość. We wszystkich przypadkach dane do wykrycia fizycznie istniały w systemie, ale nie były przedstawione tak, by problem stał się widoczny. Rozbicie według wymiarów, percentyle zamiast średniej i uwaga na ponowienia to nie abstrakcyjne rekomendacje. To konkretne soczewki, z których każda czyni widocznym swój własny klas problemów.

FAQ: częste pytania o obserwowalność proxy

Od czego zacząć, jeśli teraz nie ma zupełnie nic?

Zacznij od logowania każdego żądania w ustrukturyzowanej formie z obowiązkowymi polami: identyfikator proxy, kod odpowiedzi, TTFB, rozmiar, numer próby, wymiary. Nawet bez metryk i dashboardów to już da ci możliwość analizowania incydentów. Następnym krokiem dodaj cztery metryki i jeden lub dwa krytyczne alerty. Nie próbuj budować wszystkiego naraz, minimalny działający zestaw jest cenniejszy niż idealny niedokończony.

Jak często zbierać metryki?