Pliki konfiguracyjne i pamięć podręczna usług zbierających logi (np. Winlogbeat, nxlog) w Windows: Jak działają agenty do przekazywania dzienników i gdzie zapisują dane tymczasowe?

Agenty do przekazywania dzienników, takie jak Winlogbeat czy nxlog, to kluczowe elementy w infrastrukturze monitorowania systemów Windows. Ich zadaniem jest zbieranie logów zdarzeń, dzienników aplikacji czy innych istotnych informacji z systemu operacyjnego i przesyłanie ich dalej do centralnego systemu analizy, np. Logstash, Elasticsearch, Splunk czy SIEM. Działają dyskretnie w tle, a ich sprawność zależy od dwóch typów plików: plików konfiguracyjnych i plików pamięci podręcznej (stanu). Te pliki są sercem działania każdego agenta i bez nich cała machina monitoringu po prostu by nie ruszyła.

Gdzie szukać tych plików i co to za rozszerzenia?

Zacznijmy od lokalizacji i typowych rozszerzeń. To nie jest jeden unikalny plik, ale zbiór.

• Pliki konfiguracyjne:
• Dla Winlogbeat: Zazwyczaj znajdziesz je w katalogu instalacyjnym, np. `C:\Program Files\Winlogbeat\winlogbeat.yml`. Rozszerzenie `.yml` (YAML) to standard dla produktów Elastic.
• Dla nxlog: Często plik `nxlog.conf` umiejscowiony jest w `C:\Program Files (x86)\nxlog\conf\`. Tutaj używane jest rozszerzenie `.conf`.
• Pliki pamięci podręcznej / stanu:
• Dla Winlogbeat: Kluczowy jest plik `data.json` lub podobny (często w podkatalogu `data` lub `state`) w `C:\ProgramData\Winlogbeat\`. To jest katalog, który u mnie wielokrotnie zajmował dużo miejsca.
• Dla nxlog: Podobnie, pliki stanu znajdziesz w `C:\ProgramData\nxlog\` (lub podkatalogach, np. `nxlog\data`), często bez konkretnego rozszerzenia lub z `.dat`.

`C:\ProgramData` to ukryty folder systemowy, stworzony specjalnie dla danych aplikacji, które są wspólne dla wszystkich użytkowników i nie są częścią instalacji programu. Właśnie tam agenty przechowują swoje dane operacyjne.

Do czego służą i kto ich używa?

Pliki konfiguracyjne są instrukcją dla agenta. Definiują one:

• Jakie logi zbierać? (np. dzienniki zdarzeń Windows: Security, System, Application, niestandardowe pliki tekstowe).
• Jakie filtry zastosować? (np. ignoruj zdarzenia o niskim priorytecie, zbieraj tylko błędy).
• Gdzie wysyłać zebrane dane? (adres IP i port serwera docelowego, np. Logstash: `192.168.1.10:5044`).
• Z jakim formatem? (JSON, syslog).
• Jak często wysyłać?

To właśnie w tych plikach konfigurujesz niuanse działania agenta.

Pliki pamięci podręcznej (stanu) to zupełnie inna bajka. Ich główna rola to zapewnienie, że logi są wysyłane dokładnie raz lub, w przypadku awarii, przynajmniej raz bez utraty danych. Działają jak „zakładka” w książce. Jeśli Winlogbeat zbiera dziennik zdarzeń, zapisuje w pliku stanu, które zdarzenie było ostatnio pomyślnie wysłane. Gdy usługa zostanie zrestartowana, przeczyta ten plik i wznowi wysyłanie od tego miejsca. Bez nich, po każdym restarcie agent zaczynałby wysyłać logi od początku, generując potężne duplikacje. U mnie pierwszy raz konfiguracja Winlogbeat, a potem debugowanie duplikacji, zajęła całe popołudnie, bo zapomniałem o tej funkcji.

Czy to wirus? Czy można usunąć i co się stanie?

Absolutnie nie! Te pliki nie są wirusami. Są integralną częścią legalnego oprogramowania monitorującego. Usuwanie ich „na ślepo” jest proszeniem się o kłopoty.

• Usunięcie plików konfiguracyjnych: Agent nie będzie mógł się uruchomić lub będzie działał z domyślnymi (często bezużytecznymi) ustawieniami, zgłaszając błędy w Dzienniku Zdarzeń Windows. Usługa prawdopodobnie przejdzie w stan „stopped”.
• Usunięcie plików pamięci podręcznej/stanu: To jest znacznie bardziej podstępne. Agent wznowi wysyłanie logów od najwcześniej dostępnego punktu (lub od momentu, w którym został zainstalowany), co spowoduje zalew duplikatów w Twoim systemie SIEM/Logstash. Zdarzyło mi się kiedyś przez przypadek skasować plik registry Winlogbeata na serwerze i w ciągu kilku minut do Logstasha wpadło ponad 50 000 duplikatów zdarzeń, co zapchało mi cały potok! Musiałem szybko reagować, żeby nie obciążyć nadmiernie serwera Elastic.

Jeśli chcesz usunąć te pliki, zrób to tylko w przypadku deinstalacji agenta lub gdy świadomie chcesz zresetować stan i *zaakceptować* duplikację. Zawsze zrób kopię zapasową przed usunięciem.

Typowe problemy i błędy

• Błędy składni w plikach konfiguracyjnych: Najczęstszy problem. Jeden spacje zamiast tabulacji w YAML, błędna ścieżka do dziennika – i agent odmawia współpracy. `winlogbeat.exe test config` to Twój przyjaciel.
• Brak uprawnień: Usługa działająca jako np. `Local System` lub `Network Service` może nie mieć praw do odczytu konkretnych dzienników zdarzeń lub plików stanu. Sprawdź, na jakim koncie działa usługa i nadaj mu odpowiednie uprawnienia do katalogów i źródeł logów.
• Problemy z siecią/połączeniem: Agenty nie mogą połączyć się z docelowym serwerem (np. Logstash) z powodu firewalla, błędnego adresu IP, czy problemów DNS. Logi błędów w Dzienniku Zdarzeń agenta (zwykle w Application) są tu kluczowe.
• Przepełnienie dysku: Jeśli agent nie może wysyłać logów, a konfiguracja przewiduje buforowanie, pliki stanu mogą rosnąć w nieskończoność. U mnie jeden nxlog na zapomnianym serwerze przez dwa tygodnie zbierał logi do pamięci podręcznej i plik stanu urósł do ~30 GB! Szybka reakcja była konieczna, żeby nie zabić dysku.
• Zbyt wiele logów: Niekiedy agent jest konfigurowany do zbierania zbyt dużej liczby logów, co może obciążać system i dysk.
• Nie wiem czemu — ale działa: To mój ulubiony błąd. Czasem po zmianie konfiguracji, agent działa, ale nie loguje tego co byś chciał. Dopiero po głębszej analizie okazuje się, że filtr był źle ustawiony i odrzucał 90% zdarzeń.

Dlaczego nie są read-only ani systemowe?

Pliki konfiguracyjne nie są domyślnie `read-only` ani „systemowe” w sensie Windows, ponieważ administrator musi mieć możliwość ich edycji. Natomiast pliki stanu (pamięci podręcznej) muszą być aktywnie zapisywane przez usługę podczas jej działania, więc nie mogą być `read-only`. Chociaż znajdują się w ukrytym folderze `C:\ProgramData`, co sprawia, że są mniej widoczne dla przypadkowego użytkownika, nie są one chronione na tym samym poziomie co pliki systemowe Windows (np. jądra systemu). To celowe — pozwala to na łatwiejsze zarządzanie i debugowanie przez administratorów.

Najczęstsze pytania

Czy mogę zmieniać pliki konfiguracyjne, gdy agent działa?

Nie, zawsze zatrzymaj usługę agenta (np. Winlogbeat lub nxlog) przed edycją plików konfiguracyjnych, a następnie uruchom ją ponownie, aby zmiany zostały zastosowane.

Jak zresetować stan Winlogbeata lub nxloga bez reinstalacji?

Zatrzymaj usługę agenta, usuń pliki pamięci podręcznej/stanu (np. `data.json` dla Winlogbeat w `C:\ProgramData\Winlogbeat\`) i uruchom usługę ponownie. Pamiętaj, że to spowoduje duplikację logów.

Co zrobić, gdy plik pamięci podręcznej zajmuje za dużo miejsca?

Sprawdź, czy agent może łączyć się z serwerem docelowym. Jeśli nie, rozwiąż problem z połączeniem. W ostateczności możesz usunąć plik pamięci podręcznej (po zatrzymaniu usługi), ale przygotuj się na duplikaty.