Het beste uit PostgreSQL-logboeken halen

Als een modern RDBMS wordt PostgreSQL geleverd met veel parameters voor fijnafstemming. Een van de aandachtspunten is hoe PostgreSQL zijn activiteiten moet loggen. Logboekregistratie wordt vaak over het hoofd gezien in het databasebeheer van Postgres, en als het niet wordt genegeerd, meestal verkeerd ingesteld. Dit gebeurt omdat het doel van het loggen meestal onduidelijk is. Natuurlijk is de fundamentele reden voor het loggen bekend, maar wat soms ontbreekt, is een begrip van hoe de logs zullen worden gebruikt.

De logboekvereisten van elke organisatie zijn uniek en daarom zal ook de manier waarop PostgreSQL-logboekregistratie moet worden geconfigureerd, verschillen. Wat een financiële dienstverlener moet vastleggen in zijn databaselogboeken, zal anders zijn dan wat een bedrijf dat zich bezighoudt met kritieke gezondheidsinformatie moet vastleggen. En in sommige gevallen kunnen ze ook op elkaar lijken.

In dit artikel zal ik enkele fundamentele praktijken behandelen om het beste uit PostgreSQL-logboeken te halen. Deze blog is geen hard en snel regelboek; lezers zijn meer dan welkom om hun mening te delen in de commentarensectie. Om er echter het beste uit te halen, vraag ik de lezer om na te denken over hoe ze hun PostgreSQL-databaseserverlogboeken willen gebruiken:

Reden voor wettelijke naleving waar specifieke informatie moet worden vastgelegd
Beveiligingsaudit waarbij specifieke gebeurtenisdetails aanwezig moeten zijn
Problemen oplossen met prestaties waar vragen en hun parameters moeten worden vastgelegd
Dagelijkse operationele ondersteuning waarbij een bepaald aantal meetwaarden moet worden gecontroleerd

Dat gezegd hebbende, laten we beginnen.

Maak geen handmatige wijzigingen aan postgresql.conf

Alle wijzigingen in het postgresql.conf-bestand moeten worden gemaakt met behulp van een configuratiebeheersysteem zoals Puppet, Ansible of Chef. Dit zorgt ervoor dat wijzigingen traceerbaar zijn en indien nodig veilig kunnen worden teruggedraaid naar een eerdere versie. Dit geldt wanneer u wijzigingen aanbrengt in de logparameters.

DBA's maken vaak meerdere kopieën van het bestand postgresql.conf, elk met iets andere parameters, elk voor een ander doel. Het handmatig beheren van verschillende configuratiebestanden is een omslachtige taak, zo niet gevoelig voor fouten. Aan de andere kant kan een configuratiebeheersysteem worden gemaakt om verschillende versies van het bestand postgresql.conf te hernoemen en te gebruiken op basis van een eraan doorgegeven parameter. Deze parameter bepaalt het doel van de huidige versie. Wanneer de behoefte is voltooid, kan het oude configuratiebestand worden teruggezet door dezelfde invoerparameter te wijzigen.

Als u bijvoorbeeld alle instructies wilt loggen die op uw PostgreSQL-instantie worden uitgevoerd, kan een configuratiebestand met de parameterwaarde "log_statement=all" worden gebruikt. Als het niet nodig is om alle verklaringen vast te leggen – misschien na een probleemoplossingsoefening – kan het vorige configuratiebestand worden hersteld.

Gebruik aparte logbestanden voor PostgreSQL

Ik raad aan om de native logging-collector van PostgreSQL tijdens normale bewerkingen in te schakelen. Om PostgreSQL native logboekregistratie in te schakelen, stelt u de volgende parameter in op aan:

logging_collector = on

Er zijn twee redenen voor:

Ten eerste kan het besturingssysteem in drukke systemen PostgreSQL-berichten niet consequent opnemen in syslog (uitgaande van een op nix gebaseerde installatie) en vaak berichten laten vallen. Met native PostgreSQL-logging zorgt een aparte daemon voor het vastleggen van de gebeurtenissen. Als PostgreSQL bezig is, stelt dit proces het schrijven naar de logbestanden uit, zodat de querythreads kunnen worden voltooid. Dit kan het hele systeem blokkeren totdat de loggebeurtenis is geschreven. Het is daarom handig om minder uitgebreide berichten in het logboek op te nemen (zoals we later zullen zien) en verkorte voorvoegsels voor de logregel te gebruiken.

