Jak najlepiej wykorzystać logi PostgreSQL

Jako nowoczesny RDBMS, PostgreSQL zawiera wiele parametrów do dostrojenia. Jednym z obszarów do rozważenia jest sposób, w jaki PostgreSQL powinien rejestrować swoje działania. Logowanie jest często pomijane w zarządzaniu bazą danych Postgres, a jeśli nie jest ignorowane, zwykle jest źle ustawione. Dzieje się tak, ponieważ przez większość czasu cel rejestrowania jest niejasny. Oczywiście podstawowa przyczyna rejestrowania jest dobrze znana, ale czasami brakuje zrozumienia, w jaki sposób będą one używane.

Wymagania dotyczące rejestrowania w każdej organizacji są unikalne, dlatego też sposób konfiguracji rejestrowania PostgreSQL również będzie inny. To, co firma świadcząca usługi finansowe musi rejestrować w swoich dziennikach bazy danych, będzie się różnić od tego, co firma zajmująca się krytycznymi informacjami o stanie zdrowia musi rejestrować. A w niektórych przypadkach mogą być również podobne.

W tym artykule omówię kilka podstawowych praktyk, aby jak najlepiej wykorzystać logi PostgreSQL. Ten blog nie jest twardym i szybkim podręcznikiem; czytelnicy są bardziej niż mile widziani, aby podzielić się swoimi przemyśleniami w sekcji komentarzy. Aby jednak uzyskać z tego jak najlepszą wartość, proszę czytelnika, aby zastanowił się, w jaki sposób chce używać swoich dzienników serwera bazy danych PostgreSQL:

• Powód zgodności z prawem, w którym należy przechwycić określone informacje
• Audyt bezpieczeństwa, w którym muszą być obecne określone szczegóły wydarzenia
• Rozwiązywanie problemów z wydajnością, w których mają być rejestrowane zapytania i ich parametry
• Codzienne wsparcie operacyjne, w ramach którego monitorowana jest określona liczba metryk

Powiedziawszy to, zacznijmy.

Nie wprowadzaj ręcznych zmian w pliku postgresql.conf

Wszelkie zmiany w pliku postgresql.conf należy wprowadzać za pomocą systemu zarządzania konfiguracją, takiego jak Puppet, Ansible lub Chef. Dzięki temu zmiany można śledzić i w razie potrzeby można je bezpiecznie przywrócić do poprzedniej wersji. Dotyczy to sytuacji, gdy wprowadzasz zmiany w parametrach rejestrowania.

Administratorzy baz danych często tworzą wiele kopii pliku postgresql.conf, z których każda ma nieco inne parametry, z których każda ma inny cel. Ręczne zarządzanie różnymi plikami konfiguracyjnymi jest uciążliwym zadaniem, jeśli nie jest podatne na błędy. Z drugiej strony, system zarządzania konfiguracją może zmienić nazwę i używać różnych wersji pliku postgresql.conf na podstawie przekazanego do niego parametru. Ten parametr będzie dyktować przeznaczenie bieżącej wersji. Gdy potrzeba zostanie spełniona, stary plik konfiguracyjny można przywrócić, zmieniając ten sam parametr wejściowy.

Na przykład, jeśli chcesz rejestrować wszystkie instrukcje uruchomione na twojej instancji PostgreSQL, możesz użyć pliku konfiguracyjnego z wartością parametru „log_statement=all”. Gdy nie ma potrzeby rejestrowania wszystkich instrukcji – być może po ćwiczeniu rozwiązywania problemów – poprzedni plik konfiguracyjny może zostać przywrócony.

Użyj oddzielnych plików dziennika dla PostgreSQL

Zalecam włączenie natywnego kolektora logów PostgreSQL podczas normalnych operacji. Aby włączyć natywne logowanie PostgreSQL, ustaw następujący parametr na on:

logging_collector = on

Są ku temu dwa powody:

