Als modernes RDBMS verfügt PostgreSQL über viele Parameter zur Feinabstimmung. Einer der zu berücksichtigenden Bereiche ist, wie PostgreSQL seine Aktivitäten protokollieren sollte. Die Protokollierung wird in der Postgres-Datenbankverwaltung oft übersehen und, wenn sie nicht ignoriert wird, in der Regel falsch eingestellt. Dies hängt davon ab, dass der Zweck der Protokollierung meistens unklar ist. Natürlich ist der Hauptgrund für die Protokollierung bekannt, aber was manchmal fehlt, ist ein Verständnis dafür, wie die Protokolle verwendet werden.
Die Protokollierungsanforderungen jeder Organisation sind unique, und daher wird auch die Art und Weise, wie die PostgreSQL-Protokollierung konfiguriert werden sollte, unterschiedlich sein. Was ein Finanzdienstleistungsunternehmen in seinen Datenbankprotokollen erfassen muss, unterscheidet sich von dem, was ein Unternehmen, das sich mit kritischen Gesundheitsinformationen befasst, aufzeichnen muss. Und in einigen Fällen können sie auch ähnlich sein.
In diesem Artikel werde ich einige grundlegende Praktiken behandeln, um das Beste aus PostgreSQL-Protokollen herauszuholen. Dieser Blog ist kein hartes und schnelles Regelbuch; Die Leser sind herzlich eingeladen, ihre Gedanken zu teilen. Um den besten Nutzen daraus zu ziehen, bitte ich den Leser, darüber nachzudenken, wie er seine PostgreSQL-Datenbankserverprotokolle verwenden möchte:
- Grund für die Einhaltung gesetzlicher Vorschriften, wenn bestimmte Informationen erfasst werden müssen
- Sicherheitsüberwachung, bei der spezifische Details vorhanden sein müssen
- Performance-Troubleshooting, bei der Abfragen und deren Parameter aufgezeichnet werden sollen
- Tägliche Betriebsunterstützung, bei der eine bestimmte Anzahl von Metriken überwacht werden soll
Fangen wir damit an.
Nehmen Sie keine manuellen Änderungen an postgresql.conf vor
Alle Änderungen in der Datei postgresql.conf sollten mit einem Konfigurationsmanagementsystem wie Puppet, Ansible oder Chef vorgenommen werden. Dadurch wird sichergestellt, dass Änderungen nachvollziehbar sind und bei Bedarf sicher auf eine frühere Version zurückgesetzt werden können. Dies gilt, wenn Sie Änderungen an den Protokollierungsparametern vornehmen.
DBAs erstellen häufig mehrere Kopien der Datei postgresql.conf mit jeweils leicht unterschiedlichen Parametern für einen anderen Zweck. Die manuelle Verwaltung verschiedener Konfigurationsdateien ist eine umständliche Aufgabe, wenn sie nicht fehleranfällig ist. Auf der anderen Seite kann ein Konfigurationsmanagementsystem so angelegt werden, dass es verschiedene Versionen der Datei postgresql.conf basierend auf einem an sie übergebenen Parameter umbenennt und verwendet. Dieser Parameter bestimmt den Zweck der aktuellen Version. Wenn der Bedarf abgeschlossen ist, kann die alte Konfigurationsdatei durch Ändern desselben Eingabeparameters zurückgesetzt werden.
Wenn Sie beispielsweise alle Anweisungen protokollieren möchten, die auf Ihrer PostgreSQL-Instanz ausgeführt werden, kann eine Konfigurationsdatei mit dem Parameterwert "log_statement=all" verwendet werden. Wenn nicht alle Anweisungen aufgezeichnet werden müssen – vielleicht nach einer Fehlerbehebung – kann die vorherige Konfigurationsdatei wiederhergestellt werden.
Separate Protokolldateien für PostgreSQL verwenden
Ich empfehle, den nativen Logging-Collector von PostgreSQL während normaler Betriebszeiten zu aktivieren. Um die native PostgreSQL-Protokollierung zu aktivieren, setzen Sie den folgenden Parameter auf on:
logging_collector = on
Dafür gibt es zwei Gründe:
Erstens zeichnet das Betriebssystem in ausgelasteten Systemen PostgreSQL-Nachrichten möglicherweise nicht konsistent in syslog auf (vorausgesetzt, es handelt sich um eine nix-basierte Installation) und verwerfen häufig Nachrichten. Bei der nativen PostgreSQL-Protokollierung kümmert sich ein separater Daemon um die Aufzeichnung der Ereignisse. Wenn PostgreSQL ausgelastet ist, verschiebt dieser Prozess das Schreiben in die Protokolldateien, damit Abfragethreads abgeschlossen werden können. Dadurch kann das gesamte System blockiert werden, bis das Protokollereignis geschrieben wird. Es ist daher sinnvoll, weniger ausführliche Meldungen im Protokoll aufzuzeichnen (wie wir später sehen werden) und verkürzte Protokollzeilenpräfixe zu verwenden.
Zweitens – und wie wir später sehen werden – sollten Protokolle mit einem Protokollverwaltungsprogramm gesammelt, analysiert, indiziert und analysiert werden. Wenn PostgreSQL seine Ereignisse im Syslog aufzeichnen muss, muss im Log-Management-Teil eine zusätzliche Filter- und Musterabgleichsebene erstellt werden, um alle "Rauschmeldungen" herauszufiltern. Dedizierte Protokolldateien können von den meisten Tools einfach analysiert und für Ereignisse indiziert werden.
Log Destination auf stderr festlegen
Betrachten wir den Parameter "log_destination". Er kann vier Werte haben:
log_destination = stderr | syslog | csv | eventlog
Sofern es keinen guten Grund gibt, Protokollereignisse in einem durch Kommas getrennten Format oder Ereignisprotokoll in Windows zu speichern, empfehle ich, diesen Parameter auf stderr zu setzen. Dies liegt daran, dass bei eingeschalteter CSV-Datei ein benutzerdefinierter Parameterwert "log_line_prefix" keine Auswirkungen hat und das Präfix dennoch so erstellt werden kann, dass es wertvolle Informationen enthält.
Auf der anderen Seite kann ein CSV-Protokoll jedoch einfach in eine Datenbanktabelle importiert und später mit Standard-SQL abgefragt werden. Für mich finden PostgreSQL-Benutzer es also bequemer als die Handhabung von rohen Protokolldateien. Wie wir später sehen werden, können moderne Log-Management-Lösungen PostgreSQL-Protokolle nativ analysieren und automatisch aussagekräftige Erkenntnisse daraus gewinnen. Bei CSV muss das Reporting und die Visualisierung manuell vom Benutzer durchgeführt werden.
Letztendlich kommt es auf Ihre Wahl an. Wenn Sie mit dem Erstellen Einer eigenen Datenerfassungspipeline vertraut sind, um die CSV-Protokolle in Datenbanktabellen zu laden, die Daten zu bereinigen und zu transformieren und benutzerdefinierte Berichte zuerstellen, die Ihre Geschäftsanforderungen erfüllen, stellen Sie sicher, dass die "log_destination" auf CSV festgelegt ist.
Sinnvolle Protokolldateinamen verwenden
Wenn PostgreSQL-Protokolldateien lokal gespeichert werden, scheint das Befolgen eines Benennungsstils möglicherweise nicht erforderlich zu sein. Der Standarddateinamenstil ist “postgresql-%Y-%m-%d_%H%M%S.log” für nicht CSV-formatierte Protokolle, was für die meisten Fälle ausreichend ist.
Die Benennung wird wichtig, wenn Sie Protokolldateien von mehreren Servern an einem zentralen Speicherort wie einem dedizierten Protokollserver, einem gemounteten NFS-Volume oder einem S3-Bucket speichern. Ich empfehle, in diesem Fall zwei Parameter zu verwenden:
log_directory
log_filename
Um Protokolldateien von mehreren Instanzen an einem Ort zu speichern, erstellen Sie zunächst eine separate Verzeichnishierarchie für jede Instanz. Dies kann in etwa wie folgt sein:
/< Application_Name>/<Environment_Name>/<Instance_Name>
Die "log_directory" jeder PostgreSQL-Instanz kann dann auf den angegebenen Ordner verwiesen werden.
Jede Instanz kann dann denselben Parameterwert "log_filename" verwenden. Der Standardwert erstellt eine Datei wie
postgresql_2020-08-25_2359.log
Um einen aussagekräftigeren Namen zu verwenden, setzen Sie die "log_filename" auf etwas wie folgt:
log_filename = "postgresql_%A-%d-%B_%H%M"
Die Protokolldateien werden dann wie folgt benannt:
postgresql_Tuesday-16-November_1623
Sinnvolles Protokollzeilenpräfix verwenden
PostgreSQL-Protokollzeilen Präfixes können neben der eigentlichen Nachricht selbst die wertvollsten Informationen enthalten. Die Postgres-Dokumentation zeigt mehrere Escapezeichen für die Konfiguration des Protokollereignispräfixes. Diese Escape-Sequenzen werden zur Laufzeit durch verschiedene Statuswerte ersetzt. Einige Anwendungen wie pgBadger erwarten ein bestimmtes Protokollzeilenpräfix.
Ich empfehle, die folgenden Informationen in das Präfix aufzunehmen:
- Die Uhrzeit des-Ereignisses (ohne Millisekunden): %t
- Name oder IP-Adresse des Remoteclients: %h
- Benutzername: %u
- Aufgerufene Datenbank: %d
- Anwendungsname: %a
- Prozess-ID: %p
- Beenden der Nicht-Sitzungsprozessausgabe: %q
- Die Protokollzeilennummer für jede Sitzung oder jeden Prozess, beginnend bei 1: %l
Um zu verstehen, worum es bei jedem Feld im Präfix geht, können wir vor dem Feld eine kleine Literalzeichenfolge hinzufügen. So kann dem Prozess-ID-Wert das Literal "PID=" vorangestellt werden, der Datenbankname kann mit "db=" usw. behoben werden. Hier ist ein Beispiel:
log_line_prefix = 'time=%t, pid=%p %q db=%d, usr=%u, client=%h , app=%a, line=%l '
Je nachdem, woher das Ereignis kommt, zeigt das Protokollzeilenpräfix unterschiedliche Werte an. Sowohl Hintergrundprozesse als auch Benutzerdatensätze zeichnen ihre Meldungen in der Protokolldatei auf. Für Systemprozesse habe ich %q angegeben, wodurch jeder Text nach der Prozess-ID (%p) unterdrückt wird. In jeder anderen Sitzung werden der Datenbankname, der Benutzername, die Clientadresse, der Anwendungsname und eine Nummernzeile für jedes Ereignis angezeigt.
Außerdem habe ich ein einzelnes Leerzeichen nach dem Protokollzeilenpräfix eingefügt. Dieser Bereich trennt das Protokollereignispräfix von der eigentlichen Ereignismeldung. Es muss kein Leerzeichen sein – so etwas wie ein Doppelpunkt (::),Bindestrich (-) oder ein anderes sinnvolles Trennzeichen kann verwendet werden.
Setzen Sie außerdem den Parameter "log_hostname" auf 1:
log_hostname = 1
Andernfalls wird nur die Client-IP-Adresse angezeigt. In Produktionssystemen ist dies in der Regel die Adresse des Proxys, des Load Balancers oder des Verbindungspoolers. Wenn Sie die IP-Adressen dieser Systeme nicht auswendig kennen, kann es sich lohnen, ihre Hostnamen zu protokollieren. Die DNS-Suche fügt dem Protokollierungsdaemon jedoch auch zusätzliche Zeit hinzu, um in die Datei zu schreiben.
Ein weiterer Parameter, der zusammen mit dem "log_line_prefix" gesetzt werden sollte, ist "log_timezone". Wenn Sie dies auf die lokale Zeitzone des Servers festlegen, wird sichergestellt, dass protokollierte Ereignisse einfach aus ihrem Zeitstempel verfolgt werden können, anstatt zuerst in die Ortszeit konvertiert zu werden. Im folgenden Codeausschnitt setzen wir die log_timzeone auf Europa/Berlin Standard Zeitzone:
log_timezone = 'Europe/Berlin'
Nur Protokollverbindungen
Zwei Parameter steuern, wie PostgreSQL Clientverbindungen und -verbindungen aufzeichnet. Beide Parameter sind standardmäßig deaktiviert. Basierend auf den Sicherheitsanforderungen Ihrer Organisation können Sie eine davon auf 1 und die andere auf 0 festlegen (es sei denn, Sie verwenden ein Tool wie pgBadger – dazu später mehr).
log_connections = 1
log_disconnections = 0
Wenn Sie log_connections auf 1 setzen, werden alle autorisierten Verbindungen sowie Verbindungsversuche aufgezeichnet. Dies ist offensichtlich gut für die Sicherheitsüberwachung: Ein Brute-Force-Angriff kann leicht aus den Protokollen identifiziert werden. Wenn diese Einstellung aktiviert ist, kann jedoch in einer ausgelasteten PostgreSQL-Umgebung mit Tausenden oder sogar Hunderten von kurzlebigen gültigen Connections die Protokolldatei überschwemmt werden.
Dennoch kann es auch Anwendungsprobleme identifizieren, die sonst möglicherweise nicht offensichtlich sind. Eine große Anzahl von Verbindungsversuchen von vielen verschiedenen gültigen Clientadressen kann darauf hindeuten, dass die Instanz einen Lastenausgleich oder Verbindungspoolingdienst vor sich hat. Eine große Anzahl von Verbindungsversuchen von einer einzelnen Clientadresse kann eine Anwendung mit zu vielen Threads aufdecken, die eine Art Drosselung erfordern.
Nur DDL- und DML-Vorgänge protokollieren
Es gibt eine Menge Diskussionen darüber, was im Postgres-Protokoll aufgezeichnet werden sollte – d.h. was der Wert des Parameters "log_statement" sein sollte. Es kann drei Werte haben:
log_statement = 'off' | 'ddl' | 'mod' | 'all'
Es mag verlockend sein, dies auf "alle" zu setzen, um jede SQL-Anweisung zu erfassen, die auf dem Server ausgeführt wird, aber dies ist in der Realität möglicherweise nicht immer eine gute Idee.
Stark ausgelastete Produktionssysteme führen meist SELECT-Anweisungen aus, manchmal Tausende davon pro Stunde. Die Instanz läuft möglicherweise einwandfrei und ohne Leistungsprobleme. Das Setzen dieses Parameters auf "all" würde in solchen Fällen den Protokollierungsdaemon unnötig belasten, da er alle diese Anweisungen in die Datei schreiben muss.
Was Sie jedoch erfassen möchten, sind datenkoruption oder Änderungen in der Datenbankstruktur, die irgendeine Art von Problem verursacht haben. Unerwünschte oder nicht autorisierte Datenbankänderungen verursachen mehr Anwendungsprobleme als die Auswahl von Daten. Deshalb empfehle ich, diesen Parameter auf "mod" zu setzen. Mit dieser Einstellung zeichnet PostgreSQL alle DDL- und DML-Änderungen an der Protokolldatei auf.
Wenn Ihre PostgreSQL-Instanz mäßig ausgelastet ist (Dutzende von Abfragen pro Stunde), können Sie diesen Parameter auf "alle" setzen. Wenn Sie probleme bei langsam ausgeführten SELECT-Abfragen beheben oder nach unbefugtem Datenzugriff suchen, können Sie dies auch vorübergehend auf "alle" festlegen. Einige Anwendungen wie pgBadger erwarten auch, dass Sie dies auf "all" setzen.
Protokollieren Sie "Warnmeldungen" und mehr
Wenn der Parameter "log_statement" entscheidet, welche Art von Anweisungen aufgezeichnet werden, bestimmen die folgenden 2-Parameter, wie detailliert die Nachricht sein wird:
log_min_messages
log_min_error_statement
Jedem PostgreSQL-Ereignis ist eine Nachrichtenebene zugeordnet. Die Nachrichtenebene kann von ausführlichem DEBUG bis hin zu knapper PANIK alles sein. Je niedriger die Ebene, desto ausführlicher ist die Nachricht. Der Standardwert für den Parameter "log_min_messages" ist "WARNING". Ich empfehle, diese Ebene beizubehalten, es sei denn, Sie möchten, dass auch Informationsnachrichten protokolliert werden.
Der Parameter "log_min_error_statement" steuert, welche SQL-Anweisungen, die Fehler verursachen, protokolliert werden. Wie bei "log_min_message" wird jede SQL-Anweisung mit einem Fehlerschweregrad aufgezeichnet, der dem in "log_min_error_statement" angegebenen Wert entspricht oder darüber liegt. Der Standardwert ist "ERROR", und ich empfehle, den Standardwert beizubehalten.
Protokolldauerparameter auf Standardwerten halten
Dann haben wir die folgenden zwei Parameter:
log_duration
log_min_duration_statement
Der Parameter "log_duration" nimmt einen booleschen Wert an. Wenn sie auf 1 festgelegt ist, wird die Dauer jeder abgeschlossenen Anweisung protokolliert. Wenn der 0-Satz auf 0 festgelegt ist, wird die Anweisungsdauer nicht protokolliert. Dies ist der Standardwert, und ich empfehle, ihn auf 0 zu 0 zu behalten, es sei denn, Sie beheben Leistungsprobleme. Durch das Berechnen und Aufzeichnen der Anweisungsdauer leistet das Datenbankmodul zusätzliche Arbeit (egal wie klein sie ist), und wenn sie auf Hunderte oder Tausende von Abfragen extrapoliert wird, können die Einsparungen sehr gering sein.
Schließlich haben wir den Parameter "log_min_duration_statement". Wenn dieser Parameter festgelegt ist (ohne Einheiten wird er als Millisekunden betrachtet), wird die Dauer einer Anweisung, die gleich oder länger als der Parameterwert ist, protokolliert. Wenn Sie diesen Parameterwert auf 0 setzen, wird die Dauer aller abgeschlossenen Anweisungen aufgezeichnet. Wenn Sie diese Option auf -1 festlegen, wird die Protokollierung der Anweisungsdauer deaktiviert. Dies ist der Standardwert, und ich empfehle, ihn so zu behalten.
Sie möchten diesen Parameter nur dann auf 0 festlegen, wenn Sie eine Leistungsbasislinie für häufig ausgeführte Abfragen erstellen möchten. Beachten Sie jedoch, dass, wenn der Parameter "log_statement" gesetzt ist, die protokollierten Anweisungen in den Protokollmeldungen, die die Dauer anzeigen, nicht wiederholt werden. Sie müssen also die Protokolldateien in eine Datenbanktabelle laden und dann die Prozess-ID- und Sitzungs-ID-Werte aus den Protokollzeilenpräfixen verbinden, um verwandte Anweisungen und deren Dauer zu identifizieren.
Was auch immer die Mittel sind, sobald Sie eine Baseline für jede häufig ausgeführte Abfrage haben, können Sie den Parameter "log_min_duration_statement" auf den höchsten der Baseline-Werte festlegen. Jetzt ist jede Abfrage, die länger als der höchste Basiswert ausgeführt wird, ein Kandidat für die Feinabstimmung.
Fehlermeldungsverbung auf Standardwert halten
Der Parameter "log_error_verbosity" kann drei mögliche Werte haben:
log_error_verbosity = terse | standard | verbose
Dieser Parameter steuert die Menge der Informationen, die PostgreSQL für jedes in der Protokolldatei aufgezeichnete Ereignis aufzeichnen wird. Sofern keine Datenbankanwendung debuggt wird, ist dieser Parameter am besten bei "default" zu halten. Der ausführliche Modus ist nützlich, wenn Sie den Datei- oder Funktionsnamen und die Zeilennummer dort erfassen müssen, die den Fehler generiert hat. Wenn Sie dies auf "knapp" setzen, wird die Protokollierung der Abfrage unterdrückt, was möglicherweise auch nicht nützlich ist.
Finden Sie eine Protokollrotations policy, die für Ihren Anwendungsfall geeignet ist
Ich empfehle, eine Protokollrotationsrichtlinie basierend auf der Größe oder dem Alter der Protokolldatei zu erstellen, jedoch nicht auf beiden. Zwei PostgreSQL-Konfigurationsparameter bestimmen, wie alte Protokolle archiviert und neue Protokolle erstellt werden:
log_rotation_age = <Anzahl Minuten>
log_rotation_size = <Anzahl Kilobyte>
Der Standardwert für "log_rotration_age" ist 24 Stunden, und der Standardwert für "log_rotation_size"ist 10 Megabyte.
In den meisten Fällen garantiert eine Größenrotationsrichtlinie nicht immer, dass die letzte Protokolldatei in der archivierten Protokolldatei vollständig nur in dieser Datei enthalten ist.
Wenn die" log_rotation_age" auf ihren Standardwert von 24 Stunden gehalten wird, kann jede Datei leicht identifiziert und einzeln untersucht werden, da jede Datei Ereignisse eines Tages enthält. Auch dies garantiert jedoch nicht, dass jede Datei eine in sich geschlossene Einheit von Protokollen der letzten 24 Stunden ist. Manchmal kann es mehr als 24 Stunden dauern, bis eine langsame Abfrage abgeschlossen ist. Ereignisse können auftreten, wenn die alte Datei geschlossen und die neue generiert wird. Dies kann während eines nächtlichen Batch-Jobs der Fall sein, was dazu führt, dass einige Teile der Abfragen in einer Datei und der Rest in einer anderen Datei aufgezeichnet werden.
Unsere Empfehlung ist, eine Log-Rotationsperiode zu finden, die für Ihren Anwendungsfall funktioniert. Überprüfen Sie den Zeitunterschied zwischen zwei aufeinanderfolgenden Perioden mit der niedrigsten Aktivität (z. B. zwischen einem Samstag zum nächsten). Sie können dann den Wert "log_rotation_age" auf diesen Zeitnachlasse setzen und während eines dieser Zeiträume den PostgreSQL-Dienst neu starten. Auf diese Weise dreht PostgreSQL die aktuelle Protokolldatei, wenn die nächste Flaute eintritt. Wenn Sie den Dienst jedoch zwischen diesen Zeiträumen neu starten müssen, wird die Protokollrotation erneut verzerrt. Sie müssen diesen Vorgang dann wiederholen. Aber wie bei vielen anderen Dingen in PostgreSQL wird Versuch und Irrtum den besten Wert bestimmen. Wenn Sie ein Dienstprogramm für die Protokollverwaltung verwenden, spielt das Alter oder die Größe der Protokollrotation keine Rolle, da der Agent für die Protokollverwaltungr jedes Ereignis aus der Datei aufnimmt, wenn es hinzugefügt wird.
Verwenden Sie Tools wie pgBadger
pgBadger ist ein leistungsstarker PostgreSQL-Protokollanalysator, der sehr nützliche Erkenntnisse aus Postgres-Protokolldateien gewinnen kann. Es ist ein in Perl geschriebenes Open-Source-Tool mit einem sehr geringen Platzbedarf in der Maschine, auf der es ausgeführt wird. Das Tool wird über die Befehlszeile ausgeführt und verfügt über eine große Anzahl von Optionen. Es nimmt ein oder mehrere Protokolle als Eingabe und kann einen HTML-Bericht mit detaillierten Statistiken über Folgendes erstellen:
- Am häufigsten wartende Abfragen.
- Abfragen, die die meisten temporären Dateien oder die größten temporären Dateien generieren
- Am langsamsten ausgeführte Abfragen
- Durchschnittliche Abfragedauer
- Am häufigsten ausgeführte Abfragen
- Häufigste Fehler bei Abfragen
- Benutzer und Anwendungen, die Abfragen ausführen
- Checkpoints-Statistiken.
- Autovakuum und Autoanalysestatistiken.
- Sperrstatistik
- Fehlerereignisse (Panik, schwerwiegender Fehler, Fehler und Warnung).
- Verbindungs- und Sitzungsprofile (nach Datenbank, Benutzer, Anwendung)
- Sitzungsprofile
- Abfrageprofile (Abfragetypen, Abfragennach Datenbank/Anwendung)
- E/A-Statistiken
- etc.
Wie bereits erwähnt, müssen einige der protokollbezogenen Konfigurationsparameter aktiviert werden, um alle Protokollereignisse zu erfassen, damit pgBadger diese Protokolle effektiv analysieren kann. Da dadurch große Protokolldateien mit vielen Ereignissen erzeugt werden können, sollte pgBadger nur zum Create Benchmarks oder zur Behebung von Leistungsproblemen verwendet werden. Sobald die detaillierten Protokolle generiert wurden, können die Konfigurationsparameter wieder auf ihre ursprünglichen Werte zurückgesetzt werden. Für die kontinuierliche Protokollanalyse ist es am besten, eine dedizierte Protokollverwaltungsanwendung zu verwenden.
Wenn Sie mit der Eingabeaufforderung vertrauter sind und Systemansichten verwenden, sollten Sie pg_stat_statements verwenden. Tatsächlich sollte dies in jeder PostgreSQL-Produktionsinstallation aktiviert sein.
pg_stat_statements ist eine PostgreSQL-Erweiterung and mit der Standardinstallation jetzt. Um dies zu aktivieren, sollte der Konfigurationsparameter " shared_preload_libraries" pg_stat_statements als einen seiner Werte haben. Es kann dann wie jede andere Erweiterung mit dem Befehl "CREATE EXTENSION" installiert werden. Die Extension erstellt die pg_stat_statement Ansicht, die wertvolle abfragebezogene Informationen liefert.
Verwenden einer Protokollverwaltungsanwendung zum Gewinnen von Einblicken
Es gibt viele Protokollverwaltungsprogramme auf dem Markt, und die meisten Organisationen verwenden heutzutage eines oder mehrere. Unabhängig davon, welches Tool vorhanden ist, empfehle ich, es zum Sammeln und Verwalten von PostgreSQL-Protokollen zu verwenden.
Dafür gibt es mehrere Gründe:
Mit einem automatisierten Tool ist es viel einfacher, Geräusche aus Protokolldateien zu analysieren, zu analysieren und herauszufiltern. Manchmal kann sich ein Ereignis über mehrere Protokolldateien erstrecken, basierend auf der Dauer des Ereignisses und dem Alter oder der Größe der Protokollrotation. Ein Log-Manager macht es viel einfacher, diese Informationen als Ganzes darzustellen.
Protokollverwaltungslösungen verfügen heute in der Regel über eine integrierte Fähigkeit, PostgreSQL-Protokolle zu analysieren. Einige verfügen auch über Dashboards, die die häufigsten Metriken anzeigen können, die aus diesen Protokollen extrahiert wurden.
Die meisten modernen Protokollverwaltungsanwendungen bieten auch leistungsstarke Such-, Filter-, Mustervergleichs-, Ereigniskorrelations- und KI-fähige Trendanalysefunktionen. Was für gewöhnliche Augen nicht sichtbar ist, kann mit diesen Werkzeugen leicht offensichtlich gemacht werden.
Schließlich bedeutet die Verwendung eines Protokollmanagers zum Speichern von PostgreSQL-Protokollen, dass die Ereignisse für die Nachwelt gespeichert werden, auch wenn die Originaldateien versehentlich oder böswillig gelöscht werden.
Obwohl die Verwendung einer Protokollverwaltungsanwendung offensichtliche Vorteile bietet, haben viele Organisationen Einschränkungen hinsichtlich des Standorts ihrer Protokolle. Dies ist ein typischer Fall bei SaaS-basierten Lösungen, bei denen Protokolle häufig außerhalb der geografischen Grenzen eines Unternehmens gespeichert werden – etwas, das möglicherweise nicht den gesetzlichen Anforderungen entspricht.
In solchen Fällen empfehle ich, einen Anbieter mit lokaler Rechenzentrumspräsenz zu wählen – wenn möglich – oder einen selbstverwalteten Log-Manager zu verwenden, der im Netzwerk der Organisation gehostet wird, z. B. einen ELK-Stack.
Abschließende Worte
PostgreSQL-Serverprotokolle können bei entsprechender Konfiguration eine Goldmine an Informationen sein. Der Trick besteht darin, zu bestimmen,wann und wie viel protokolliert werden soll, und vor allem zu testen, ob die Protokolle bei Bedarf die richtigen Informationen liefern können. Es wird eine Frage von Versuch und Irrtum sein, aber was ich heute hier besprochen habe, sollte einen ziemlich anständigen Anfang geben.