Optymalizacja wykresów w WanGuard: kiedy RRD zaczyna kosztować czas reakcji

Krótka odpowiedź: WanGuard tworzy osobny plik RRD dla każdego grafowanego adresu IP. Włączenie wykresów dla całej podsieci /20 to 4096 plików i około 14,8 GB danych, zapisywanych cyklicznie na dysk. Jeśli podsystem dyskowy tego nie wyrabia, procesory zaczynają czekać w IO wait, a serwer, który czeka na dysk, nie analizuje w tym czasie ataku. Grafowanie należy więc świadomie ograniczyć — czas reakcji jest ważniejszy niż komplet wykresów.

---

Dlaczego wykresy w ogóle obciążają system

Zbieranie danych jest ważne, ale równie ważne jest, żeby wiedzieć, jaki wpływ ma to na serwer WanGuard. Wykresy w WanGuard opierają się na plikach RRD (Round Robin Database). Każdy grafowany obiekt — adres IP, prefiks, interfejs — to osobny plik na dysku, aktualizowany cyklicznie zgodnie z interwałem (domyślnie co 5 minut) albo zgodnie z ustawieniami rrdcached.

Kluczowa właściwość RRD: jeden zapis to jedna operacja dyskowa. Nie ma tu efektu skali — 4096 wykresów oznacza 4096 operacji, które muszą się zmieścić w oknie zapisu. To test na IOPS, nie na przepustowość: dysk zapisujący sekwencyjnie kilkaset MB/s może się zadławić na tysiącach drobnych, losowo rozrzuconych zapisów.

---

Czym jest IO wait i dlaczego to najważniejszy licznik

IOWAIT to czas, w którym procesor był bezczynny (nie wykonywał żadnych zadań), a jednocześnie istniała co najmniej jedna niezakończona operacja dyskowa zlecona przez zadanie przypisane do tego procesora.

Warto obserwować czasy IO wait na serwerze WanGuard, zwłaszcza przy większym obciążeniu systemu i w trakcie ataku — czyli dokładnie wtedy, gdy przybywa danych do zapisania i jednocześnie system musi podjąć decyzję o reakcji.

Podstawowe narzędzia:

top

iotop

W top szukaj kolumny czasu oczekiwania na I/O oraz procesu rrdcached, który potrafi zająć 100% jednego rdzenia, zrzucając dane z pamięci do plików RRD. iotop pokazuje, który proces realnie obciąża dysk.

Kiedy serwer WanGuard czeka na zakończenie operacji dyskowych, nie ma zbyt wiele miejsca na inne operacje — takie jak analiza ataku DDoS i uruchomienie odpowiedzi. Dlatego w razie konfliktu poświęca się grafowanie na rzecz czasu reakcji.

---

Gdzie to się ustawia

Liczbę tworzonych wykresów kontroluje się w ustawieniach strefy IP:

Configuration > Network & Policy > Twoja strefa IP

W tej sekcji decydujesz, ile wykresów powstanie per prefiks. Zalecenie jest proste: dodawaj bardziej szczegółowe prefiksy i twórz wykresy tylko dla tych, które są naprawdę potrzebne. Grafowanie podsieci /20 (4094 adresy) utworzy 4096 plików i zajmie 14,8 GB danych, zrzucanych na dysk zgodnie z interwałem wykresu (5 minut) albo ustawieniem rrdcached.

Rozmiar pojedynczego pliku RRD ustawia się globalnie tutaj:

Configuration > General Settings > Graph & Storage

---

Ile miejsca zajmie: prosta arytmetyka

Każdy dodany dekoder, protokół czy zdefiniowana zmienna dokłada dane do każdego wykresu. To ustawienie globalne, obowiązujące dla wszystkich wykresów per IP — dlatego jego skutki mnożą się przez liczbę adresów.

Przyjmując, że każdy dekoder to około 0,6 MB:

Rozmiar pliku RRD	Liczba wykresów	Zajętość
3,6 MB	4096	14,8 GB
4,2 MB	4096	17,2 GB
4,8 MB	4096	19,8 GB

Widać tu rzecz, którą łatwo przeoczyć przy planowaniu: dołożenie jednego dekodera do statystyk kosztuje mniej więcej 2,4 GB na każde /20 objęte grafowaniem. Decyzja podjęta raz w ustawieniach globalnych zwielokrotnia się przez całą adresację.