Po pierwsze, w obciążonych systemach system operacyjny może nie konsekwentnie rejestrować wiadomości PostgreSQL w syslog (zakładając instalację opartą na nix) i często odrzucać wiadomości. Przy natywnym logowaniu PostgreSQL oddzielny demon zajmuje się rejestrowaniem zdarzeń. Gdy PostgreSQL jest zajęty, proces ten odroczy zapisywanie do plików dziennika, aby umożliwić zakończenie wątków zapytań. Może to zablokować cały system do momentu zapisania zdarzenia w dzienniku. Dlatego przydatne jest zapisywanie mniej szczegółowych komunikatów w dzienniku (jak zobaczymy później) i używanie skróconych przedrostków wierszy dziennika.

Po drugie – jak zobaczymy później – logi powinny być zbierane, analizowane, indeksowane i analizowane za pomocą narzędzia Log Management. Posiadanie PostgreSQL-a rejestrującego zdarzenia w syslogu będzie oznaczać utworzenie dodatkowej warstwy filtrowania i dopasowywania wzorców w części Log Management, aby odfiltrować wszystkie „komunikaty o szumie”. Dedykowane pliki dziennika można łatwo analizować i indeksować pod kątem zdarzeń za pomocą większości narzędzi.

Ustaw miejsce docelowe dziennika na stderr

Rozważmy parametr „log_destination”. Może mieć cztery wartości:

log_destination = stderr | syslog | csv | eventlog

O ile nie ma dobrego powodu, aby zapisywać zdarzenia dziennika w formacie rozdzielanym przecinkami lub dziennik zdarzeń w systemie Windows, zalecam ustawienie tego parametru na stderr. Dzieje się tak, ponieważ w przypadku miejsca docelowego pliku CSV niestandardowa wartość parametru „log_line_prefix” nie będzie miała żadnego efektu, a mimo to prefiks może zawierać cenne informacje.

Z drugiej strony dziennik CSV można łatwo zaimportować do tabeli bazy danych, a następnie przeszukać go przy użyciu standardowego SQL. Niektórzy użytkownicy PostgreSQL uważają to za wygodniejsze niż obsługa surowych plików dziennika. Jak zobaczymy później, nowoczesne rozwiązania do zarządzania logami mogą natywnie analizować logi PostgreSQL i automatycznie tworzyć na ich podstawie istotne informacje. W przypadku plików CSV raportowanie i wizualizacja muszą być wykonywane ręcznie przez użytkownika.

Ostatecznie sprowadza się to do twojego wyboru. Jeśli nie masz nic przeciwko tworzeniu własnego potoku pozyskiwania danych w celu załadowania dzienników CSV do tabel bazy danych, oczyszczenia i przekształcenia danych oraz tworzenia niestandardowych raportów, które odpowiadają potrzebom Twojej firmy, upewnij się, że „log_destination” jest ustawione na CSV.

Użyj znaczących nazw plików dziennika

Gdy pliki dziennika PostgreSQL są zapisywane lokalnie, stosowanie stylu nazewnictwa może nie wydawać się konieczne. Domyślny styl nazwy pliku to „postgresql-%Y-%m-%d_%H%M%S.log” dla dzienników w formacie innym niż CSV, co jest wystarczające w większości przypadków.

Nazewnictwo staje się ważne, gdy zapisujesz pliki dziennika z wielu serwerów w centralnej lokalizacji, takiej jak dedykowany serwer dziennika, zamontowany wolumin NFS lub zasobnik S3. W takim przypadku zalecam użycie dwóch parametrów:

log_directory
log_filename

Aby przechowywać pliki dziennika z wielu instancji w jednym miejscu, najpierw utwórz osobną hierarchię katalogów dla każdej instancji. Może to wyglądać mniej więcej tak:

/<Application_Name>/<Environment_Name>/<Instance_Name>

„log_directory” każdej instancji PostgreSQL można następnie wskazać na wyznaczony folder.

