PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

So holen Sie das Beste aus PostgreSQL-Protokollen heraus

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 nicht ignoriert, normalerweise falsch eingestellt. Dies geschieht, weil der Zweck der Protokollierung meistens unklar ist. Natürlich ist der grundlegende Grund für die Protokollierung bekannt, aber was manchmal fehlt, ist das Verständnis dafür, wie die Protokolle verwendet werden.

Die Protokollierungsanforderungen jeder Organisation sind einzigartig, und daher ist auch die Art und Weise, wie die PostgreSQL-Protokollierung konfiguriert werden sollte, unterschiedlich. 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; Leser sind herzlich eingeladen, ihre Gedanken im Kommentarbereich mitzuteilen. Um jedoch den besten Nutzen daraus zu ziehen, bitte ich den Leser, darüber nachzudenken, wie er seine PostgreSQL-Datenbankserverprotokolle verwenden möchte:

  • Grund zur Einhaltung gesetzlicher Vorschriften, wenn bestimmte Informationen erfasst werden müssen
  • Sicherheitsprüfung, wenn bestimmte Ereignisdetails vorhanden sein müssen
  • Fehlerbehebung bei der Leistung, wenn Abfragen und ihre Parameter aufgezeichnet werden sollen
  • Tägliche operative Unterstützung, wenn eine festgelegte Anzahl von Metriken überwacht werden sollen

Fangen wir damit an.

Machen Sie keine manuellen Änderungen an postgresql.conf

Alle Änderungen in der Datei postgresql.conf sollten mit einem Konfigurationsverwaltungssystem 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 oft mehrere Kopien der postgresql.conf-Datei, jede mit leicht unterschiedlichen Parametern, jede für einen anderen Zweck. Die manuelle Verwaltung verschiedener Konfigurationsdateien ist eine umständliche Aufgabe, wenn sie nicht fehleranfällig ist. Andererseits kann ein Konfigurationsverwaltungssystem dazu gebracht werden, verschiedene Versionen der postgresql.conf-Datei basierend auf einem ihm übergebenen Parameter umzubenennen und zu verwenden. Dieser Parameter bestimmt den Zweck der aktuellen Version. Wenn der Bedarf abgeschlossen ist, kann die alte Konfigurationsdatei wiederhergestellt werden, indem derselbe Eingabeparameter geändert wird.

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 es nicht notwendig ist, alle Anweisungen aufzuzeichnen – vielleicht nach einer Fehlerbehebungsübung – könnte die vorherige Konfigurationsdatei wiederhergestellt werden.

Verwenden Sie separate Protokolldateien für PostgreSQL

Ich empfehle, den nativen Logging-Collector von PostgreSQL während des normalen Betriebs 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 stark ausgelasteten Systemen PostgreSQL-Meldungen möglicherweise nicht konsistent im Syslog auf (vorausgesetzt, es handelt sich um eine nix-basierte Installation) und verwirft häufig Meldungen. Bei der nativen PostgreSQL-Protokollierung kümmert sich ein separater Daemon um die Aufzeichnung der Ereignisse. Wenn PostgreSQL ausgelastet ist, verzögert dieser Prozess das Schreiben in die Protokolldateien, damit Abfrage-Threads beendet werden können. Dies kann das gesamte System blockieren, 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, geparst, indiziert und analysiert werden. Wenn PostgreSQL seine Ereignisse im Syslog aufzeichnet, muss im Protokollverwaltungsteil eine zusätzliche Ebene zum Filtern und Mustervergleich erstellt werden, um alle „Rauschmeldungen“ herauszufiltern. Dedizierte Protokolldateien können von den meisten Tools leicht analysiert und nach Ereignissen indiziert werden.

Protokollziel auf stderr setzen

Betrachten wir den Parameter „log_destination“. Es kann vier Werte haben:

log_destination = stderr | syslog | csv | eventlog