Ten tweede - en zoals we later zullen zien - moeten logboeken worden verzameld, geparseerd, geïndexeerd en geanalyseerd met een hulpprogramma voor logbeheer. Als PostgreSQL zijn gebeurtenissen in syslog vastlegt, betekent dit dat er een extra laag van filtering en patroonovereenkomst moet worden gemaakt in het gedeelte Logbeheer om alle "ruisberichten" eruit te filteren. Toegewijde logbestanden kunnen door de meeste tools eenvoudig worden geparseerd en geïndexeerd voor gebeurtenissen.

Stel de logbestemming in op stderr

Laten we eens kijken naar de parameter "log_destination". Het kan vier waarden hebben:

log_destination = stderr | syslog | csv | eventlog

Tenzij er een goede reden is om logboekgebeurtenissen op te slaan in door komma's gescheiden indeling of gebeurtenislogboek in Windows, raad ik aan deze parameter in te stellen op stderr. Dit komt omdat met een CSV-bestandsbestemming een aangepaste parameterwaarde "log_line_prefix" geen effect heeft, en toch kan het voorvoegsel waardevolle informatie bevatten.

Aan de andere kant kan een CSV-logboek eenvoudig worden geïmporteerd in een databasetabel en later worden opgevraagd met behulp van standaard SQL. Sommige PostgreSQL-gebruikers vinden het handiger dan het verwerken van onbewerkte logbestanden. Zoals we later zullen zien, kunnen moderne Log Management-oplossingen native PostgreSQL-logboeken ontleden en er automatisch zinvolle inzichten uit creëren. Met CSV moet de rapportage en visualisatie handmatig door de gebruiker worden gedaan.

Uiteindelijk komt het neer op jouw keuze. Als u vertrouwd bent met het maken van uw eigen pijplijn voor gegevensopname om de CSV-logboeken in databasetabellen te laden, de gegevens op te schonen en te transformeren en aangepaste rapporten te maken die passen bij uw zakelijke behoeften, zorg er dan voor dat de "log_destination" is ingesteld op CSV.

Gebruik zinvolle namen van logbestanden

Wanneer PostgreSQL-logbestanden lokaal worden opgeslagen, lijkt het misschien niet nodig om een naamgevingsstijl te volgen. De standaard bestandsnaamstijl is "postgresql-%Y-%m-%d_%H%M%S.log" voor niet-CSV-geformatteerde logbestanden, wat in de meeste gevallen voldoende is.

Naamgeving wordt belangrijk wanneer u logbestanden opslaat van meerdere servers naar een centrale locatie zoals een speciale logserver, een gekoppeld NFS-volume of een S3-bucket. Ik raad aan om in dat geval twee parameters te gebruiken:

log_directory
log_filename

Om logbestanden van meerdere instanties op één plaats op te slaan, maakt u eerst een aparte directoryhiërarchie voor elke instantie. Dit kan ongeveer het volgende zijn:

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

De "log_directory" van elke PostgreSQL-instantie kan vervolgens worden verwezen naar de bijbehorende map.

Elke instantie kan dan dezelfde parameterwaarde "log_filename" gebruiken. De standaardwaarde zal een bestand maken zoals

postgresql_2020-08-25_2359.log

Om een meer betekenisvolle naam te gebruiken, stelt u de "log_filename" in op zoiets als dit:

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

De logbestanden krijgen dan de naam:

postgresql_zaterdag-23-augustus_2230

Gebruik een zinvol voorvoegsel voor de logregel

PostgreSQL-logregelprefixen kunnen naast het eigenlijke bericht zelf de meest waardevolle informatie bevatten. De Postgres-documentatie toont verschillende escape-tekens voor de configuratie van het voorvoegsel van loggebeurtenissen. Deze escape-reeksen worden tijdens runtime vervangen door verschillende statuswaarden. Sommige toepassingen, zoals pgBadger, verwachten een specifiek voorvoegsel van de logregel.

Ik raad aan om de volgende informatie in het voorvoegsel op te nemen:

De tijd van de gebeurtenis (zonder milliseconden):%t
Klantnaam of IP-adres op afstand:%h
Gebruikersnaam:%u
Toegang tot database:%d
Applicatienaam:%a
Proces-ID:%p
Uitvoer van niet-sessieproces beëindigen:%q
Het logregelnummer voor elke sessie of elk proces, beginnend bij 1:%l