Każda instancja może następnie użyć tej samej wartości parametru „log_filename”. Wartość domyślna utworzy plik taki jak

postgresql_2020-08-25_2359.log

Aby użyć bardziej znaczącej nazwy, ustaw „log_filename” na coś takiego:

log_filename = "postgresql_%A-%d-%B_%H%M"

Pliki dziennika otrzymają wtedy nazwę:

postgresql_Saturday-23-August_2230

Użyj znaczącego prefiksu wiersza dziennika

Prefiksy wierszy dziennika PostgreSQL mogą zawierać najcenniejsze informacje poza samą wiadomością. Dokumentacja Postgresa pokazuje kilka znaków ucieczki do konfiguracji prefiksu zdarzeń dziennika. Te sekwencje specjalne są zastępowane różnymi wartościami stanu w czasie wykonywania. Niektóre aplikacje, takie jak pgBadger, oczekują określonego przedrostka wiersza dziennika.

Zalecam umieszczenie w prefiksie następujących informacji:

• Czas zdarzenia (bez milisekund):%t
• Nazwa klienta zdalnego lub adres IP:%h
• Nazwa użytkownika:%u
• Dostęp do bazy danych:%d
• Nazwa aplikacji:%a
• Identyfikator procesu:%p
• Przerywanie wyjścia procesu bez sesji:%q
• Numer wiersza dziennika dla każdej sesji lub procesu, zaczynając od 1:%l

Aby zrozumieć, o co chodzi w każdym polu w prefiksie, przed polem możemy dodać mały literał ciągu. Tak więc wartość identyfikatora procesu może być poprzedzona literałem „PID=”, nazwa bazy danych może być poprzedzona „db=” itd. Oto przykład:

log_line_prefix = 'time=%t, pid=%p %q db=%d, usr=%u, client=%h , app=%a, line=%l '

W zależności od tego, skąd pochodzi zdarzenie, prefiks wiersza dziennika będzie pokazywał różne wartości. Zarówno procesy działające w tle, jak i procesy użytkownika będą rejestrować swoje komunikaty w pliku dziennika. Dla procesów systemowych określiłem %q, co spowoduje pominięcie dowolnego tekstu po identyfikatorze procesu (%p). Każda inna sesja pokaże nazwę bazy danych, nazwę użytkownika, adres klienta, nazwę aplikacji i numerowaną linię dla każdego zdarzenia.

Dodałem również pojedynczą spację po przedrostku wiersza dziennika. To miejsce oddziela prefiks zdarzenia dziennika od rzeczywistego komunikatu o zdarzeniu. Nie musi to być znak spacji — można użyć dowolnego typu podwójnego dwukropka (::), łącznika (-) lub innego znaczącego separatora.

Ustaw również parametr „log_hostname” na 1:

log_hostname = 1

Bez tego zostanie wyświetlony tylko adres IP klienta. W systemach produkcyjnych będzie to zazwyczaj adres serwera proxy, systemu równoważenia obciążenia lub puli połączeń. Jeśli nie znasz na pamięć adresów IP tych systemów, warto zarejestrować ich nazwy hostów. Jednak wyszukiwanie DNS doda również dodatkowy czas demonowi rejestrującemu na zapis do pliku.

Innym parametrem, który należy ustawić wraz z „log_line_prefix” jest „log_timezone”. Ustawienie tego na lokalną strefę czasową serwera zapewni, że zarejestrowane zdarzenia będą łatwe do śledzenia na podstawie ich znacznika czasu, zamiast najpierw konwertować na czas lokalny. W poniższym fragmencie kodu ustawiamy log_timzeone na australijską standardową strefę czasową:

log_timezone = 'Australia/Sydney'

Tylko połączenia dziennika

