Logi w PostgreSQL. Podczas pracy z bazą danych PostgreSQL napotykamy różnego typu problemy, z których najczęstszymi są:
- niska wydajność zapytań,
- awaria bazy danych,
- niektóre narzędzia lub rozszerzenia nie działają,
- aktualizacja bazy danych nie powiodła się
- …
Problemy, wiadomo, mogą się zdarzać, ważne jest aby wiedzieć jakie są dobre praktyki w dążeniu do ich rozwiązania, tak aby szybko przywrócić właściwe działanie bazy danych bez pogłębiania kryzysu. Jeżeli firma, w której pojawia się taki problem, posiada support, wtedy należy pamiętać o właściwym przygotowaniu się do kontaktu z pracownikami helpdesku – najlepiej w formie dobrze przygotowanej dokumentacji, która powinna zawierać poniższe elementy:
- Informacja o tym jaka jest konfiguracja systemu
- Opis dokładnych objawów problemu
- I oczywiście przygotowane logi
Logi są kluczem do szybkiego rozwiązania problemu. Jeżeli nie ma możliwości zrzucenia logów, to niestety może znacznie wydłużyć proces usuwania awarii, wymusić dłuższy i częstszy kontakt z supportem.
Jakich informacji dostarczą nam logi:
- Kiedy rozpoczęło się, zakończyło i jak długo trwało zapytanie.
- Wskaźniki uszkodzenia danych.
- Wszelkie błędy w zapytaniu lub próbie połączenia.
- Statystyki zapytań i czynności związanych z utrzymaniem.
- Informacje o plikach tymczasowych.
- Kto łączył się z bazą danych.
- Skąd pochodzi połączenie.
- Jakie zapytania zostały uruchomione przed wycofaniem transakcji.
- I więcej..
Więcej logów oznacza szybszą diagnozę, szybsze rozwiązanie problemu, więcej zadowolonych klientów, większy spokój i mniejszy stres podczas pracy dla DB Adminów, lepsze planowanie zasobów. Krótko mówiąc Logi pomagają oszczędzać czas i pieniądze.
Parametry logów Postgresa:
Gdzie trafiają logi | Kiedy używane są logi | Jakie informacje zrzucamy do logów |
---|---|---|
log_destination | log_min_messages | log_autovacuum_min_duration |
logging_collector | log_min_error_statement | log_checkpoints |
log_directory | log_min_duration_statement | log_connections |
log_filename | log_min_duration_sample | log_disconnections |
log_file_mode | log_statement_sample_rate | log_duration |
log_rotation_age | log_transaction_sample_rate | log_error_verbosity |
log_rotation_size | log_hostname | |
log_truncate_on_rotation | log_line_prefix | |
log_lock_waits | ||
log_recovery_conflicts_waits | ||
log_parameter_max_length | ||
log_parameter_max_length_on_error | ||
log_statement | ||
log_replication_commands | ||
log_temp_files | ||
log_timezone |
Na początek – konfiguracja miejsca docelowego dla logów:
Parametr | Ustawienia |
---|---|
log_destination | stderr, syslog, csvlog, eventlog |
logging_collector | On/off |
log_directory | use a custom partition |
log_filename | PostgreSQL-%Y-%m-%d_%H%M%S.log |
log_file_mode | 0600 |
log_rotation_age | 1 dzień |
log_rotation_size | 10 MB |
log_truncate_on_rotation | On/off |
log_destination – PostgreSQL obsługuje kilka metod rejestrowania komunikatów serwera, w tym stderr, csvlog i syslog. W systemie Windows obsługiwany jest również eventlog. Wartość domyślna to stderr. Ustawienia parametru można zmienić tylko w pliku postgresql.conf lub korzystając z linii poleceń.Jeśli w log_destination wybierzemy metodę csvlog to wpisy dziennika logów będą wyprowadzane w formacie wartości rozdzielanych przecinkami (CSV), co jest wygodnym rozwiązaniem szczególnie przy ładowaniu logów do innych programów, np. analizatorów logów. Musimy jednakże pamiętać, że w tym przypadku aby móc generować logi w formacie CSV logging_collector musi być włączony (czyli ustawiony na wartość ON).
W przypadku ustawienia metody stderr lub csvlog plik current_logfiles jest tworzony w celu rejestrowania lokalizacji plików logów aktualnie używanych przez logging collector. Zapewnia to wygodny sposób odnajdywania dziennika logów aktualnie używanych przez instancję. Przykłady konfiguracji:
log_destination =stderr logging_collector=onlog/postgresql.log
log_destination = csvlog logging_collector=onlog/postgresql.csv
current_logfiles jest odtwarzany, gdy nowy plik logów jest tworzony jako efekt rotacji i gdy log_destination jest ponownie ładowany. Z kolei jest usuwany, gdy w log_destination nie jest ustawiona metoda ani stderr ani csvlog i gdy logging_collector jest wyłączony.Aby móc korzystać z opcji syslog dla log_destination w większości systemów Unix należy zmienić konfigurację daemon’a syslog. PostgreSQl może zrzucać logi do wskazanych syslog facilities, ale domyślnie konfiguracja syslog na większości platform będzie odrzucała takie wiadomości. Trzeba zmienić nieco konfigurację:
Przykład:
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err;local0.none /var/log/messages
Aby wiadomości były zapisywane w wybranej lokalizacji dodajemy:
local0.* /var/log/postgresql.log
logging_collector istnieje po to, aby nigdy nie tracić wiadomości logów. Oznacza to, że gdy logging collector jest włączony, to w przypadku bardzo dużego obciążenia procesy serwera mogą zostać zablokowane podczas próby wysłania dodatkowych komunikatów. W przeciwieństwie do tego rozwiązania, syslog woli usuwać wiadomości, jeśli nie może ich zapisywać, co oznacza ryzyko utraty logów, ale system nie zostanie zablokowany.
log_directory (string)Kiedy parametr logging_collector = on, log_directory determinuje katalog w którym pliki logów są tworzone. Ścieżka do katalogu może być bezwzględna lub względna. Sam parametr zwykle jest określony w pliku postgresql.conf lub przy pomocy linii poleceń serwera.
log_filename (string)Kontroluje nazwę nadaną każdemu plikowi logu (logging_collector powinien być włączony). W nazwie można użyć konwersji formatu czasu i daty. Wartość jest traktowana jako wzorzec strftime, co pozwala na konwersję daty, czasu w formę stringa. Domyślna nazwa pliku to postgresql-%Y-%m-%d_%H%M%S.log.
Jeśli określisz nazwę pliku bez %-zmienna, powinieneś zaplanować rotację logów, aby uniknąć zapchania dysku. Domyślnie pliki logów PostgreSQL nie są rotowane. Podczas korzystania z PostgreSQL with Deep Security wskazane jest skonfigurowanie parametrów w pliku postgresql.conf :
- log_filename
- log_rotation_age
- log_rotation_size
- log_truncate_on_rotation
log_rotation_age i log_rotation_size – determinuje jaki jest maxymalny czas życia pliku logu, po ustalonym czasie nowy plik logów jest tworzony. I tak np.: jeżeli ustawimy log_rotation_age na 1440 nowy plik logu będzie tworzony po 1440 minutach ( 1 dzień). Jeżeli ustawimy log_rotation_size to 10000 to w tym wypadku nowy plik logu będzie tworzony po osiągnięciu 10 000 KB.
log_truncate_on_rotation = on oraz logging_collector = on – pozwala na nadpisywanie pliku.log_filename = postgresql-%a.log oznacza, że do nazwy pliku logu dodawane są 3 pierwsze litery nazwy dnia tygodnia
log_file_mode (integer) – w systemach Unix ten parametr ustawia uprawnienia dla plików logów (gdy logging_collector = on). W systemie Windows parametr ten jest ignorowany. Domyślna wartość to 0600, co znaczy że właściciel procesu serwera Postgres może czytać i modyfikować pliki logów. Czasem użyteczną wartością jest -640 pozwalająca członkom grupy właściciela czytać pliki logów.Parametr może być ustawiony w postgresql.conf albo z linii poleceń serwera.