Om te begrijpen waar elk veld in het voorvoegsel over gaat, kunnen we een kleine letterlijke tekenreeks voor het veld toevoegen. De proces-ID-waarde kan dus worden voorafgegaan door de letterlijke "PID=", de databasenaam kan worden voorafgegaan door "db=" enz. Hier is een voorbeeld:

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

Afhankelijk van waar de gebeurtenis vandaan komt, toont het voorvoegsel van de logregel verschillende waarden. Zowel achtergrondprocessen als gebruikersprocessen zullen hun berichten opnemen in het logbestand. Voor systeemprocessen heb ik %q gespecificeerd, dat alle tekst na de proces-ID (%p) onderdrukt. Elke andere sessie toont de databasenaam, gebruikersnaam, klantadres, applicatienaam en een genummerde regel voor elke gebeurtenis.

Ook heb ik een enkele spatie toegevoegd na het voorvoegsel van de logregel. Deze ruimte scheidt het voorvoegsel van de loggebeurtenis van het eigenlijke gebeurtenisbericht. Het hoeft geen spatie te zijn - zoiets als een dubbele dubbele punt (::), koppelteken (-) of een ander betekenisvol scheidingsteken kan worden gebruikt.

Stel ook de parameter "log_hostname" in op 1:

log_hostname = 1

Zonder dit wordt alleen het IP-adres van de client weergegeven. In productiesystemen is dit meestal het adres van de proxy, load balancer of de pooler voor verbindingen. Tenzij u de IP-adressen van deze systemen uit uw hoofd kent, kan het de moeite waard zijn om hun hostnamen te loggen. De DNS-lookup voegt echter ook extra tijd toe voor de logging-daemon om naar het bestand te schrijven.

Een andere parameter die samen met de "log_line_prefix" moet worden ingesteld, is "log_timezone". Als u dit instelt op de lokale tijdzone van de server, zorgt u ervoor dat gelogde gebeurtenissen gemakkelijk te volgen zijn vanaf hun tijdstempel in plaats van eerst naar de lokale tijd te converteren. In het onderstaande codefragment stellen we de log_timzeone in op Australian Eastern Standard Timezone:

log_timezone = 'Australia/Sydney'

Alleen verbindingen loggen

Twee parameters bepalen hoe PostgreSQL clientverbindingen en verbroken verbindingen registreert. Beide parameters zijn standaard uitgeschakeld. Op basis van de beveiligingsvereisten van uw organisatie wilt u misschien een van deze instellen op 1 en de andere op 0 (tenzij u een tool zoals pgBadger gebruikt - daarover later meer).

log_connections = 1
log_disconnections = 0

Door log_connections in te stellen op 1 worden alle geautoriseerde verbindingen geregistreerd, evenals pogingen verbindingen. Dit is natuurlijk goed voor beveiligingsaudits:een brute force-aanval kan gemakkelijk worden geïdentificeerd aan de hand van de logboeken. Als deze instelling echter is ingeschakeld, kan het logbestand in een drukke PostgreSQL-omgeving met duizenden of zelfs honderden kortstondige geldige verbindingen worden overspoeld.

Desalniettemin kan het ook toepassingsproblemen identificeren die anders misschien niet duidelijk zijn. Een groot aantal verbindingspogingen van veel verschillende geldige clientadressen kan erop wijzen dat de instantie een load balancer of verbindingspooling-service nodig heeft. Een groot aantal verbindingspogingen vanaf een enkel clientadres kan een toepassing aan het licht brengen met te veel threads die op een of andere manier moeten worden beperkt.

Alleen DDL- en DML-bewerkingen registreren

Er is veel discussie over wat er in het Postgres-logboek moet worden vastgelegd, d.w.z. wat de waarde van de parameter "log_statement" moet zijn. Het kan drie waarden hebben:

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

Het kan verleidelijk zijn om dit in te stellen op "all" om elke SQL-instructie die op de server wordt uitgevoerd vast te leggen, maar in werkelijkheid is dit misschien niet altijd een goed idee.

Drukke productiesystemen voeren meestal SELECT-instructies uit, soms duizenden per uur. De instantie werkt mogelijk perfect, zonder prestatieproblemen. Het instellen van deze parameter op "all" in dergelijke gevallen zou de logging-daemon onnodig belasten, aangezien deze al die instructies naar het bestand moet schrijven.