Dwa parametry kontrolują sposób, w jaki PostgreSQL rejestruje połączenia i rozłączenia klientów. Oba parametry są domyślnie wyłączone. W oparciu o wymagania bezpieczeństwa Twojej organizacji możesz ustawić jeden z nich na 1, a drugi na 0 (chyba że używasz narzędzia takiego jak pgBadger – więcej o tym później).

log_connections = 1
log_disconnections = 0

Ustawienie log_connections na 1 spowoduje zarejestrowanie wszystkich autoryzowanych połączeń, a także próby znajomości. Jest to oczywiście dobre dla audytu bezpieczeństwa:atak typu brute force można łatwo zidentyfikować na podstawie dzienników. Jednak po włączeniu tego ustawienia, obciążone środowisko PostgreSQL z tysiącami, a nawet setkami krótkotrwałych prawidłowych połączeń może zobaczyć, jak plik dziennika jest zalewany.

Niemniej jednak może również zidentyfikować problemy z aplikacją, które w przeciwnym razie mogą nie być oczywiste. Duża liczba prób połączenia z wielu różnych prawidłowych adresów klientów może wskazywać, że instancja wymaga przed sobą modułu równoważenia obciążenia lub usługi puli połączeń. Duża liczba prób połączenia z jednego adresu klienta może wykryć aplikację ze zbyt dużą liczbą wątków, która wymaga pewnego rodzaju ograniczania przepustowości.

Dziennik tylko operacji DDL i DML

Toczy się wiele dyskusji na temat tego, co powinno być zapisywane w logu Postgresa – tj. jaka powinna być wartość parametru „log_statement”. Może mieć trzy wartości:

log_statement = 'off' | 'ddl' | 'mod' | 'all'

Kuszące może być ustawienie tego na „all”, aby przechwycić każdą instrukcję SQL uruchomioną na serwerze, ale w rzeczywistości nie zawsze jest to dobry pomysł.

Zapracowane systemy produkcyjne w większości uruchamiają instrukcje SELECT, czasami tysiące na godzinę. Instancja może działać doskonale, bez żadnych problemów z wydajnością. Ustawienie tego parametru na „all” w takich przypadkach niepotrzebnie obciążałoby demona rejestrującego, ponieważ musi on zapisywać wszystkie te instrukcje w pliku.

To, co chcesz uchwycić, to jakiekolwiek uszkodzenie danych lub zmiany w strukturze bazy danych, które spowodowały pewien rodzaj problemu. Niechciane lub nieautoryzowane zmiany w bazie danych powodują więcej problemów z aplikacjami niż wybieranie danych; dlatego polecam ustawienie tego parametru na „mod”. Przy tym ustawieniu PostgreSQL będzie rejestrować wszystkie zmiany DDL i DML w pliku dziennika.

Jeśli twoja instancja PostgreSQL jest średnio zajęta (dziesiątki zapytań na godzinę), możesz ustawić ten parametr na „all”. Gdy rozwiązujesz problemy z wolno działającymi zapytaniami SELECT lub szukasz nieautoryzowanego dostępu do danych, możesz również tymczasowo ustawić tę opcję na „wszystkie”. Niektóre aplikacje, takie jak pgBadger, również oczekują, że ustawisz to na „all”.

Zapisuj komunikaty „Ostrzeżenia” i w górę

Jeśli parametr „log_statement” decyduje o tym, jaki typ wyciągów będzie rejestrowany, następujące dwa parametry określają, jak szczegółowy będzie komunikat:

log_min_messages
log_min_error_statement

Każde zdarzenie PostgreSQL ma skojarzony poziom wiadomości. Poziom wiadomości może być dowolny, od gadatliwego DEBUG do zwięzłej PANIC. Im niższy poziom, tym bardziej szczegółowa wiadomość. Domyślna wartość parametru „log_min_messages” to „OSTRZEŻENIE”. Zalecam utrzymanie go na tym poziomie, chyba że chcesz, aby wiadomości informacyjne były również rejestrowane.