Sofern es keinen triftigen Grund gibt, Protokollereignisse in einem durch Kommas getrennten Format oder ein Ereignisprotokoll in Windows zu speichern, empfehle ich, diesen Parameter auf stderr zu setzen. Dies liegt daran, dass bei einem CSV-Dateiziel ein benutzerdefinierter „log_line_prefix“-Parameterwert keine Wirkung hat, und dennoch kann das Präfix so gestaltet werden, 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. Einige PostgreSQL-Benutzer finden es bequemer als den Umgang mit rohen Protokolldateien. Wie wir später sehen werden, können moderne Protokollverwaltungslösungen PostgreSQL-Protokolle nativ parsen und daraus automatisch aussagekräftige Erkenntnisse gewinnen. Bei CSV muss die Berichterstellung und Visualisierung manuell durch den Benutzer erfolgen.

Letztendlich kommt es auf Ihre Wahl an. Wenn Sie gerne Ihre eigene Datenerfassungspipeline erstellen, um die CSV-Protokolle in Datenbanktabellen zu laden, die Daten zu bereinigen und umzuwandeln und benutzerdefinierte Berichte zu erstellen, die Ihren Geschäftsanforderungen entsprechen, stellen Sie sicher, dass „log_destination“ auf CSV eingestellt ist.

Verwenden Sie aussagekräftige Protokolldateinamen

Wenn PostgreSQL-Protokolldateien lokal gespeichert werden, erscheint es möglicherweise nicht erforderlich, einem Namensstil zu folgen. Der standardmäßige Dateinamenstil ist „postgresql-%Y-%m-%d_%H%M%S.log“ für Protokolle im Nicht-CSV-Format, was für die meisten Fälle ausreichend ist.

Die Benennung wird wichtig, wenn Sie Protokolldateien von mehreren Servern an einem zentralen Ort wie einem dedizierten Protokollserver, einem gemounteten NFS-Volume oder einem S3-Bucket speichern. Ich empfehle in diesem Fall die Verwendung von zwei Parametern:

log_directory
log_filename

Um Protokolldateien von mehreren Instanzen an einem Ort zu speichern, erstellen Sie zuerst eine separate Verzeichnishierarchie für jede Instanz. Dies kann in etwa so aussehen:

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

Das „log_directory“ jeder PostgreSQL-Instanz kann dann auf den angegebenen Ordner verwiesen werden.

Jede Instanz kann dann denselben „log_filename“-Parameterwert verwenden. Der Standardwert erstellt eine Datei wie

postgresql_2020-08-25_2359.log

Um einen aussagekräftigeren Namen zu verwenden, setzen Sie den „log_filename“ auf etwa so:

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

Die Protokolldateien werden dann wie folgt benannt:

postgresql_Saturday-23-August_2230

Verwenden Sie ein aussagekräftiges Protokollzeilenpräfix

PostgreSQL-Protokollzeilenpräfixe können neben der eigentlichen Nachricht selbst die wertvollsten Informationen enthalten. Die Postgres-Dokumentation zeigt mehrere Escape-Zeichen 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 Zeit des Ereignisses (ohne Millisekunden):%t
  • Remote-Client-Name oder IP-Adresse:%h
  • Benutzername:%u
  • Datenbankzugriff:%d
  • Anwendungsname:%a
  • Prozess-ID:%p
  • Beendigung der Nichtsitzungsprozessausgabe:%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. Dem Prozess-ID-Wert kann also das Literal „PID=“ vorangestellt werden, dem Datenbanknamen kann „db=“ vorangestellt werden usw. 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 Präfix der Protokollzeile unterschiedliche Werte an. Sowohl Hintergrundprozesse als auch Benutzerprozesse zeichnen ihre Meldungen in der Protokolldatei auf. Für Systemprozesse habe ich %q angegeben, wodurch jeglicher Text nach der Prozess-ID (%p) unterdrückt wird. Jede andere Sitzung zeigt den Datenbanknamen, den Benutzernamen, die Client-Adresse, den Anwendungsnamen und eine nummerierte Zeile für jedes Ereignis an.

