Jak skonfigurować logi serwera PostgreSQL (co i gdzie logować)

PostgreSQL

Jak skonfigurować logi serwera PostgreSQL (co i gdzie logować)

W skrócie

Dobre logi to pierwsza rzecz, po którą sięgasz, gdy baza zwalnia albo coś się psuje, i ostatnia, o której ktoś pamięta, zanim problem wystąpi. PostgreSQL potrafi logować bardzo dużo, ale domyślnie robi to skromnie, a lokalizacja plików zależy od sposobu instalacji. Pokażemy Ci, jak włączyć zbieranie logów, gdzie je kierować i które zdarzenia warto rejestrować, żeby diagnoza była szybka. Temat jest dla każdego, kto administruje bazą i chce widzieć, co się w niej dzieje.

Jak to wygląda w praktyce

Aplikacja zgłasza błędy albo baza działa wolno, a Ty otwierasz katalog z logami i albo go nie znajdujesz, albo pliki są niemal puste. W innym przypadku logi są, ale nie ma w nich tego, czego szukasz: nie widać treści wolnych zapytań, nie ma informacji, kto się łączył, nie widać kontekstu błędu. Bywa też odwrotnie, że logów jest tak dużo, iż nie da się w nich niczego znaleźć, bo rejestrowane jest wszystko jak leci. Wspólny objaw to brak użytecznej informacji we właściwym momencie, przez co diagnoza opiera się na zgadywaniu zamiast na faktach.

Dlaczego tak się dzieje

PostgreSQL potrafi wysyłać komunikaty na kilka sposobów, a to, gdzie trafiają, zależy od konfiguracji i od dystrybucji. Za kierowanie logów do plików odpowiada parametr logging_collector, który w części instalacji jest wyłączony, przez co komunikaty idą na standardowe wyjście procesu i giną albo są przechwytywane przez menedżera usług. Katalog i wzorzec nazw plików ustawiają log_directory i log_filename. To, jak dużo szczegółów widzisz, zależy od poziomu logowania, głównie od log_min_messages dla komunikatów serwera i log_min_error_statement dla zapytań, które zakończyły się błędem. Osobno działa log_min_duration_statement, który rejestruje zapytania trwające dłużej niż zadany próg, i to on jest najcenniejszy przy szukaniu wolnych zapytań. Do tego dochodzą przełączniki logujące połączenia, rozłączenia oraz szablon prefiksu każdej linii, czyli log_line_prefix, który decyduje, czy w logu jest czas, użytkownik i baza. Jeśli te ustawienia są domyślne, log bywa albo za ubogi, albo bez kontekstu.

Jak to rozwiązać krok po kroku

1. Włącz zbieranie logów do plików, ustawiając logging_collector = on. Ten parametr wymaga restartu serwera, więc zaplanuj go świadomie.
2. Ustaw miejsce i nazwy plików przez log_directory oraz log_filename. Wygodny jest wzorzec z datą w nazwie, dzięki czemu logi dzielą się na pliki dzienne i łatwiej je archiwizować.
3. Ustaw log_line_prefix tak, aby każda linia zawierała znacznik czasu, identyfikator procesu, użytkownika i bazę. Bez tego kontekstu log jest znacznie mniej użyteczny.
4. Do wychwytywania wolnych zapytań ustaw log_min_duration_statement na rozsądny próg w milisekundach, żeby rejestrować tylko zapytania trwające dłużej niż ten czas, zamiast wszystkich.
5. Zdecyduj o poziomie komunikatów: log_min_messages steruje tym, jak szczegółowe zdarzenia serwera trafiają do logu, a osobne przełączniki pozwalają logować nawiązywanie i kończenie połączeń, jeśli tego potrzebujesz.
6. Po zmianach, które tego nie wymagają, przeładuj konfigurację przez reload, a po włączeniu kolektora logów wykonaj restart. Następnie wywołaj celowo jakieś zdarzenie i sprawdź, czy pojawia się w pliku.

Jak sprawdzić, że zadziałało

Ścieżkę i wzorzec nazw potwierdzisz poleceniami SHOW log_directory; oraz SHOW log_filename;, a to, czy kolektor działa, sprawdzisz przez SHOW logging_collector;. Najpewniejszy test to wywołać zdarzenie, które ma być logowane, i zajrzeć do pliku. Wykonaj celowo zapytanie z błędem albo zapytanie trwające dłużej niż ustawiony próg i sprawdź, czy pojawiło się w logu z pełnym kontekstem, czyli czasem, użytkownikiem i bazą w prefiksie. Jeśli widzisz swoje zdarzenie z właściwymi danymi, konfiguracja działa. Gdy plik pozostaje pusty mimo wywołanego zdarzenia, wróć do sprawdzenia, czy kolektor jest włączony i czy poziom logowania nie odcina tego typu komunikatów.

Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5