Parametr „log_min_error_statement” określa, które instrukcje SQL zgłaszające błędy będą rejestrowane. Podobnie jak „log_min_message”, każda instrukcja SQL o poziomie ważności błędu równym lub wyższym od wartości określonej w „log_min_error_statement” będzie rejestrowana. Domyślna wartość to „BŁĄD” i zalecam zachowanie wartości domyślnej.

Zachowaj domyślne parametry czasu trwania dziennika

Następnie mamy następujące dwa parametry:

log_duration
log_min_duration_statement

Parametr „log_duration” przyjmuje wartość logiczną. Gdy jest ustawiony na 1, czas trwania każdego wypełnionego wyciągu będzie rejestrowany. Jeśli jest ustawiony na 0, czas trwania wyciągu nie będzie rejestrowany. Jest to wartość domyślna i zalecam utrzymanie jej na 0, chyba że rozwiązujesz problemy z wydajnością. Obliczanie i rejestrowanie czasu trwania instrukcji sprawia, że ​​silnik bazy danych wykonuje dodatkową pracę (niezależnie od tego, jak mały), a gdy jest ekstrapolowany do setek lub tysięcy zapytań, oszczędności mogą być znaczne.

Na koniec mamy parametr „log_min_duration_statement”. Gdy ten parametr jest ustawiony (bez żadnych jednostek, przyjmuje się go w milisekundach), zostanie zarejestrowany czas trwania dowolnej instrukcji równy lub dłuższy niż wartość parametru. Ustawienie wartości tego parametru na 0 spowoduje zarejestrowanie czasu trwania wszystkich wypełnionych wyciągów. Ustawienie tego na -1 spowoduje wyłączenie rejestrowania czasu trwania wyciągu. Jest to wartość domyślna i zalecam jej zachowanie.

Jedynym przypadkiem, w którym chcesz ustawić ten parametr na 0, jest utworzenie planu bazowego wydajności dla często uruchamianych zapytań. Pamiętaj jednak, że jeśli parametr „log_statement” jest ustawiony, protokoły, które są rejestrowane, nie będą powtarzane w komunikatach dziennika pokazujących czas trwania. Musisz więc załadować pliki dziennika do tabeli bazy danych, a następnie połączyć wartości identyfikatora procesu i identyfikatora sesji z przedrostków wiersza dziennika, aby zidentyfikować powiązane instrukcje i czas ich trwania.

Niezależnie od środków, gdy masz już linię bazową dla każdego często uruchamianego zapytania, możesz ustawić parametr „log_min_duration_statement” na najwyższą z wartości linii bazowej. Teraz każde zapytanie działające dłużej niż najwyższa wartość bazowa będzie kandydatem do dostrojenia.

Zachowaj domyślne szczegółowości komunikatów o błędach

Parametr „log_error_verbosity” może mieć trzy możliwe wartości:

log_error_verbosity = terse | standard | verbose

Ten parametr kontroluje ilość informacji, które PostgreSQL zapisze dla każdego zdarzenia zapisanego w pliku dziennika. O ile nie debugujesz aplikacji bazodanowej, ten parametr najlepiej jest zachować jako „domyślny”. Tryb szczegółowy przyda się, gdy trzeba przechwycić nazwę pliku lub funkcji oraz numer wiersza, który wygenerował błąd. Ustawienie tego na „zwięzły” spowoduje wstrzymanie rejestrowania zapytania, co również może nie być przydatne.

Znajdź zasadę rotacji logów, która działa dla Twojego Użyj przypadku

Zalecam tworzenie zasad rotacji logów w oparciu o rozmiar lub wiek pliku logu, ale nie jedno i drugie. Dwa parametry konfiguracyjne PostgreSQL określają sposób archiwizacji starych i tworzenia nowych:

log_rotation_age = <number of minutes>
log_rotation_size = <number of kilobytes>

Domyślna wartość „log_rotration_age” to 24 godziny, a domyślna wartość „log_rotation_size” to 10 megabajtów.