Außerdem habe ich nach dem Präfix der Protokollzeile ein einzelnes Leerzeichen eingefügt. Dieses Leerzeichen trennt das Präfix des Protokollereignisses von der eigentlichen Ereignismeldung. Es muss kein Leerzeichen sein – irgendetwas wie ein doppelter Doppelpunkt (::), ein Bindestrich (-) oder ein anderes sinnvolles Trennzeichen kann verwendet werden.

Setzen Sie außerdem den Parameter „log_hostname“ auf 1:

log_hostname = 1

Ohne dies wird nur die Client-IP-Adresse angezeigt. In Produktionssystemen ist dies in der Regel die Adresse des Proxys, Load Balancers oder Connection Poolers. Wenn Sie die IP-Adressen dieser Systeme nicht auswendig kennen, kann es sich lohnen, ihre Hostnamen zu protokollieren. Die DNS-Suche fügt dem Protokollierungs-Daemon jedoch auch zusätzliche Zeit hinzu, um in die Datei zu schreiben.

Ein weiterer Parameter, der zusammen mit „log_line_prefix“ gesetzt werden sollte, ist „log_timezone“. Wenn Sie dies auf die lokale Zeitzone des Servers einstellen, wird sichergestellt, dass protokollierte Ereignisse anhand ihres Zeitstempels leicht zu verfolgen sind, anstatt zuerst in die Ortszeit umgerechnet zu werden. Im folgenden Code-Snippet setzen wir log_timzeone auf Australian Eastern Standard Timezone:

log_timezone = 'Australia/Sydney'

Nur Verbindungen protokollieren