Wat u echter wilt vastleggen, zijn gegevensbeschadiging of wijzigingen in de databasestructuur die een probleem hebben veroorzaakt. Ongewenste of ongeautoriseerde databasewijzigingen veroorzaken meer toepassingsproblemen dan het selecteren van gegevens; daarom raad ik aan om deze parameter op "mod" te zetten. Met deze instelling zal PostgreSQL alle DDL- en DML-wijzigingen in het logbestand opnemen.

Als uw PostgreSQL-instantie matig bezet is (tientallen zoekopdrachten per uur), kunt u deze parameter gerust op "all" zetten. Wanneer u problemen met traag lopende SELECT-query's oplost of ongeautoriseerde toegang tot gegevens zoekt, kunt u dit ook tijdelijk op "alles" instellen. Sommige toepassingen, zoals pgBadger, verwachten ook dat u dit instelt op "alle".

Log "Waarschuwingsberichten" en hoger

Als de parameter "log_statement" bepaalt welk type statements worden opgenomen, bepalen de volgende twee parameters hoe gedetailleerd het bericht zal zijn:

log_min_messages
log_min_error_statement

Elke PostgreSQL-gebeurtenis heeft een bijbehorend berichtniveau. Het berichtniveau kan van alles zijn, van uitgebreide DEBUG tot beknopte PANIEK. Hoe lager het niveau, hoe uitgebreider de boodschap. De standaardwaarde voor de parameter "log_min_messages" is "WARNING". Ik raad aan om het op dit niveau te houden, tenzij je ook informatieve berichten wilt loggen.

De parameter "log_min_error_statement" bepaalt welke fout bij het genereren van SQL-statements wordt vastgelegd. Net als "log_min_message", wordt elke SQL-instructie met een fouternstniveau dat gelijk is aan of hoger is dan de waarde die is opgegeven in "log_min_error_statement" vastgelegd. De standaardwaarde is "ERROR", en ik raad aan om de standaardwaarde te behouden.

Houd de logduur op standaard

Dan hebben we de volgende twee parameters:

log_duration
log_min_duration_statement

De parameter "log_duration" heeft een booleaanse waarde. Als deze is ingesteld op 1, wordt de duur van elke ingevulde verklaring gelogd. Indien ingesteld op 0, wordt de duur van de instructie niet gelogd. Dit is de standaardwaarde en ik raad aan deze op 0 te houden, tenzij u prestatieproblemen oplost. Door de duur van de instructie te berekenen en vast te leggen, doet de database-engine extra werk (hoe klein ook), en wanneer deze wordt geëxtrapoleerd naar honderden of duizenden zoekopdrachten, kunnen de besparingen aanzienlijk zijn.

Ten slotte hebben we de parameter "log_min_duration_statement". Wanneer deze parameter is ingesteld (zonder eenheden, wordt dit beschouwd als milliseconden), wordt de duur van een instructie die gelijk is aan of langer duurt dan de parameterwaarde gelogd. Als u deze parameterwaarde op 0 instelt, wordt de duur van alle voltooide instructies vastgelegd. Als u dit instelt op -1, wordt het loggen van de duur van de instructie uitgeschakeld. Dit is de standaardwaarde en ik raad aan om deze zo te houden.

De enige keer dat u deze parameter op 0 wilt instellen, is wanneer u een prestatiebasislijn wilt maken voor vaak uitgevoerde query's. Houd er echter rekening mee dat als de parameter "log_statement" is ingesteld, de gelogde instructies niet worden herhaald in de logberichten die de duur weergeven. U moet dus de logbestanden in een databasetabel laden en vervolgens de Process ID en Session ID-waarden van de logregelprefixen samenvoegen om gerelateerde statements en hun duur te identificeren.

Wat de middelen ook zijn, als u eenmaal een basislijn hebt voor elke vaak uitgevoerde query, kunt u de parameter "log_min_duration_statement" instellen op de hoogste van de basislijnwaarden. Nu komt elke zoekopdracht die langer duurt dan de hoogste basislijnwaarde in aanmerking voor finetuning.

Houd de breedsprakigheid van de foutmelding op standaard

De parameter "log_error_verbosity" kan drie mogelijke waarden hebben:

log_error_verbosity = terse | standard | verbose

