Andrzej Majewski Written in Serwer www, Bezpieczeństwo, Linux, Nginx, Optymalizacja, Wazuh

Linux devotee and Bournemouth-based IT expert, obsessed with homelabbing, server performance, and elegant Python code.

Spis treści

Toggle

Studium przypadku:

Każdy administrator zna to uczucie. Spoglądasz na panel swojego systemu SIEM, oczekując strumienia alertów, a tam… cisza. Dashboardy się nie odświeżają, ostatnie zdarzenia są sprzed wielu godzin. Pierwsza myśl? Awaria. Logujesz się na serwer, wpisujesz systemctl status wazuh-manager i widzisz zielony napis: active (running).

Właśnie wpadłeś w pułapkę „cichej awarii” – jednego z najbardziej frustrujących problemów w zarządzaniu systemami. Usługa działa, ale nie pracuje. W tym artykule przejdziemy krok po kroku przez mój ostatni bój z Wazuhem, który przestał przetwarzać dane, mimo że pozornie wszystko było w porządku. To historia o fałszywych tropach, jednym kluczowym odkryciu i pułapce wydajnościowej, o której zapomina wielu administratorów wdrażających Wazuh na serwerach VPS.

Krok 1: Potwierdzenie problemu – Gdzie utknęły dane?

Skoro usługa menedżera działa, problem musi leżeć w potoku przetwarzania danych. Pierwszym i najważniejszym krokiem jest sprawdzenie, czy menedżer w ogóle generuje alerty.

# Sprawdzamy znacznik czasu ostatniego alertu
tail -1 /var/ossec/logs/alerts/alerts.json

Wynik był bezlitosny – ostatni alert pochodził z poprzedniego dnia. To potwierdziło, że problem leży w samym menedżerze lub w komunikacji z agentami.

Następny krok to zajrzenie pod maskę silnika analitycznego. Pliki stanu Wazuh to prawdziwa kopalnia wiedzy:

cat /var/ossec/var/run/wazuh-analysisd.state

I tu pojawił się pierwszy dowód zbrodni:

• events_dropped='169742'
• event_queue_usage='1.00'

Prawie 170 tysięcy odrzuconych zdarzeń i w 100% zapełniona kolejka. Menedżer nie tyle nie pracował, co tonął pod naporem zdarzeń, których nie był w stanie przetworzyć. Diagnoza: klasyczna burza zdarzeń (event storm).

Krok 2: Poszukiwanie winowajcy – Fałszywe tropy

Logika podpowiadała, że któryś z agentów lub lokalny plik logu musi generować ogromny ruch. Rozpocząłem polowanie:

1. Analiza archiwów: Próby parsowania archives.log w poszukiwaniu „hałaśliwego” agenta lub pliku spaliły na panewce. Format logów był zbyt zróżnicowany.
2. Przegląd konfiguracji: Sprawdziłem plik ossec.conf pod kątem monitorowanych plików (<localfile>) i przeanalizowałem ich rozmiary. Nic. Żaden plik nie był podejrzanie duży. Logi NGINX, choć aktywne, nie tłumaczyły paraliżu na taką skalę.

Czułem, że kręcę się w kółko. Problem musiał leżeć gdzieś indziej.

Krok 3: Przełom – Potęga journald

Wróciłem do konfiguracji i zauważyłem jedną, często pomijaną linijkę:

<localfile>
  <log_format>journald</log_format>
  <location>journald</location>
</localfile>

Wazuh pobierał logi bezpośrednio z dziennika systemowego systemd. To oznaczało, że źródłem problemu mogła być dowolna usługa na serwerze, a niekoniecznie ta, którą świadomie monitorowałem.

To był strzał w dziesiątkę. Użyłem journalctl, aby cofnąć się w czasie do dokładnego momentu awarii:

journalctl --since "2025-09-13 17:25:00" --until "2025-09-13 17:35:00"

Wynik był jednoznaczny. Na ekranie zalała mnie fala identycznych błędów, powtarzających się tysiące razy na sekundę:

Sep 13 17:28:02 WazuhSecurity wazuh-analysisd[2421035]: wazuh-db: ERROR: SQL error: 'disk I/O error'
Sep 13 17:28:02 WazuhSecurity wazuh-analysisd[2421035]: wazuh-db: ERROR: Could not execute SQL query.

Wszystko zaczęło się od jednej linijki, tuż przed lawiną błędów:

Sep 13 17:28:02 WazuhSecurity wazuh-analysisd[...]: wazuh-modulesd:vulnerability-detector: INFO: Starting vulnerability scan.

Znalazłem winowajcę. Skaner podatności (vulnerability-detector) uruchomił operację tak intensywną dla dysku, że ten przestał odpowiadać. Błąd I/O został zapisany do journald, skąd logcollector Wazuh natychmiast go odczytał i wysłał do analysisd. Silnik analityczny, próbując przetworzyć błąd, prawdopodobnie generował kolejne operacje na dysku, tworząc katastrofalną pętlę sprzężenia zwrotnego, która w kilka sekund zapchała cały system.

Ostateczna diagnoza: VPS i ukryte limity IOPS

Dlaczego jednak dysk SSD na serwerze VPS zgłaszał błędy I/O?

• Miejsce na dysku? Było go mnóstwo (tylko 26% zajętości).
• Awaria sprzętowa? Logi kernela (dmesg) były czyste.

Prawdziwa przyczyna leżała w modelu biznesowym hostingu współdzielonego. Mój serwer, choć z dyskiem „SSD”, to podstawowy plan Cloud VPS. W takich środowiskach dostawcy limitują wydajność operacji wejścia/wyjścia (IOPS), aby zapewnić sprawiedliwy podział zasobów.

Skaner podatności Wazuh to narzędzie klasy enterprise. Jego zapotrzebowanie na IOPS podczas skanowania dalece przekroczyło limity przydzielone mojemu VPS-owi. Mój dysk nie był uszkodzony ani pełny – był po prostu za wolny na to zadanie.

Plan naprawczy: Jak przywrócić Wazuh do życia?

1. Natychmiastowe obejście problemu

Aby natychmiast przywrócić kluczową funkcjonalność (zbieranie alertów), musiałem poświęcić winowajcę. Wyłączyłem skaner podatności w pliku /var/ossec/etc/ossec.conf:

<vulnerability-detector>
  <enabled>no</enabled>  <!-- Zmiana 'yes' na 'no' -->
  ...
</vulnerability-detector>

Po restarcie menedżera (systemctl restart wazuh-manager) system ożył. Kolejki się opróżniły, a alerty od agentów zaczęły spływać normalnie.

2. Długoterminowe rozwiązanie

Jedynym prawdziwym rozwiązaniem jest zapewnienie odpowiednich zasobów. Opcje są dwie:

• Upgrade planu VPS na taki z gwarantowaną, wysoką liczbą IOPS.
• Migracja na serwer dedykowany lub do chmury (AWS, GCP, Azure), gdzie mam pełną kontrolę nad wydajnością dysku.

Kluczowe wnioski

Ta historia to cenne przypomnienie kilku prawd:

1. active (running) nie oznacza „działa poprawnie”. Zawsze ufaj metrykom wewnętrznym, a nie tylko statusowi usługi.
2. events_dropped to Twój najważniejszy wskaźnik. Jeśli ta wartość rośnie, masz poważny problem z wydajnością.
3. Uważaj na pułapki wydajnościowe VPS. „Dysk SSD” w nazwie pakietu nie gwarantuje wydajności potrzebnej do profesjonalnych narzędzi bezpieczeństwa. Zawsze sprawdzaj limity IOPS.
4. Diagnostyka to proces eliminacji. Czasem trzeba podążyć kilkoma fałszywymi tropami, aby dotrzeć do prawdziwej przyczyny.

Mam nadzieję, że moje doświadczenia pomogą Wam w przyszłości szybciej diagnozować podobne „ciche awarie”.

Andrzej Majewski

Moja fascynacja technologią zaczęła się podczas studiów informatycznych na Uniwersytecie Zielonogórskim. Od czasu przeprowadzki do Wielkiej Brytanii w 2015 roku i osiedlenia się na stałe w Bournemouth, przekułem tę pasję w karierę zawodową poświęconą infrastrukturze o wysokiej wydajności.W głębi duszy jestem entuzjastą Linuxa – to zaangażowanie wykracza poza moją pracę zawodową w SolutionsInc i obejmuje również mój rozbudowany, prywatny homelab. Niezależnie od tego, czy zarządzam złożonymi architekturami serwerowymi przez ISPConfig, buduję systemy VoIP w ramach Phones Rescue, czy tworzę narzędzia do automatyzacji w Pythonie, najlepiej czuję się, podejmując wyzwania związane z projektowaniem wydajnych rozwiązań open-source