Zwei Parameter steuern, wie PostgreSQL Clientverbindungen und -trennungen aufzeichnet. Beide Parameter sind standardmäßig ausgeschaltet. Basierend auf den Sicherheitsanforderungen Ihrer Organisation möchten Sie vielleicht einen davon auf 1 und den anderen auf 0 setzen (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 versuchte aufgezeichnet Verbindungen. Dies ist natürlich gut für die Sicherheitsüberprüfung:Ein Brute-Force-Angriff kann anhand der Protokolle leicht identifiziert werden. Wenn diese Einstellung jedoch aktiviert ist, könnte eine ausgelastete PostgreSQL-Umgebung mit Tausenden oder sogar Hunderten von kurzlebigen gültigen Verbindungen dazu führen, dass die Protokolldatei überschwemmt wird.

Nichtsdestotrotz kann es auch Anwendungsprobleme identifizieren, die ansonsten möglicherweise nicht offensichtlich sind. Eine große Anzahl von Verbindungsversuchen von vielen verschiedenen gültigen Clientadressen kann darauf hindeuten, dass die Instanz einen Lastenausgleichs- oder Verbindungspoolingdienst davor benötigt. Eine große Anzahl von Verbindungsversuchen von einer einzelnen Client-Adresse kann eine Anwendung mit zu vielen Threads aufdecken, die irgendeine Art von Drosselung benötigen.

Nur DDL- und DML-Operationen protokollieren

Es gibt viele Diskussionen darüber, was im Postgres-Protokoll aufgezeichnet werden soll – d. h. welchen Wert der Parameter „log_statement“ haben soll. Es kann drei Werte haben:

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

Es mag verlockend sein, dies auf „all“ 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.

Ausgelastete Produktionssysteme führen meistens SELECT-Anweisungen aus, manchmal Tausende davon pro Stunde. Die Instanz läuft möglicherweise einwandfrei und ohne Leistungsprobleme. Wenn Sie diesen Parameter in solchen Fällen auf „all“ setzen, würde dies den Logging-Daemon unnötig belasten, da er all diese Anweisungen in die Datei schreiben muss.

Was Sie jedoch erfassen möchten, sind Datenbeschädigungen oder Änderungen in der Datenbankstruktur, die ein 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 in der Protokolldatei auf.

Wenn Ihre PostgreSQL-Instanz mäßig ausgelastet ist (Dutzende von Abfragen pro Stunde), können Sie diesen Parameter gerne auf „all“ setzen. Wenn Sie langsam laufende SELECT-Abfragen beheben oder nach unbefugtem Datenzugriff suchen, können Sie dies auch vorübergehend auf „alle“ setzen. Einige Anwendungen wie pgBadger erwarten auch, dass Sie dies auf „alle“ setzen.

Protokollieren Sie „Warnmeldungen“ und höher

Wenn der Parameter „log_statement“ entscheidet, welche Art von Anweisungen aufgezeichnet werden, bestimmen die folgenden zwei Parameter, wie detailliert die Nachricht sein wird:

log_min_messages
log_min_error_statement

Jedes PostgreSQL-Ereignis hat eine zugeordnete Nachrichtenebene. Die Meldungsebene kann alles sein, von ausführlich DEBUG bis knapp PANIC. Je niedriger die Stufe, desto ausführlicher ist die Nachricht. Der Standardwert für den Parameter „log_min_messages“ ist „WARNING“. Ich empfehle, diese Stufe beizubehalten, es sei denn, Sie möchten, dass auch Informationsmeldungen protokolliert werden.

Der Parameter „log_min_error_statement“ steuert, welche SQL-Anweisungen, die Fehler auslösen, protokolliert werden. Wie „log_min_message“ wird jede SQL-Anweisung mit einem Fehlerschweregrad gleich oder höher als der in „log_min_error_statement“ angegebene Wert aufgezeichnet. Der Standardwert ist „ERROR“, und ich empfehle, den Standardwert beizubehalten.

Protokolldauer-Parameter auf Standard belassen

Dann haben wir die folgenden zwei Parameter:

log_duration
log_min_duration_statement

Der Parameter „log_duration“ nimmt einen booleschen Wert an. Wenn es auf 1 gesetzt ist, wird die Dauer jeder abgeschlossenen Anweisung protokolliert. Wenn auf 0 gesetzt, wird die Anweisungsdauer nicht protokolliert. Dies ist der Standardwert, und ich empfehle, ihn auf 0 zu belassen, es sei denn, Sie beheben Leistungsprobleme. Das Berechnen und Aufzeichnen der Anweisungsdauer macht der Datenbank-Engine zusätzliche Arbeit (egal wie klein), und wenn sie auf Hunderte oder Tausende von Abfragen hochgerechnet wird, können die Einsparungen erheblich sein.

Zuletzt haben wir den Parameter „log_min_duration_statement“. Wenn dieser Parameter gesetzt ist (ohne Einheiten, es wird als Millisekunden angenommen), wird die Dauer jeder Anweisung, die gleich oder länger als der Parameterwert dauert, protokolliert. Wenn Sie diesen Parameterwert auf 0 setzen, wird die Dauer aller abgeschlossenen Anweisungen aufgezeichnet. Wenn Sie dies auf -1 setzen, wird die Protokollierung der Anweisungsdauer deaktiviert. Dies ist der Standardwert, und ich empfehle, ihn beizubehalten.

Sie sollten diesen Parameter nur dann auf 0 setzen, wenn Sie eine Leistungsbaseline für häufig ausgeführte Abfragen erstellen möchten. Beachten Sie jedoch, dass bei gesetztem Parameter „log_statement“ die protokollierten Statements nicht in den Log-Meldungen mit Dauer 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 zusammenfügen, um verwandte Anweisungen und ihre Dauer zu identifizieren.

Wie auch immer, 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 setzen. Jetzt ist jede Abfrage, die länger als der höchste Basiswert ausgeführt wird, ein Kandidat für die Feinabstimmung.

Ausführlichkeit der Fehlermeldung auf Standard belassen

Der Parameter „log_error_verbosity“ kann drei mögliche Werte haben:

log_error_verbosity = terse | standard | verbose

Dieser Parameter steuert die Menge an Informationen, die PostgreSQL für jedes in der Protokolldatei aufgezeichnete Ereignis aufzeichnet. Wenn Sie keine Datenbankanwendung debuggen, sollten Sie diesen Parameter am besten auf „Standard“ belassen. Der ausführliche Modus ist nützlich, wenn Sie den Datei- oder Funktionsnamen und die Zeilennummer dort erfassen müssen, die den Fehler verursacht 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 Protokollrotationsrichtlinie, die für Ihre funktioniert Anwendungsfall

Ich empfehle, eine Protokollrotationsrichtlinie zu erstellen, die entweder auf der Größe oder dem Alter der Protokolldatei basiert, aber nicht auf beiden. Zwei PostgreSQL-Konfigurationsparameter bestimmen, wie alte Protokolle archiviert und neue Protokolle erstellt werden:

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

Der Standardwert für „log_rotation_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 Protokollnachricht in der archivierten Protokolldatei vollständig nur in dieser Datei enthalten ist.

Wenn das „log_rotation_age“ auf seinem Standardwert von 24 Stunden gehalten wird, kann jede Datei leicht identifiziert und einzeln untersucht werden, da jede Datei die Ereignisse eines Tages enthält. Auch dies garantiert jedoch nicht, dass jede Datei eine in sich geschlossene Einheit von Protokollen der letzten 24 Stunden darstellt. Manchmal kann es mehr als 24 Stunden dauern, bis eine Abfrage mit langsamer Leistung abgeschlossen ist. Ereignisse könnten passieren, 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 aufgezeichnet werden und der Rest in einer anderen.

Wir empfehlen, einen für Ihren geeigneten Zeitraum für die Protokollrotation zu finden Anwendungsfall. Überprüfen Sie den Zeitunterschied zwischen zwei aufeinanderfolgenden Perioden mit geringster Aktivität (z. B. zwischen einem Samstag und dem nächsten). Sie können dann den Wert „log_rotation_age“ auf diesen Zeitunterschied setzen und während eines dieser Zeiträume den PostgreSQL-Dienst neu starten. Auf diese Weise rotiert 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. Diesen Vorgang müssen Sie dann wiederholen. Aber wie bei vielen anderen Dingen in PostgreSQL bestimmt Versuch und Irrtum den besten Wert. Wenn Sie ein Dienstprogramm zur Protokollverwaltung verwenden, spielt das Alter oder die Größe der Protokollrotation keine Rolle, da der Protokollmanager-Agent jedes Ereignis aus der Datei aufnimmt, sobald 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 auf dem Computer, auf dem es ausgeführt wird. Das Tool wird über die Befehlszeile ausgeführt und verfügt über eine große Anzahl von Optionen. Es verwendet ein oder mehrere Protokolle als Eingabe und kann einen HTML-Bericht mit detaillierten Statistiken zu folgenden Themen erstellen:

  • Am häufigsten wartende Abfragen.
  • Abfragen, die die meisten temporären Dateien oder die größten temporären Dateien generieren
  • Am langsamsten laufende Abfragen
  • Durchschnittliche Abfragedauer
  • Am häufigsten ausgeführte Abfragen
  • Häufigste Fehler in Abfragen
  • Benutzer und Anwendung, die Abfragen ausführen
  • Checkpoint-Statistiken.
  • Autovacuum- und Autoanalyze-Statistiken.
  • Sperrstatistik
  • Fehlerereignisse (Panik, schwerwiegend, Fehler und Warnung).
  • Verbindungs- und Sitzungsprofile (nach Datenbank, Benutzer, Anwendung)
  • Sitzungsprofile
  • Abfrageprofile (Abfragetypen, Abfragen nach Datenbank/Anwendung)
  • E/A-Statistiken
  • usw.

Wie ich bereits erwähnt habe, müssen einige der protokollbezogenen Konfigurationsparameter aktiviert werden, um alle Protokollereignisse zu erfassen, damit pgBadger diese Protokolle effektiv analysieren kann. Da dies große Protokolldateien mit vielen Ereignissen erzeugen kann, sollte pgBadger nur zum Erstellen von Benchmarks oder zum Beheben von Leistungsproblemen verwendet werden. Sobald die detaillierten Protokolle generiert wurden, können die Konfigurationsparameter wieder auf ihre ursprünglichen Werte geändert werden. Für eine kontinuierliche Protokollanalyse verwenden Sie am besten eine dedizierte Protokollverwaltungsanwendung.

Wenn Sie lieber Dinge in der Eingabeaufforderung erledigen und Systemansichten verwenden, sollten Sie pg_stat_statements verwenden. Tatsächlich sollte dies in jeder PostgreSQL-Produktionsinstallation aktiviert werden.

pg_stat_statements ist eine PostgreSQL-Erweiterung und jetzt mit der Standardinstallation. Um es zu aktivieren, sollte der Konfigurationsparameter „shared_preload_libraries“ pg_stat_statements als einen seiner Werte haben. Sie kann dann wie jede andere Erweiterung mit dem Befehl „CREATE EXTENSION“ installiert werden. Die Erweiterung erstellt die pg_stat_statement-Ansicht, die wertvolle abfragebezogene Informationen bereitstellt.

Verwenden Sie eine Protokollverwaltungsanwendung, um Erkenntnisse zu gewinnen

Es gibt viele Dienstprogramme zur Protokollverwaltung auf dem Markt, und die meisten Unternehmen verwenden heutzutage eines oder mehrere. Welches Tool auch immer vorhanden ist, ich empfehle, es zum Sammeln und Verwalten von PostgreSQL-Protokollen zu verwenden.

Dafür gibt es einige Gründe:

Mit einem automatisierten Tool ist es viel einfacher, Rauschen aus Protokolldateien zu parsen, zu analysieren und herauszufiltern. Manchmal kann ein Ereignis mehrere Protokolldateien umfassen, basierend auf der Dauer des Ereignisses und dem Alter oder der Größe der Protokollrotation. Ein Protokollmanager macht es viel einfacher, diese Informationen als Ganzes darzustellen.

Protokollverwaltungslösungen verfügen heute in der Regel über eine integrierte Fähigkeit zum Parsen von PostgreSQL-Protokollen. Einige verfügen auch über Dashboards, die die gängigsten Messwerte anzeigen können, die aus diesen Protokollen extrahiert wurden.

Die meisten modernen Protokollverwaltungsanwendungen bieten außerdem leistungsstarke Such-, Filter-, Musterabgleichs-, Ereigniskorrelations- und KI-fähige Trendanalysefunktionen. Was für gewöhnliche Augen nicht sichtbar ist, kann mit diesen Tools leicht sichtbar gemacht werden.

Schließlich bedeutet die Verwendung eines Protokollmanagers zum Speichern von PostgreSQL-Protokollen auch, dass die Ereignisse für die Nachwelt gespeichert werden, selbst wenn die Originaldateien versehentlich oder böswillig gelöscht werden.

Obwohl die Verwendung einer Protokollverwaltungsanwendung offensichtliche Vorteile hat, haben viele Organisationen Beschränkungen hinsichtlich wo Ihre Protokolle können leben. Dies ist ein typischer Fall bei SaaS-basierten Lösungen, bei denen Protokolle häufig außerhalb der geografischen Grenzen einer Organisation gespeichert werden – etwas, das möglicherweise nicht den gesetzlichen Anforderungen entspricht.

In solchen Fällen empfehle ich, wenn möglich, einen Anbieter mit lokaler Rechenzentrumspräsenz zu wählen oder einen selbstverwalteten Protokollmanager zu verwenden, der im Netzwerk der Organisation gehostet wird, z. B. einen ELK-Stack.

Schlussworte

PostgreSQL-Serverprotokolle können bei entsprechender Konfiguration eine Goldgrube an Informationen sein. Der Trick besteht darin, zu bestimmen, was und wie viel protokolliert werden soll, und, was noch wichtiger ist, zu testen, ob die Protokolle bei Bedarf die richtigen Informationen liefern können. Es wird eine Sache von Versuch und Irrtum sein, aber was ich heute hier besprochen habe, sollte einen ziemlich anständigen Anfang geben. Wie ich eingangs sagte, würde ich mich sehr über Ihre Erfahrungen mit der Konfiguration der PostgreSQL-Protokollierung für optimale Ergebnisse freuen.