Deze parameter bepaalt de hoeveelheid informatie die PostgreSQL zal vastleggen voor elke gebeurtenis die in het logbestand is vastgelegd. Tenzij u een databasetoepassing debugt, kunt u deze parameter het beste op "standaard" houden. De uitgebreide modus is handig wanneer u de bestands- of functienaam en het regelnummer daar moet vastleggen dat de fout heeft gegenereerd. Als u dit instelt op "kort" zal het loggen van de zoekopdracht onderdrukken, wat ook niet handig kan zijn.

Vind een logboekrotatiebeleid dat werkt voor uw Gebruiksvoorbeeld

Ik raad aan om een logboekrotatiebeleid te maken op basis van de grootte of de leeftijd van het logbestand, maar niet beide. Twee PostgreSQL-configuratieparameters bepalen hoe oude logs worden gearchiveerd en hoe nieuwe logs worden aangemaakt:

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

De standaardwaarde voor "log_rotration_age" is 24 uur en de standaardwaarde voor "log_rotation_size" is 10 megabytes.

In de meeste gevallen garandeert het hebben van een formaatrotatiebeleid niet altijd dat het laatste logbericht in het gearchiveerde logbestand volledig in dat bestand zit.

Als de "log_rotation_age" op de standaardwaarde van 24 uur wordt gehouden, kan elk bestand gemakkelijk worden geïdentificeerd en afzonderlijk worden bekeken, aangezien elk bestand een dag aan gebeurtenissen zal bevatten. Dit garandeert echter ook niet dat elk bestand een op zichzelf staande eenheid van logboeken van de afgelopen 24 uur zal zijn. Soms kan het meer dan 24 uur duren voordat een traag presterende zoekopdracht is voltooid; gebeurtenissen kunnen plaatsvinden wanneer het oude bestand wordt gesloten en het nieuwe wordt gegenereerd. Dit kan het geval zijn tijdens een nachtelijke batchtaak, waardoor sommige delen van de zoekopdrachten in het ene bestand worden vastgelegd en de rest in een ander.

Onze aanbeveling is om een logboekrotatieperiode te vinden die werkt voor uw gebruiksgeval. Controleer het tijdsverschil tussen twee opeenvolgende perioden met de minste activiteit (bijvoorbeeld tussen de ene zaterdag en de volgende). U kunt vervolgens de waarde "log_rotation_age" instellen op dat tijdsverschil en tijdens een van die perioden de PostgreSQL-service opnieuw starten. Op die manier zal PostgreSQL het huidige logbestand roteren wanneer de volgende rustperiode plaatsvindt. Als u de service echter tussen deze perioden opnieuw moet opstarten, wordt de logrotatie opnieuw scheefgetrokken. U zult dit proces dan moeten herhalen. Maar zoals bij veel andere dingen in PostgreSQL, zal vallen en opstaan de beste waarde bepalen. Als u een hulpprogramma voor logbeheer gebruikt, maakt de leeftijd of grootte van de logrotatie ook niet uit, omdat de logmanager-agent elke gebeurtenis uit het bestand opneemt zodra deze wordt toegevoegd.

Gebruik tools zoals pgBadger

pgBadger is een krachtige PostgreSQL-logboekanalysator die zeer nuttige inzichten kan creëren uit Postgres-logboekbestanden. Het is een open-source tool geschreven in Perl met een zeer kleine footprint in de machine waarop het draait. De tool wordt uitgevoerd vanaf de opdrachtregel en wordt geleverd met een groot aantal opties. Het heeft een of meer logs nodig als invoer en kan een HTML-rapport produceren met gedetailleerde statistieken over:

Meest vaak wachtende vragen.
Query's die de meeste tijdelijke bestanden of de grootste tijdelijke bestanden genereren
Langzaamst lopende zoekopdrachten
Gemiddelde duur van zoekopdrachten
Meest uitgevoerde zoekopdrachten
Meest voorkomende fouten in zoekopdrachten
Gebruikers en applicaties die zoekopdrachten uitvoeren
Checkpoint-statistieken.
Autovacuüm en automatische analyse van statistieken.
Statistieken vergrendelen
Foutgebeurtenissen (paniek, fataal, fout en waarschuwing).
Verbindings- en sessieprofielen (per database, gebruiker, applicatie)
Sessieprofielen
Queryprofielen (querytypes, queries per database/toepassing)
I/O-statistieken
enz.