W większości przypadków stosowanie zasad rotacji rozmiarów nie zawsze gwarantuje, że ostatni komunikat w zarchiwizowanym pliku dziennika jest w całości zawarty tylko w tym pliku.

Jeśli „log_rotation_age” zostanie zachowana domyślna wartość 24 godzin, każdy plik można łatwo zidentyfikować i indywidualnie zbadać, ponieważ każdy plik będzie zawierał zdarzenia z całego dnia. Jednak to również nie gwarantuje, że każdy plik będzie samodzielną jednostką dzienników z ostatnich 24 godzin. Czasami wykonanie wolno działającego zapytania może zająć więcej niż 24 godziny; zdarzenia mogą mieć miejsce po zamknięciu starego pliku i wygenerowaniu nowego. Może się tak zdarzyć podczas nocnego zadania wsadowego, w wyniku czego niektóre części zapytań są zapisywane w jednym pliku, a reszta w innym.

Zalecamy znalezienie okresu rotacji logów, który będzie odpowiedni dla Twojego przypadek użycia. Sprawdź różnicę czasu między dwoma kolejnymi okresami najniższej aktywności (na przykład między jedną sobotą a następną). Następnie możesz ustawić wartość „log_rotation_age” na tę różnicę czasu i podczas jednego z tych okresów ponownie uruchomić usługę PostgreSQL. W ten sposób PostgreSQL zmieni bieżący plik dziennika, gdy nastąpi następny okres przerwy. Jeśli jednak musisz ponownie uruchomić usługę między tymi okresami, rotacja dzienników zostanie ponownie przekrzywiona. Będziesz musiał wtedy powtórzyć ten proces. Ale jak wiele innych rzeczy w PostgreSQL, metoda prób i błędów będzie dyktować najlepszą wartość. Ponadto, jeśli używasz narzędzia do zarządzania dziennikami, wiek lub rozmiar rotacji dzienników nie będzie miał znaczenia, ponieważ agent menedżera dzienników będzie pobierał każde zdarzenie z dodawanego pliku.

Używaj narzędzi takich jak pgBadger

pgBadger to potężny analizator logów PostgreSQL, który może tworzyć bardzo przydatne informacje z plików logów Postgres. Jest to narzędzie typu open source napisane w Perlu, które zajmuje bardzo mało miejsca na maszynie, na której działa. Narzędzie jest uruchamiane z wiersza poleceń i zawiera wiele opcji. Jako dane wejściowe pobierze jeden lub więcej dzienników i może wygenerować raport HTML ze szczegółowymi statystykami na temat:

• Najczęściej oczekujące zapytania.
• Zapytania generujące większość plików tymczasowych lub największe pliki tymczasowe
• Najwolniej działające zapytania
• Średni czas trwania zapytania
• Najczęściej uruchamiane zapytania
• Najczęstsze błędy w zapytaniach
• Użytkownicy i aplikacje uruchamiające zapytania
• Statystyki punktów kontrolnych.
• Statystyki autoodkurzania i autoanalizy.
• Statystyki blokowania
• Zdarzenia błędów (panika, fatalne, błąd i ostrzeżenie).
• Profile połączeń i sesji (według bazy danych, użytkownika, aplikacji)
• Profile sesji
• Profile zapytań (typy zapytań, zapytania według bazy danych/aplikacji)
• Statystyki we/wy
• itd.

Jak wspomniałem wcześniej, niektóre parametry konfiguracyjne związane z dziennikiem muszą być włączone, aby przechwytywać wszystkie zdarzenia dziennika, aby pgBadger mógł skutecznie analizować te dzienniki. Ponieważ może to generować duże pliki dziennika z wieloma zdarzeniami, pgBadger powinien być używany tylko do tworzenia testów porównawczych lub rozwiązywania problemów z wydajnością. Po wygenerowaniu szczegółowych dzienników parametry konfiguracyjne można przywrócić do ich oryginalnych wartości. Do ciągłej analizy logów najlepiej jest użyć dedykowanej aplikacji do zarządzania logami.