Rośnie przy tym nie tylko zajętość, ale i liczba operacji zapisu w każdym cyklu — a to ona wypycha procesory w IO wait.

---

Typowe pułapki przy konfiguracji

Grafowanie całej adresacji „na wszelki wypadek". Najczęstszy błąd. Wykresy per IP mają sens dla adresów usługowych, hostów klienckich objętych ochroną i tych, na których naprawdę czyta się historię. Dla reszty wystarczają statystyki na poziomie prefiksu.

Wykresy na tym samym dysku co system i baza. Przy dużej liczbie wykresów warto wynieść RRD na osobny nośnik. W oryginalnym wdrożeniu rekomendowaliśmy osobny dysk SSD albo nawet kartę Fusion-IO. Dziś odpowiednikiem jest po prostu NVMe — istotny jest ten sam parametr: losowe IOPS zapisu, a nie przepustowość sekwencyjna.

Traktowanie rrdcached jak rozwiązania problemu. rrdcached buforuje zapisy w pamięci i grupuje je, co realnie pomaga. Ale nie zmniejsza całkowitej liczby operacji — przesuwa je w czasie. Przy naprawdę dużej liczbie wykresów zrzut i tak nastąpi, tylko skumulowany, i wtedy skok IO wait bywa jeszcze ostrzejszy.

Zmiana ustawień globalnych bez przeliczenia skutków. Zanim dołożysz dekoder do statystyk, przemnóż jego koszt przez liczbę grafowanych adresów.

Brak monitoringu samego serwera WanGuard. IO wait, zajętość dysku i czas zrzutu RRD to trzy metryki, które warto mieć na własnym wykresie.

---

Podsumowanie

Każdy wykres musi zostać zapisany albo zrzucony na dysk, a do tej operacji potrzebna jest jedna operacja I/O. Przy grafowaniu dużej liczby adresów lub podsieci dobrą praktyką jest umieszczenie wykresów na osobnym, szybkim nośniku.

Zasada nadrzędna pozostaje jedna: wykresy służą do analizy po fakcie, detekcja służy do obrony w trakcie. Jeśli jedno zaczyna zjadać drugie, ogranicza się wykresy — bo o tym, czy atak zostanie w ogóle zauważony, decyduje metoda wykrywania, a nie rozdzielczość wykresu. Więcej o modułach systemu — we wpisie co to jest WanGuard.

---

Najczęstsze pytania

Ile miejsca zajmą wykresy dla podsieci /20?

Około 14,8 GB przy plikach RRD o rozmiarze 3,6 MB (4096 plików). Przy 4,2 MB będzie to 17,2 GB, a przy 4,8 MB — 19,8 GB. Rozmiar pliku rośnie z liczbą dekoderów i zmiennych włączonych globalnie w ustawieniach wykresów.

Czy SSD rozwiązuje problem wykresów w WanGuard?

Podnosi sufit, ale go nie usuwa. Liczy się liczba losowych operacji zapisu na sekundę, a ta rośnie liniowo z liczbą grafowanych adresów. Przy odpowiednio dużej strefie IP nawet szybki nośnik zacznie generować IO wait — wtedy jedynym realnym rozwiązaniem jest ograniczenie zakresu grafowania.

Czy wyłączenie wykresów pogarsza wykrywanie ataków?

Nie. Wykrywanie opiera się na progach i statystykach ruchu, a nie na plikach RRD. Wykresy to warstwa prezentacji i historii. Tracisz możliwość obejrzenia szczegółowego przebiegu dla danego adresu wstecz — nie tracisz detekcji.

Jak sprawdzić, czy serwer nie wyrabia z zapisem wykresów?

Obserwuj czas IO wait w top oraz proces rrdcached. Jeśli IO wait rośnie cyklicznie, w rytm interwału zrzutu, a iotop wskazuje rrdcached jako główne obciążenie dysku — masz odpowiedź. Najbardziej niepokojący jest wzrost tego wskaźnika w trakcie ataku.

Czy warto tworzyć wykresy dla adresów klientów?

Tylko dla tych, dla których faktycznie prowadzisz analizę albo raportowanie — historia per IP bywa wtedy materiałem dowodowym przy zgłoszeniu incydentu. Dla adresacji nieużywanej lub czysto tranzytowej to zbędny koszt.