Zoals ik eerder al zei, moeten sommige log-gerelateerde configuratieparameters worden ingeschakeld om alle loggebeurtenissen vast te leggen, zodat pgBadger die logs effectief kan analyseren. Aangezien dit grote logbestanden met veel gebeurtenissen kan opleveren, mag pgBadger alleen worden gebruikt om benchmarks te maken of prestatieproblemen op te lossen. Zodra de gedetailleerde logbestanden zijn gegenereerd, kunnen de configuratieparameters worden teruggezet naar hun oorspronkelijke waarden. Voor continue loganalyse kunt u het beste een speciale toepassing voor logbeheer gebruiken.

Als u zich meer op uw gemak voelt om dingen in de opdrachtprompt te doen en gebruik te maken van systeemweergaven, zou u pg_stat_statements willen gebruiken. In feite zou dit moeten worden ingeschakeld in elke PostgreSQL-productieinstallatie.

pg_stat_statements is een PostgreSQL-extensie en nu met de standaardinstallatie. Om dit in te schakelen, moet de configuratieparameter "shared_preload_libraries" pg_stat_statements als een van zijn waarden hebben. Het kan vervolgens worden geïnstalleerd zoals elke andere extensie met behulp van de opdracht "EXTENSIE MAKEN". De extensie creëert de pg_stat_statement-weergave die waardevolle query-gerelateerde informatie biedt.

Gebruik een toepassing voor logbeheer om inzicht te krijgen

Er zijn veel hulpprogramma's voor logbeheer op de markt en de meeste organisaties gebruiken er tegenwoordig een of meer. Welke tool er ook is, ik raad aan deze te gebruiken om PostgreSQL-logboeken te verzamelen en te beheren.

Er zijn een paar redenen voor:

Het is veel gemakkelijker om ruis uit logbestanden te ontleden, te analyseren en uit te filteren met een geautomatiseerde tool. Soms kan een gebeurtenis meerdere logbestanden omvatten op basis van de duur van de gebeurtenis en de leeftijd of grootte van de logrotatie. Het hebben van een logmanager maakt het veel eenvoudiger om deze informatie in zijn geheel te presenteren.

Logboekbeheeroplossingen worden tegenwoordig meestal geleverd met een ingebouwde mogelijkheid om PostgreSQL-logboeken te ontleden. Sommige worden ook geleverd met dashboards die de meest voorkomende statistieken kunnen weergeven die uit deze logboeken zijn geëxtraheerd.

De meeste moderne toepassingen voor logbeheer bieden ook krachtige zoek-, filter-, patroonafstemmings-, gebeurteniscorrelatie en AI-enabled trendanalysefuncties. Wat voor gewone ogen niet zichtbaar is, kan met deze hulpmiddelen gemakkelijk duidelijk worden gemaakt.

Ten slotte betekent het gebruik van een logmanager om PostgreSQL-logboeken op te slaan ook dat de gebeurtenissen voor het nageslacht worden bewaard, zelfs als de originele bestanden per ongeluk of kwaadwillig worden verwijderd.

Hoewel er duidelijke voordelen zijn aan het gebruik van een toepassing voor logbeheer, hebben veel organisaties beperkingen met betrekking tot waar hun logs kunnen leven. Dit is een typisch geval van op SaaS gebaseerde oplossingen waarbij logboeken vaak buiten de geografische grens van een organisatie worden opgeslagen - iets dat mogelijk niet voldoet aan de wettelijke vereisten.

In dergelijke gevallen raad ik aan een leverancier te kiezen met een lokale datacenteraanwezigheid - indien mogelijk - of een zelfbeheerde logmanager te gebruiken die wordt gehost in het netwerk van de organisatie, zoals een ELK-stack.

Laatste woorden

PostgreSQL-serverlogboeken kunnen een goudmijn aan informatie zijn als ze op de juiste manier zijn geconfigureerd. De truc is om te bepalen wat je moet loggen en hoeveel je moet loggen, en nog belangrijker, om te testen of de logs de juiste informatie kunnen leveren wanneer dat nodig is. Het zal een kwestie van vallen en opstaan zijn, maar wat ik hier vandaag heb besproken, zou een behoorlijk goede start moeten geven. Zoals ik aan het begin al zei, zou ik graag horen over uw ervaring met het configureren van PostgreSQL-logboekregistratie voor optimale resultaten.