Jeśli wygodniej jest robić rzeczy w wierszu poleceń i korzystać z widoków systemowych, chciałbyś użyć pg_stat_statements. W rzeczywistości powinno to być włączone w każdej produkcyjnej instalacji PostgreSQL.

pg_stat_statements to rozszerzenie PostgreSQL z domyślną instalacją. Aby go włączyć, parametr konfiguracyjny „shared_preload_libraries” powinien mieć jako jedną z wartości pg_stat_statements. Można go następnie zainstalować jak każde inne rozszerzenie za pomocą polecenia „UTWÓRZ ROZSZERZENIE”. Rozszerzenie tworzy widok pg_stat_statement, który dostarcza cennych informacji związanych z zapytaniami.

Użyj aplikacji do zarządzania logami, aby uzyskać wgląd

Na rynku dostępnych jest wiele narzędzi do zarządzania dziennikami, a większość organizacji korzysta obecnie z jednego lub więcej. Niezależnie od tego, jakie narzędzie jest na miejscu, zalecam korzystanie z niego do zbierania i zarządzania dziennikami PostgreSQL.

Jest kilka powodów:

O wiele łatwiej jest analizować, analizować i odfiltrowywać szumy z plików dziennika za pomocą zautomatyzowanego narzędzia. Czasami zdarzenie może obejmować wiele plików dziennika w zależności od czasu trwania zdarzenia oraz wieku lub rozmiaru rotacji dziennika. Posiadanie menedżera dziennika znacznie ułatwia prezentowanie tych informacji jako całości.

Dzisiejsze rozwiązania do zarządzania logami zazwyczaj mają wbudowaną możliwość analizowania logów PostgreSQL. Niektóre są również wyposażone w pulpity nawigacyjne, które mogą pokazywać najpopularniejsze metryki wyodrębnione z tych dzienników.

Większość nowoczesnych aplikacji do zarządzania dziennikami oferuje również zaawansowane funkcje wyszukiwania, filtrowania, dopasowywania wzorców, korelacji zdarzeń i analizy trendów z wykorzystaniem sztucznej inteligencji. To, co nie jest widoczne dla zwykłych oczu, można łatwo uwidocznić za pomocą tych narzędzi.

Wreszcie, użycie menedżera dzienników do przechowywania dzienników PostgreSQL będzie również oznaczać, że zdarzenia zostaną zapisane dla potomności, nawet jeśli oryginalne pliki zostaną usunięte przypadkowo lub złośliwie.

Chociaż istnieją oczywiste zalety korzystania z aplikacji do zarządzania dziennikami, wiele organizacji ma ograniczenia dotyczące gdzie ich dzienniki mogą żyć. Jest to typowy przypadek w przypadku rozwiązań opartych na SaaS, w których dzienniki są często zapisywane poza granicami geograficznymi organizacji – coś, co może nie być zgodne z wymogami prawnymi.

W takich przypadkach polecam wybrać dostawcę z lokalnym centrum danych – jeśli to możliwe – lub korzystającego z samozarządzającego się menedżera logów hostowanego w sieci organizacji, takiego jak stos ELK.

Końcowe słowa

Logi serwera PostgreSQL mogą być kopalnią informacji, jeśli są odpowiednio skonfigurowane. Sztuczka polega na ustaleniu, co i ile należy rejestrować, a co ważniejsze, sprawdzić, czy dzienniki mogą w razie potrzeby dostarczać właściwych informacji. Będzie to kwestia prób i błędów, ale to, o czym tu dzisiaj omówiłem, powinno dać całkiem przyzwoity początek. Jak powiedziałem na początku, byłbym bardziej niż szczęśliwy mogąc usłyszeć o twoich doświadczeniach z konfigurowaniem logowania PostgreSQL w celu uzyskania optymalnych wyników.