Dzienniki

Pliki dziennika, syslog, ślad audytu oraz jak długo przechowywane są zadania i wpisy audytu

  1. Pliki dziennika
  2. Wiersze JSON
  3. Syslog
  4. Ślad audytu
  5. Retencja

Pliki dziennika

AnsibleForms zapisuje dwa dzienniki rotowane codziennie w LOG_PATH (%PERSISTENT_FOLDER%/logs), kompresuje starsze dni i przechowuje je przez LOG_RETENTION_DAYS (domyślnie 30, 0 zachowuje każdy plik; zmiana na stronie ustawień działa od razu):

  • ansibleforms.<date>.log : wszystko na poziomie LOG_LEVEL i wyżej
  • ansibleforms.errors.<date>.log : tylko błędy

Konsola, czytana przez docker logs lub kubectl logs, ma własny poziom, LOG_CONSOLE_LEVEL. Oba domyślnie mają notice, co jest właściwe dla produkcji; używaj info lub debug tylko podczas diagnozowania problemów i zostaw ENABLE_DB_QUERY_LOGGING wyłączone. Poziomy można zmieniać na stronach ustawień bez restartu, a strona Dziennik serwera pokazuje dziennik użytkownikom z opcją showLogs.


Wiersze JSON

Dla kolektora logów takiego jak Loki, ELK czy Splunk ustaw LOG_FORMAT na json. Każdy wiersz, na konsoli i w plikach, jest wtedy jednym obiektem JSON zamiast <time> <level>: <message>:

{"time":"2026-10-12T08:15:02.113Z","level":"notice","message":"App running on port 8000!","role":"all","host":"forms01"}
Pole Zawartość
time Czas, w ISO 8601 UTC
level Poziom logowania
message Komunikat
requestId Żądanie, do którego należy wiersz, gdy został zapisany podczas jego obsługi
role Rola procesu, AF_ROLE, lub all, gdy nie jest ustawiona
host Nazwa hosta maszyny lub kontenera, w którym działa proces

Każde żądanie dostaje identyfikator: nagłówek X-Request-Id wysłany przez reverse proxy albo nowy. Jest zwracany w nagłówku X-Request-Id odpowiedzi i niesiony przez każdy wiersz zapisany podczas obsługi żądania (jako [req <id>] w wierszach tekstowych), więc żądanie można prześledzić w dzienniku i dopasować do dziennika proxy. Zmiana na stronie ustawień działa od razu.


Syslog

Serwerami syslog zarządza się w Ustawienia > Połączenia > Syslog, dzięki czemu serwer syslog lub SIEM dostaje dziennik na bieżąco. Możesz dodać kilka serwerów, a każdy ma własne ustawienia:

Ustawienie Co robi
Włączony Cokolwiek dostają tylko włączone serwery, więc serwer można wstrzymać bez usuwania; przełączają go też Włącz i Wyłącz w menu wiersza
Protokół udp4 (domyślnie), udp6, tcp4, tcp6, tls4, tls6, unix lub unix-connect
Host i port Serwer docelowy, domyślnie port 514; protokół unix przyjmuje zamiast tego ścieżkę gniazda
Otrzymuje Dziennik serwera, wpisy audytu lub oba (domyślnie dla nowego serwera)
Poziom Najniższy poziom dziennika serwera, który otrzymuje, domyślnie info; wpisy audytu są wysyłane zawsze
Typ BSD (RFC 3164, domyślnie) lub RFC 5424

Zmiana działa na każdym węźle bez restartu, a strona serwera ma przycisk, który wysyła do niego komunikat testowy. Nieosiągalny serwer nigdy nie zatrzymuje aplikacji: błąd jest zapisywany na konsoli.

Od wersji 7.3.0 serwery syslog wymagają pełnych uprawnień do ustawień, czyli opcji roli showSettings: sam dostęp do ustawień połączeń nie wystarcza, bo serwer syslog otrzymuje dziennik serwera i wpisy audytu.

Zmienne LOG_SYSLOG_* z wcześniejszych wersji są przestarzałe od wersji 7. Pierwsze uruchomienie, które znajdzie ustawioną LOG_SYSLOG_HOST, importuje je jednorazowo jako serwer syslog, który otrzymuje dziennik serwera jak wcześniej, i od tej pory je ignoruje. Po tym pierwszym uruchomieniu usuń je ze środowiska i zarządzaj serwerem na stronie ustawień.


Ślad audytu

Strona Dziennik audytu (w Ustawienia > Dzienniki) zapisuje, kto co zmienił, na co pliki dziennika słabo odpowiadają. Zapisuje:

  • każdą zmianę wykonaną przez API (POST, PUT, PATCH, DELETE), łącznie z próbami odrzuconymi kodem 401 lub 403
  • logowania, z nazwą użytkownika, której próbowano
  • zdarzenia samej aplikacji, takie jak nocne kopie zapasowe, usunięte kopie zapasowe, wyczyszczone zadania i zastosowania config seed

Każdy wpis ma czas, wykonawcę (użytkownika lub samą aplikację dla jej własnych zadań), adres IP klienta, akcję, jej cel i wynik: success, failure lub denied. Strona filtruje po wykonawcy, akcji i wyniku, a otworzyć ją mogą użytkownicy z opcją roli showSettings.

Adres IP to ten, który widzi AnsibleForms, czyli adres proxy, gdy aplikacja działa za proxy. Ustaw TRUST_PROXY na liczbę lub adresy swoich proxy, a AnsibleForms zapisze zamiast tego adres klienta, który proxy podaje w X-Forwarded-For; zobacz Reverse proxy.

Aby przechowywać ślad audytu poza instancją, dla SIEM, dodaj serwer syslog, który otrzymuje wpisy audytu (zobacz Syslog). Każdy wpis jest wysyłany na bieżąco, jako jeden wiersz audit {...} z wpisem w JSON, niezależnie od poziomu serwera. Kopii w syslogu nie usuwa poniższa retencja ani nie zastępuje jej przywrócenie bazy danych.


Retencja

Dwa codzienne zadania z ustawieniem chronią bazę danych przed nieograniczonym rozrostem:

Zmienna Domyślnie Uruchamia się o Usuwa
AUDIT_RETENTION_DAYS 365 3:30 Wpisy audytu starsze niż ta wartość
JOB_RETENTION_DAYS 0 (zachowaj wszystko) 2:30 Zakończone zadania starsze niż ta wartość, z ich wynikiem

0 zachowuje wszystko w obu przypadkach. Dwa kolejne codzienne zadania nie mają ustawienia: o 3:00 usuwane są zapisane tokeny odświeżania starsze niż 30 dni i wygasłe unieważnienia tokenów, a o 4:00 zapisane zadania, których termin ważności minął. Godziny są w strefie czasowej LOG_TZ, a uruchamia je worker.

Wynik zadań to zwykle najszybciej rosnąca tabela: strona Stan raportuje jej rozmiar i ostrzega, gdy przekroczy 1 GB bez ustawionej retencji. Działające zadania i zadania czekające na zatwierdzenie nigdy nie są usuwane. Wybierz retencję zadań zgodną z wymaganiami audytu, a ślad audytu przechowuj co najmniej tak samo długo.