Grundlagen der PostgreSQL-Überwachung. Alexey Lesovsky

Ich schlage vor, dass Sie sich mit dem Transkript des Berichts von Alexey Lesovsky von Data Egret „Basics of PostgreSQL Monitoring“ vertraut machen.

In diesem Bericht wird Alexey Lesovsky über die wichtigsten Punkte der Postgres-Statistiken sprechen, was sie bedeuten und warum sie in die Überwachung einbezogen werden sollten; darüber, welche Diagramme in der Überwachung enthalten sein sollten, wie man sie hinzufügt und wie man sie interpretiert. Der Bericht wird für Datenbankadministratoren, Systemadministratoren und Entwickler nützlich sein, die an der Fehlerbehebung bei Postgres interessiert sind.

Mein Name ist Alexey Lesovsky, ich vertrete Data Egret.

Ein paar Worte zu meiner Person. Ich habe vor langer Zeit als Systemadministrator angefangen.

Ich habe alle möglichen Linux-Varianten administriert, verschiedene Dinge rund um Linux gemacht, also Virtualisierung, Überwachung, mit Proxys gearbeitet usw. Aber irgendwann habe ich mich mehr mit Datenbanken, PostgreSQL, beschäftigt. Ich mochte ihn wirklich. Und irgendwann begann ich, mich die meiste Zeit meiner Arbeitszeit mit PostgreSQL zu beschäftigen. Und so wurde ich nach und nach PostgreSQL-DBA.

Und im Laufe meiner Karriere habe ich mich immer für die Themen Statistik, Monitoring, Telemetrie interessiert. Und als Systemadministrator habe ich sehr hart an Zabbix gearbeitet. Und schrieb eine kleine Reihe von Skripten wie Zabbix-Erweiterungen. Er war zu seiner Zeit sehr beliebt. Und dort war es möglich, ganz unterschiedliche wichtige Dinge zu überwachen, nicht nur Linux, sondern auch verschiedene Komponenten.

Jetzt mache ich bereits PostgreSQL. Ich schreibe bereits eine weitere Sache, die es Ihnen ermöglicht, mit PostgreSQL-Statistiken zu arbeiten. Es wird genannt pgCenter (Artikel über Habré - Postgres-Status ohne Nervosität und Anspannung).

Eine kleine Einführung. Wie sind die Situationen mit unseren Kunden, mit unseren Klienten? Es liegt ein Unfall im Zusammenhang mit der Datenbank vor. Und wenn die Datenbank bereits wiederhergestellt ist, kommt der Abteilungsleiter oder der Entwicklungsleiter und sagt: „Freunde, wir sollten die Datenbank überwachen, denn etwas Schlimmes ist passiert und es ist notwendig, dass dies in Zukunft nicht mehr passiert.“ Und hier beginnt der interessante Prozess der Auswahl eines Überwachungssystems oder der Anpassung eines vorhandenen Überwachungssystems, damit Sie Ihre Datenbank überwachen können – PostgreSQL, MySQL oder andere. Und Kollegen beginnen zu bieten: „Ich habe gehört, dass es diese und jene Datenbank gibt. Lasst es uns nutzen.“ Kollegen beginnen miteinander zu streiten. Und am Ende stellt sich heraus, dass wir uns für eine Art Datenbank entscheiden, in der die PostgreSQL-Überwachung jedoch eher dürftig dargestellt ist und wir immer etwas zu Ende bringen müssen. Nehmen Sie einige Repositories von GitHub, klonen Sie sie, passen Sie Skripte an und optimieren Sie sie irgendwie. Und am Ende wird daraus eine Art Handarbeit.

Daher werde ich in diesem Bericht versuchen, Ihnen einige Kenntnisse darüber zu vermitteln, wie Sie die Überwachung nicht nur für PostgreSQL, sondern auch für die Datenbank auswählen. Und Ihnen das Wissen zu vermitteln, das es Ihnen ermöglicht, Ihre Überwachung abzuschließen, um einen Nutzen daraus zu ziehen, sodass Sie Ihre Datenbank mit Nutzen überwachen können, um eventuell auftretende Notsituationen rechtzeitig zu verhindern.

Und diese Ideen, die in diesem Bericht enthalten sind, können direkt an jede Datenbank angepasst werden, sei es ein DBMS oder noSQL. Deshalb geht es hier nicht nur um PostgreSQL, sondern es wird auch viele Rezepte geben, wie man das in PostgreSQL macht. Es wird Beispiele für Abfragen geben, Beispiele für Entitäten, die PostgreSQL zur Überwachung bereithält. Und wenn Ihr DBMS über die gleichen Dinge verfügt, die es Ihnen ermöglichen, sie in die Überwachung zu integrieren, können Sie sie auch anpassen, hinzufügen und schon ist alles in Ordnung.

Ich werde nicht berichten
Sprechen Sie darüber, wie Sie Metriken bereitstellen und speichern. Über die Nachbearbeitung der Daten und deren Bereitstellung an den Nutzer werde ich nichts sagen. Und ich werde nichts über die Alarmierung sagen.
Aber im Laufe der Geschichte werde ich verschiedene Screenshots bestehender Überwachungen zeigen, irgendwie werde ich sie kritisieren. Dennoch werde ich versuchen, keine Marken zu nennen, um keine Werbung oder Anti-Werbung für diese Produkte zu erzeugen. Daher sind alle Zufälle zufällig und bleiben Ihrer Fantasie überlassen.

Lassen Sie uns zunächst verstehen, was Überwachung ist. Überwachung ist eine sehr wichtige Sache. Jeder versteht das. Gleichzeitig ist die Überwachung jedoch nicht mit einem Geschäftsprodukt verbunden und wirkt sich nicht direkt auf den Gewinn des Unternehmens aus, sodass der Überwachung immer eine Restzeit zugewiesen wird. Wenn wir Zeit haben, dann beschäftigen wir uns mit der Überwachung, wenn wir keine Zeit haben, dann OK, wir werden es in den Rückstand aufnehmen und eines Tages werden wir zu diesen Aufgaben zurückkehren.

Wenn wir zu Kunden kommen, ist die Überwachung daher aus unserer Praxis oft unterentwickelt und enthält keine interessanten Dinge, die uns helfen würden, mit der Datenbank bessere Arbeit zu leisten. Und deshalb muss die Überwachung immer abgeschlossen sein.

Datenbanken sind so komplexe Dinge, dass Sie sie auch überwachen müssen, da Datenbanken ein Informationsspeicher sind. Und die Informationen sind für das Unternehmen sehr wichtig, sie dürfen auf keinen Fall verloren gehen. Gleichzeitig sind Datenbanken jedoch sehr komplexe Software. Sie bestehen aus vielen Komponenten. Und viele dieser Komponenten müssen überwacht werden.

Wenn wir speziell über PostgreSQL sprechen, kann es als ein solches Schema dargestellt werden, das aus einer großen Anzahl von Komponenten besteht. Diese Komponenten interagieren miteinander. Gleichzeitig verfügt PostgreSQL über das sogenannte Stats Collector-Subsystem, mit dem Sie Statistiken über den Betrieb dieser Subsysteme sammeln und dem Administrator oder Benutzer eine Schnittstelle bereitstellen können, damit er diese Statistiken anzeigen kann.

Diese Statistiken werden in Form einer Reihe von Funktionen und Ansichten (Ansicht) dargestellt. Sie können auch als Tabellen bezeichnet werden. Das heißt, Sie können mit einem normalen psql-Client eine Verbindung zur Datenbank herstellen, diese Funktionen und Ansichten auswählen und einige spezifische Zahlen zum Betrieb von PostgreSQL-Subsystemen abrufen.

Sie können diese Zahlen zu Ihrem bevorzugten Überwachungssystem hinzufügen, Diagramme zeichnen, Funktionen hinzufügen und langfristig Analysen erhalten.

In diesem Bericht werde ich jedoch nicht ausnahmslos auf alle diese Funktionen eingehen, da dies einen ganzen Tag in Anspruch nehmen kann. Ich beziehe mich buchstäblich auf zwei, drei oder vier Dinge und erzähle Ihnen, wie sie dazu beitragen, die Überwachung zu verbessern.

Und wenn wir über die Überwachung der Datenbank sprechen, was sollte dann überwacht werden? Zunächst müssen wir die Verfügbarkeit überwachen, da die Datenbank ein Dienst ist, der Kunden den Zugriff auf Daten ermöglicht, und wir müssen die Verfügbarkeit überwachen und auch einige ihrer qualitativen und quantitativen Merkmale bereitstellen.

Wir müssen auch die Clients überwachen, die eine Verbindung zu unserer Datenbank herstellen, da es sich sowohl um normale Clients als auch um schädliche Clients handeln kann, die der Datenbank schaden können. Sie müssen auch überwacht und verfolgt werden.

Wenn Clients eine Verbindung zur Datenbank herstellen, ist es offensichtlich, dass sie mit unseren Daten arbeiten. Daher müssen wir überwachen, wie Clients mit Daten arbeiten: mit welchen Tabellen, in geringerem Maße mit welchen Indizes. Das heißt, wir müssen die Arbeitsbelastung bewerten, die durch unsere Kunden entsteht.

Aber der Arbeitsaufwand besteht natürlich auch aus Anfragen. Anwendungen stellen eine Verbindung zur Datenbank her und greifen mithilfe von Abfragen auf Daten zu. Daher ist es wichtig zu bewerten, welche Abfragen wir in der Datenbank haben, ihre Angemessenheit zu überwachen, sicherzustellen, dass sie nicht schief sind, dass einige Optionen neu geschrieben und erstellt werden müssen, damit sie schneller funktionieren und mit besserer Leistung.

Und da wir über die Datenbank sprechen, handelt es sich bei der Datenbank immer um Hintergrundprozesse. Hintergrundprozesse halten die Datenbankleistung auf einem guten Niveau und benötigen daher für ihre Ausführung eine gewisse Menge an Ressourcen. Gleichzeitig können sie sich mit Client-Anforderungsressourcen überschneiden, sodass sich die Gierarbeit von Hintergrundprozessen direkt auf die Leistung von Client-Anfragen auswirken kann. Deshalb müssen sie auch überwacht und nachverfolgt werden, damit es zu keinen Verzerrungen hinsichtlich der Hintergrundprozesse kommt.

Und das ist alles im Hinblick auf die Datenbanküberwachung, die in der Systemmetrik verbleibt. Doch da unsere gesamte Infrastruktur größtenteils in die Cloud geht, geraten die Systemmetriken eines einzelnen Hosts immer in den Hintergrund. Aber in Datenbanken sind sie immer noch relevant und natürlich ist es auch notwendig, Systemmetriken zu überwachen.

Mit Systemmetriken ist alles mehr oder weniger in Ordnung, alle modernen Überwachungssysteme unterstützen diese Metriken bereits, aber im Allgemeinen reichen einige Komponenten noch nicht aus und einige Dinge müssen hinzugefügt werden. Ich werde auch darauf eingehen, mehrere Folien werden sich mit ihnen befassen.

Der erste Punkt des Plans ist die Barrierefreiheit. Was ist Barrierefreiheit? Verfügbarkeit ist in meinem Verständnis die Fähigkeit der Basis, Verbindungen zu bedienen, das heißt, die Basis wird angehoben, sie akzeptiert als Dienst Verbindungen von Kunden. Und diese Zugänglichkeit kann anhand einiger Merkmale beurteilt werden. Diese Merkmale lassen sich sehr komfortabel auf Dashboards anzeigen.

Jeder weiß, was Dashboards sind. Dabei warfen Sie einen Blick auf den Bildschirm, der die notwendigen Informationen zusammenfasste. Und Sie können bereits sofort feststellen, ob ein Problem in der Datenbank vorliegt oder nicht.
Dementsprechend sollten die Verfügbarkeit der Datenbank und andere Schlüsselmerkmale immer auf Dashboards angezeigt werden, damit diese Informationen immer zur Hand sind. Einige zusätzliche Details, die bereits bei der Untersuchung von Vorfällen oder bei der Untersuchung einiger Notfallsituationen hilfreich sind, müssen bereits auf sekundären Dashboards platziert oder in Drilldown-Links versteckt werden, die zu Überwachungssystemen von Drittanbietern führen.

Ein Beispiel für ein bekanntes Überwachungssystem. Dies ist ein sehr cooles Überwachungssystem. Es sammelt viele Daten, hat aber aus meiner Sicht ein seltsames Dashboard-Konzept. Es gibt einen Link „Dashboard erstellen“. Wenn Sie jedoch ein Dashboard erstellen, erstellen Sie eine zweispaltige Liste, eine Liste mit Diagrammen. Und wenn Sie sich etwas ansehen müssen, beginnen Sie mit dem Klicken, Scrollen und der Suche nach dem gewünschten Diagramm mit der Maus. Und das braucht Zeit, d. h. es gibt keine Dashboards als solche. Es gibt nur Listen mit Diagrammen.

Was sollte diesen Dashboards hinzugefügt werden? Sie können mit einem Merkmal wie der Reaktionszeit beginnen. PostgreSQL verfügt über die Ansicht pg_stat_statements. Sie ist standardmäßig deaktiviert, aber sie ist eine der wichtigen Systemansichten, die immer aktiviert und verwendet werden sollte. Es speichert Informationen über alle laufenden Abfragen, die in der Datenbank ausgeführt wurden.

Dementsprechend können wir davon ausgehen, dass wir die gesamte Ausführungszeit aller Anfragen durch die Anzahl der Anfragen dividieren können, indem wir die oben genannten Felder verwenden. Aber das ist so eine durchschnittliche Temperatur im Krankenhaus. Wir können auf anderen Feldern aufbauen – der minimalen Abfrageausführungszeit, dem Maximum und dem Median. Und wir können sogar Perzentile bilden, PostgreSQL hat dafür die entsprechenden Funktionen. Und wir können einige Zahlen erhalten, die die Antwortzeit unserer Datenbank für bereits abgeschlossene Anfragen charakterisieren, d. h. wir führen nicht die gefälschte „Select 1“-Anfrage aus und beobachten die Antwortzeit, sondern wir analysieren die Antwortzeit für bereits abgeschlossene Anfragen und zeichnen entweder eine separate Figur, oder wir erstellen darauf basierend ein Diagramm.

Es ist auch wichtig, den Überblick über die Anzahl der Fehler zu behalten, die das System derzeit generiert. Und dafür können Sie die Ansicht pg_stat_database verwenden. Wir zielen auf das Feld xact_rollback. Dieses Feld zeigt nicht nur die Anzahl der in der Datenbank auftretenden Rollbacks an, sondern berücksichtigt auch die Anzahl der Fehler. Relativ gesehen können wir diese Zahl in unserem Dashboard anzeigen und sehen, wie viele Fehler wir derzeit haben. Wenn es viele Fehler gibt, dann ist das bereits ein guter Grund, in die Protokolle zu schauen, um zu sehen, um welche Art von Fehlern es sich handelt und warum sie auftreten, und dann zu investieren und sie zu beheben.

Sie können so etwas wie einen Drehzahlmesser hinzufügen. Dies sind die Anzahl der Transaktionen pro Sekunde und die Anzahl der Anfragen pro Sekunde. Relativ gesehen können Sie diese Zahlen als aktuelle Leistung Ihrer Datenbank verwenden und beobachten, ob es Spitzen bei Anfragen oder Spitzen bei Transaktionen gibt oder, umgekehrt, die Datenbank unterlastet ist, weil irgendein Backend ausgefallen ist. Es ist wichtig, sich diese Zahl immer anzusehen und sich daran zu erinnern, dass eine solche Leistung für unser Projekt normal ist und die Werte darüber und darunter bereits problematisch und unverständlich sind, was bedeutet, dass wir uns ansehen müssen, warum solche Zahlen .

Um die Anzahl der Transaktionen abzuschätzen, können wir erneut auf die Ansicht pg_stat_database zurückgreifen. Wir können die Anzahl der Commits und die Anzahl der Rollbacks addieren, um die Anzahl der Transaktionen pro Sekunde zu erhalten.

Jeder versteht, dass mehrere Anfragen in eine Transaktion passen können? Daher unterscheiden sich TPS und QPS geringfügig.

Die Anzahl der Anfragen pro Sekunde kann aus pg_stat_statements ermittelt und einfach die Summe aller ausgeführten Anfragen berechnet werden. Es ist klar, dass wir den aktuellen Wert mit dem vorherigen vergleichen, subtrahieren, das Delta ermitteln und den Betrag ermitteln.

Auf Wunsch können Sie weitere Metriken hinzufügen, die ebenfalls dabei helfen, die Verfügbarkeit unserer Datenbank einzuschätzen und zu verfolgen, ob es zu Ausfallzeiten kam.

Eine dieser Kennzahlen ist die Betriebszeit. Aber die Verfügbarkeit in PostgreSQL ist etwas knifflig. Ich sage dir warum. Wenn PostgreSQL gestartet wird, beginnt es mit der Meldung der Betriebszeit. Aber wenn irgendwann, zum Beispiel, eine Aufgabe nachts lief, ein OOM-Killer kam und den untergeordneten PostgreSQL-Prozess zwangsweise beendete, dann beendet PostgreSQL in diesem Fall die Verbindung aller Clients, setzt den Shard-Speicherbereich zurück und beginnt mit der Wiederherstellung der letzte Kontrollpunkt. Und solange diese Wiederherstellung vom Prüfpunkt dauert, akzeptiert die Datenbank keine Verbindungen, d. h. diese Situation kann als Ausfallzeit gewertet werden. Dadurch wird der Betriebszeitzähler jedoch nicht zurückgesetzt, da er die Zeit berücksichtigt, zu der der Postmaster vom ersten Moment an gestartet wurde. Daher können solche Situationen übersprungen werden.

Sie sollten auch die Anzahl der Vakuumarbeiter überwachen. Jeder weiß, was Autovacuum in PostgreSQL ist? Dies ist ein interessantes Subsystem in PostgreSQL. Viele Artikel wurden darüber geschrieben, viele Berichte wurden erstellt. Viele Diskussionen über Vakuum, wie es funktionieren sollte. Viele halten es für ein notwendiges Übel. Aber es ist. Hierbei handelt es sich um eine Art Garbage Collector, der veraltete Versionen von Zeilen bereinigt, die von keiner der Transaktionen benötigt werden, und Platz in Tabellen und Indizes für neue Zeilen freigibt.

Warum sollte es überwacht werden? Denn das Vakuum tut manchmal sehr weh. Es verbraucht eine große Menge an Ressourcen und Kundenanfragen beginnen darunter zu leiden.

Und es sollte über die Ansicht pg_stat_activity überwacht werden, worüber ich im nächsten Abschnitt sprechen werde. Diese Ansicht zeigt die aktuelle Aktivität in der Datenbank. Und durch diese Aktivität können wir die Anzahl der Staubsauger verfolgen, die gerade funktionieren. Wir können Vakuums überwachen und sehen, dass, wenn wir das Limit überschritten haben, dies eine Gelegenheit ist, einen Blick auf die PostgreSQL-Einstellungen zu werfen und den Betrieb des Vakuums irgendwie zu optimieren.

Ein weiteres Merkmal von PostgreSQL ist, dass PostgreSQL lange Transaktionen sehr satt hat. Vor allem bei Transaktionen, die lange hängen bleiben und nichts bewirken. Dabei handelt es sich um die sogenannten Stat-Idle-in-Transaction. Eine solche Transaktion hält Sperren und verhindert, dass das Vakuum funktioniert. Und dadurch schwellen die Tische an, sie werden größer. Und Abfragen, die mit diesen Tabellen arbeiten, beginnen langsamer zu arbeiten, weil Sie alle alten Zeilenversionen vom Speicher auf die Festplatte und zurück schaufeln müssen. Daher müssen auch die Zeit, die Dauer der längsten Transaktionen und die längsten Vakuumanforderungen überwacht werden. И если мы видим какие-то процессы, которые работают уже очень долго, уже больше 10-20-30 минут для OLTP-нагрузки, то на них нужно уже обращать внимание и завершать принудительно, либо оптимизировать приложение, чтобы они не вызывались и не висели so lang. Für eine analytische Belastung sind 10-20-30 Minuten normal, es gibt auch längere.

Als nächstes haben wir die Option mit verbundenen Clients. Wenn wir bereits ein Dashboard erstellt und darin wichtige Kennzahlen zur Barrierefreiheit veröffentlicht haben, können wir dort auch zusätzliche Informationen zu verbundenen Clients hinzufügen.

Die Informationen über verbundene Clients sind wichtig, da es aus Sicht von PostgreSQL verschiedene Arten von Clients gibt. Es gibt gute Kunden und es gibt schlechte Kunden.

Ein einfaches Beispiel. Mit Client meine ich die Anwendung. Die Anwendung hat sich mit der Datenbank verbunden und sendet sofort ihre Anfragen dorthin, die Datenbank verarbeitet und führt sie aus und sendet die Ergebnisse an den Client zurück. Das sind gute und richtige Kunden.

Es gibt Situationen, in denen der Client verbunden ist, die Verbindung aufrechterhält, aber nichts unternimmt. Es befindet sich im Ruhezustand.

Aber es gibt schlechte Kunden. Beispielsweise hat derselbe Client eine Verbindung hergestellt, eine Transaktion eröffnet, etwas in der Datenbank ausgeführt und ist dann in den Code gegangen, um beispielsweise auf eine externe Quelle zuzugreifen oder die empfangenen Daten dort zu verarbeiten. Gleichzeitig schloss er die Transaktion jedoch nicht ab. Und die Transaktion hängt in der Datenbank und hält die Sperre auf der Leitung. Das ist ein schlechter Zustand. Und wenn plötzlich irgendwo in der Anwendung eine Ausnahme (Exception) auftritt, kann die Transaktion sehr lange offen bleiben. Und dies wirkt sich direkt auf die Leistung von PostgreSQL aus. PostgreSQL wird langsamer ausgeführt. Daher ist es wichtig, solche Kunden rechtzeitig zu überwachen und ihre Arbeit gewaltsam zu beenden. Und Sie müssen Ihre Anwendung optimieren, damit solche Situationen nicht auftreten.

Andere schlechte Kunden sind wartende Kunden. Aber sie werden aufgrund der Umstände schlecht. Zum Beispiel eine einfache Leerlauftransaktion: Sie kann eine Transaktion öffnen, einige Zeilen sperren und dann irgendwo im Code landen, sodass eine hängende Transaktion zurückbleibt. Ein anderer Client wird kommen und dieselben Daten anfordern, wird jedoch auf eine Sperre stoßen, da diese hängende Transaktion bereits Sperren für einige erforderliche Zeilen enthält. Und die zweite Transaktion bleibt in Erwartung hängen, wenn die erste Transaktion abgeschlossen ist oder ihr Administrator sie zwangsweise schließt. Daher können sich ausstehende Transaktionen anhäufen und das Datenbankverbindungslimit überschreiten. Und wenn das Limit erreicht ist, kann die Anwendung nicht mehr mit der Datenbank arbeiten. Dies ist bereits eine Notsituation für das Projekt. Daher müssen schlechte Kunden rechtzeitig verfolgt und darauf reagiert werden.

Ein weiteres Beispiel für Überwachung. Und hier ist ein anständiges Dashboard. Es gibt Informationen zu Verbindungen von oben. DB-Anschluss - 8 Stück. Und das ist alles. Wir haben keine Informationen darüber, welche Clients aktiv sind, welche Clients einfach untätig sind und nichts tun. Es gibt keine Informationen über hängende Transaktionen und ausstehende Verbindungen, d. h. dies ist eine Zahl, die die Anzahl der Verbindungen anzeigt, und das war's. Und dann raten Sie selbst.

Um diese Informationen zur Überwachung hinzuzufügen, müssen Sie sich dementsprechend auf die Systemansicht pg_stat_activity beziehen. Wenn Sie viel Zeit in PostgreSQL verbringen, dann ist dies eine sehr gute Ansicht, die Ihr Freund werden sollte, denn sie zeigt die aktuelle Aktivität in PostgreSQL, also was darin passiert. Für jeden Prozess gibt es eine eigene Zeile, die Informationen zu diesem Prozess anzeigt: Von welchem ​​Host aus wurde die Verbindung hergestellt, unter welchem ​​Benutzer, unter welchem ​​Namen, wann wurde die Transaktion gestartet, welche Anfrage wird gerade ausgeführt, welche Anfrage wurde zuletzt ausgeführt. Und dementsprechend können wir den Status des Clients anhand des Statistikfelds bewerten. Relativ gesehen können wir nach diesem Feld gruppieren und die Statistiken abrufen, die sich jetzt in der Datenbank befinden, sowie die Anzahl der Verbindungen, die mit dieser Statistik in der Datenbank bestehen. Und wir können die bereits empfangenen Zahlen an unser Monitoring senden und darauf Diagramme zeichnen.
Es ist auch wichtig, die Dauer der Transaktion zu bewerten. Ich habe bereits gesagt, dass es wichtig ist, die Dauer von Vakuumphasen zu bewerten, aber auch Transaktionen werden auf die gleiche Weise bewertet. Es gibt die Felder xact_start und query_start. Sie zeigen relativ gesehen die Startzeit der Transaktion und die Startzeit der Anfrage. Wir nehmen die Funktion now(), die den aktuellen Zeitstempel anzeigt, und subtrahieren die Transaktions- und Anforderungszeitstempel. Und wir erhalten die Dauer der Transaktion, die Dauer der Anfrage.

Wenn wir lange Transaktionen sehen, sollten wir diese bereits abschließen. Bei einer OLTP-Last dauern lange Transaktionen bereits mehr als 1-2-3 Minuten. Bei einer OLAP-Last sind lange Transaktionen normal, aber wenn sie länger als zwei Stunden laufen, dann ist das auch ein Zeichen dafür, dass wir irgendwo einen Skew haben.

Sobald sich die Kunden mit der Datenbank verbunden haben, beginnen sie mit der Arbeit mit unseren Daten. Sie greifen auf Tabellen zu, sie greifen auf Indizes zu, um Daten aus einer Tabelle abzurufen. Und es ist wichtig zu bewerten, wie Kunden mit diesen Daten umgehen.

Dies ist notwendig, um unsere Arbeitsbelastung einzuschätzen und ungefähr zu verstehen, welche Tische wir am „heißesten“ haben. Dies ist beispielsweise in Situationen erforderlich, in denen wir „heiße“ Tabellen auf einem schnellen SSD-Speicher platzieren möchten. Beispielsweise können einige Archivtabellen, die wir längere Zeit nicht verwendet haben, in eine Art „kaltes“ Archiv, auf SATA-Festplatten, übertragen und dort leben gelassen werden, sodass bei Bedarf auf sie zugegriffen werden kann.

Es ist auch nützlich, um Anomalien nach Releases und Bereitstellungen zu erkennen. Nehmen wir an, das Projekt hat eine neue Funktion eingeführt. Beispielsweise haben wir neue Funktionen für die Arbeit mit der Datenbank hinzugefügt. Und wenn wir Diagramme zur Verwendung in Tabellen erstellen, können wir diese Anomalien in diesen Diagrammen leicht erkennen. Aktualisieren Sie beispielsweise Bursts oder löschen Sie Bursts. Es wird sehr sichtbar sein.

Es ist auch möglich, Anomalien von „floatierten“ Statistiken zu erkennen. Was bedeutet das? PostgreSQL verfügt über einen sehr starken und sehr guten Abfrageplaner. Und die Entwickler widmen seiner Entwicklung viel Zeit. Wie funktioniert er? Um gute Pläne zu erstellen, sammelt PostgreSQL in einem bestimmten Zeitintervall und mit einer gewissen Periodizität Statistiken über die Verteilung von Daten in Tabellen. Dies sind die häufigsten Werte: die Anzahl der eindeutigen Werte, Informationen über NULL in der Tabelle, viele Informationen.

Basierend auf diesen Statistiken erstellt der Planer mehrere Abfragen, wählt die optimalste aus und verwendet diesen Abfrageplan, um die Abfrage selbst auszuführen und Daten zurückzugeben.

Und es kommt vor, dass die Statistik „schwebt“. Die Qualitäts- und Quantitätsdaten in der Tabelle haben sich irgendwie geändert, aber die Statistiken wurden nicht erfasst. Und die erstellten Pläne sind möglicherweise nicht optimal. Und wenn sich herausstellt, dass unsere Pläne hinsichtlich der erfassten Überwachung gemäß den Tabellen nicht optimal sind, werden wir diese Anomalien erkennen können. Irgendwo änderten sich beispielsweise die Daten qualitativ und anstelle des Index begann man, einen sequentiellen Durchlauf durch die Tabelle zu verwenden, d.h. Wenn die Abfrage nur 100 Zeilen zurückgeben muss (es gibt eine Grenze von 100), wird für diese Abfrage eine vollständige Aufzählung durchgeführt. Und das wirkt sich immer sehr negativ auf die Leistung aus.

Und wir können es in der Überwachung sehen. Und schon schauen Sie sich diese Abfrage an, führen eine Erklärung dafür durch, sammeln Statistiken und erstellen einen neuen zusätzlichen Index. Und reagieren Sie bereits auf dieses Problem. Deshalb ist es wichtig.

Ein weiteres Beispiel für Überwachung. Ich denke, viele Leute erkennen ihn, weil er sehr beliebt ist. Wer verwendet in seinen Projekten Prometheus? Und wer verwendet dieses Produkt in Verbindung mit Prometheus? Tatsache ist, dass es im Standard-Repository dieser Überwachung ein Dashboard für die Arbeit mit PostgreSQL gibt - postgres_exporter Prometheus. Aber hier gibt es ein schlechtes Detail.

Es gibt mehrere Diagramme. Und Bytes werden als Einheit angegeben, d. h. es gibt 5 Diagramme. Dies sind Daten einfügen, Daten aktualisieren, Daten löschen, Daten abrufen und Daten zurückgeben. Als Einheitsdimension werden Bytes angegeben. Tatsache ist jedoch, dass Statistiken in PostgreSQL Daten in Tupeln (Zeilen) zurückgeben. Und dementsprechend sind diese Diagramme eine sehr gute Möglichkeit, Ihre Arbeitsbelastung mehrmals, Dutzende Male zu unterschätzen, denn ein Tupel ist kein Byte, ein Tupel ist ein String, es sind viele Bytes und die Länge ist immer variabel. Das heißt, die Berechnung der Arbeitslast in Bytes mithilfe von Tupeln ist eine unrealistische oder sehr schwierige Aufgabe. Wenn Sie ein Dashboard oder ein integriertes Monitoring verwenden, ist es daher immer wichtig zu verstehen, dass es ordnungsgemäß funktioniert und Ihnen korrekt ausgewertete Daten zurückgibt.

Wie erhalte ich Statistiken zu diesen Tabellen? Zu diesem Zweck verfügt PostgreSQL über eine Familie von Ansichten. Und die Hauptansicht ist pg_stat_user_tables. User_tables – das bedeutet, dass die Tabellen im Namen des Benutzers erstellt werden. Im Gegensatz dazu gibt es Systemansichten, die von PostgreSQL selbst verwendet werden. Und es gibt eine Übersichtstabelle Alltables, die sowohl System als auch Benutzer umfasst. Sie können mit jedem davon beginnen, der Ihnen am besten gefällt.

Die oben genannten Felder können verwendet werden, um die Anzahl der Einfügungen, Aktualisierungen und Löschungen abzuschätzen. Das von mir verwendete Beispiel-Dashboard verwendet diese Felder, um die Merkmale der Arbeitslast auszuwerten. Deshalb können wir auch darauf aufbauen. Es sei jedoch daran erinnert, dass es sich hierbei um Tupel und nicht um Bytes handelt, sodass wir daraus keine Bytes machen können.

Basierend auf diesen Daten können wir die sogenannten TopN-Tabellen erstellen. Zum Beispiel Top-5, Top-10. Und Sie können den Überblick über die Hot Tables behalten, die häufiger genutzt werden als andere. Zum Beispiel 5 „heiße“ Tabellen zum Einfügen. Und anhand dieser TopN-Tabellen bewerten wir unsere Arbeitslast und können Arbeitslastspitzen nach Veröffentlichungen, Updates und Bereitstellungen bewerten.

Es ist auch wichtig, die Größe der Tabelle zu bewerten, da Entwickler manchmal eine neue Funktion einführen und unsere Tabellen anfangen, in ihrer Größe anzuschwellen, weil sie beschlossen haben, eine zusätzliche Datenmenge hinzuzufügen, aber nicht vorhergesehen haben, wie dies geschehen würde wirken sich auf die Größe der Datenbank aus. Auch für uns kommen solche Fälle überraschend.

Und jetzt eine kleine Frage an Sie. Was ist die Frage, wenn Sie die Auslastung des Datenbankservers bemerken? Was ist Ihre nächste Frage?

Aber die eigentliche Frage ist die folgende. Welche Anfragen verursacht die Last? Das heißt, es ist nicht interessant, die Prozesse zu beobachten, die die Last verursacht. Es ist klar, dass, wenn sich der Host auf einer Datenbank befindet, die Datenbank dort ausgeführt wird, und es ist klar, dass dort nur Datenbanken gelöscht werden. Wenn wir Top öffnen, sehen wir dort eine Liste der PostgreSQL-Prozesse, die etwas tun. Von oben wird nicht klar sein, was sie tun.

Dementsprechend müssen Sie die Abfragen finden, die die meiste Last verursachen, da die Abfrageoptimierung in der Regel mehr Gewinn bringt als die PostgreSQL-Konfiguration oder die Optimierung des Betriebssystems oder sogar der Hardwareoptimierung. Nach meiner Schätzung sind es etwa 80-85-90 %. Und das geht viel schneller. Es ist schneller, die Anfrage zu korrigieren, als die Konfiguration zu korrigieren, einen Neustart zu planen, insbesondere wenn die Datenbank nicht neu gestartet werden kann, oder Hardware hinzuzufügen. Es ist einfacher, die Abfrage irgendwo umzuschreiben oder einen Index hinzuzufügen, um ein besseres Ergebnis aus dieser Abfrage zu erhalten.

Dementsprechend ist es notwendig, die Anfragen und deren Angemessenheit zu überwachen. Nehmen wir ein weiteres Beispiel für die Überwachung. Und auch hier scheint es eine hervorragende Überwachung zu geben. Es gibt Informationen zur Replikation, es gibt Informationen zu Durchsatz, Blockierung und Ressourcennutzung. Alles ist in Ordnung, aber es gibt keine Informationen zu Anfragen. Es ist nicht klar, welche Abfragen in unserer Datenbank ausgeführt werden, wie lange sie ausgeführt werden und wie viele dieser Abfragen. Wir müssen diese Informationen immer im Monitoring haben.

Und um diese Informationen zu erhalten, können wir das Modul pg_stat_statements verwenden. Auf dieser Basis können Sie eine Vielzahl von Grafiken erstellen. Sie können beispielsweise Informationen zu den häufigsten Anfragen erhalten, also zu den Anfragen, die am häufigsten ausgeführt werden. Ja, nach der Bereitstellung ist es auch sehr nützlich, einen Blick darauf zu werfen und zu verstehen, ob es zu einem Anstieg der Anfragen kommt.

Sie können die längsten Anfragen überwachen, d. h. die Anfragen, deren Ausführung am längsten dauert. Sie laufen auf dem Prozessor und verbrauchen I/O. Wir können dies auch anhand der Felder total_time, mean_time, blk_write_time und blk_read_time auswerten.

Wir können die anspruchsvollsten Anforderungen hinsichtlich der Ressourcennutzung auswerten und überwachen, diejenigen, die von der Festplatte lesen, diejenigen, die mit dem Speicher arbeiten oder im Gegenteil eine Art Schreiblast erzeugen.

Wir können die großzügigsten Anfragen bewerten. Dies sind Abfragen, die eine große Anzahl von Zeilen zurückgeben. Beispielsweise kann es sich um eine Anfrage handeln, bei der vergessen wurde, ein Limit festzulegen. Und es gibt einfach den gesamten Inhalt der Tabelle oder Abfrage für die angeforderten Tabellen zurück.

Und Sie können auch Abfragen überwachen, die temporäre Dateien oder temporäre Tabellen verwenden.

Und wir haben immer noch Hintergrundprozesse. Hintergrundprozesse sind in erster Linie Checkpoints oder werden auch Checkpoints genannt, das sind Autovacuum und Replikation.

Ein weiteres Beispiel für Überwachung. Auf der linken Seite befindet sich die Registerkarte „Wartung“. Gehen Sie dorthin und hoffen Sie, etwas Nützliches zu sehen. Aber hier nur die Zeit des Vakuums und des Sammelns von Statistiken, sonst nichts. Dies sind sehr dürftige Informationen, daher müssen Sie immer Informationen darüber haben, wie Hintergrundprozesse in unserer Datenbank funktionieren und ob bei ihrer Arbeit Probleme auftreten.

Wenn wir uns Prüfpunkte ansehen, sollten wir bedenken, dass unsere Prüfpunkte „schmutzige“ Seiten aus dem Shard-Speicherbereich auf die Festplatte leeren und dann einen Prüfpunkt erstellen. Und dieser Checkpoint kann bereits als Ort während der Wiederherstellung genutzt werden, wenn PostgreSQL im Notfall plötzlich beendet wurde.

Um alle „schmutzigen“ Seiten auf die Festplatte zu löschen, müssen Sie daher eine bestimmte Menge an Schreibvorgängen ausführen. Und auf Systemen mit viel Speicher ist das in der Regel eine ganze Menge. Und wenn wir in kurzen Abständen sehr oft Prüfpunkte durchführen, sinkt die Festplattenleistung erheblich. Und Kundenanfragen werden unter einem Mangel an Ressourcen leiden. Sie werden um Ressourcen konkurrieren und es mangelt ihnen an Produktivität.

Dementsprechend können wir über pg_stat_bgwriter in den angegebenen Feldern die Anzahl der auftretenden Prüfpunkte überwachen. Und wenn wir für einen bestimmten Zeitraum (für 10-15-20 Minuten, für eine halbe Stunde) viele Kontrollpunkte haben, zum Beispiel 3-4-5, dann kann das schon ein Problem sein. Und Sie müssen bereits in der Datenbank und in der Konfiguration nachsehen, was eine solche Fülle an Prüfpunkten verursacht. Vielleicht kommt eine große Platte. Wir können die Auslastung bereits auswerten, da wir bereits Auslastungsdiagramme hinzugefügt haben. Wir können die Haltepunktparameter bereits optimieren und sicherstellen, dass sie die Abfrageleistung nicht stark beeinträchtigen.

Ich kehre noch einmal zum Autovacuum zurück, weil es sich, wie gesagt, um etwas handelt, das sowohl die Festplatten- als auch die Abfrageleistung leicht addieren kann. Daher ist es immer wichtig, die Menge des Autovacuums zu messen.

Die Anzahl der Autovakuumarbeiter in der Datenbank ist begrenzt. Standardmäßig gibt es drei davon. Wenn also ständig drei Arbeiter in der Datenbank arbeiten, bedeutet dies, dass unser Autovacuum unterkonfiguriert ist. Wir müssen die Grenzwerte erhöhen, die Autovacuum-Einstellungen überarbeiten und bereits in die Konfiguration einsteigen.
Es ist wichtig zu bewerten, welche Vakuumarbeiter für uns arbeiten. Entweder wurde es vom Benutzer gestartet, der DBA kam herein und erzeugte mit seinen Händen eine Art Vakuum, was eine Last erzeugte. Wir haben ein Problem. Oder das ist die Anzahl der Vakuums, die den Transaktionszähler ausschrauben. Bei einigen Versionen von PostgreSQL handelt es sich um sehr schwere Lücken. Und sie können die Leistung leicht steigern, da sie die gesamte Tabelle subtrahieren und alle Blöcke in dieser Tabelle scannen.

Und natürlich die Dauer des Vakuums. Wenn wir lange Staubsauger haben, die sehr lange laufen, dann bedeutet das, dass wir noch einmal auf die Konfiguration des Staubsaugers achten und vielleicht seine Einstellungen überdenken sollten. Denn es kann vorkommen, dass das Vakuum über einen längeren Zeitraum (3-4 Stunden) auf dem Tisch arbeitet, sich aber während der Vakuumarbeit erneut eine große Menge toter Zeilen im Tisch ansammelt. Und sobald das Staubsaugen vorbei ist, muss er diesen Tisch erneut saugen. Und wir kommen zu einer Situation – einem unendlichen Vakuum. Und in diesem Fall wird das Vakuum seiner Arbeit nicht gerecht und die Tabellen beginnen allmählich an Größe zuzunehmen, obwohl die Menge der darin enthaltenen nützlichen Daten gleich bleibt. Deshalb schauen wir uns in langen Vakuumphasen immer die Konfiguration an und versuchen, sie zu optimieren, aber gleichzeitig, damit die Leistung der Client-Anfragen nicht leidet.

Mittlerweile gibt es praktisch keine PostgreSQL-Installation, bei der es keine Streaming-Replikation gab. Bei der Replikation werden Daten von einem Master auf ein Replikat übertragen.

Die Replikation in PostgreSQL wird über ein Transaktionsprotokoll organisiert. Der Master generiert ein Transaktionsprotokoll. Das Transaktionsprotokoll der Netzwerkverbindung geht an das Replikat und wird dann auf dem Replikat reproduziert. Alles ist einfach.

Dementsprechend wird die pg_stat_replication-Ansicht verwendet, um die Replikationsverzögerung zu überwachen. Aber es ist nicht einfach für sie. In Version 10 hat die Ansicht mehrere Änderungen erfahren. Zunächst wurden einige Felder umbenannt. Und einige der Felder wurden hinzugefügt. In der 10. Version erschienen Felder, mit denen Sie die Replikationsverzögerung in Sekunden auswerten können. Es ist sehr bequem. Vor Version 10 war es möglich, die Replikationsverzögerung in Bytes abzuschätzen. Diese Funktion blieb in der 10. Version erhalten, d.h. Sie können wählen, was für Sie bequemer ist – die Verzögerung in Bytes auswerten oder die Verzögerung in Sekunden auswerten. Viele machen beides.

Um die Replikationsverzögerung beurteilen zu können, müssen Sie jedoch die Position des Protokolls in der Transaktion kennen. Und diese Positionen des Transaktionsprotokolls befinden sich nur in der Ansicht pg_stat_replication. Relativ gesehen können wir die Funktion pg_xlog_location_diff() verwenden, um zwei Punkte im Transaktionsprotokoll zu erfassen. Berechnen Sie das Delta zwischen ihnen und erhalten Sie die Replikationsverzögerung in Bytes. Es ist sehr praktisch und einfach.

In Version 10 wurde diese Funktion in pg_wal_lsn_diff() umbenannt. Im Allgemeinen wurde in allen Funktionen, Ansichten und Dienstprogrammen, in denen das Wort „xlog“ vorkam, es durch den Wert „wal“ ersetzt. Dies gilt sowohl für Ansichten als auch für Funktionen. Das ist so eine Innovation.

Außerdem wurden in der 10. Version Zeilen hinzugefügt, die speziell die Verzögerung zeigen. Dies sind Schreibverzögerung, Flush-Verzögerung und Wiedergabeverzögerung. Das heißt, es ist wichtig, diese Dinge zu überwachen. Wenn wir feststellen, dass wir eine Replikationsverzögerung haben, müssen wir untersuchen, warum sie aufgetreten ist und woher sie kommt, und das Problem beheben.

Bei den Systemmetriken ist fast alles in Ordnung. Wenn eine Überwachung entsteht, beginnt sie mit Systemmetriken. Dabei handelt es sich um die Auslastung von Prozessoren, Speicher, Swap, Netzwerk und Festplatte. Dennoch sind viele Parameter nicht standardmäßig vorhanden.

Wenn bei der Entsorgung des Prozesses alles in Ordnung ist, dann gibt es Probleme bei der Entsorgung der Platte. In der Regel fügen Überwachungsentwickler Bandbreiteninformationen hinzu. Es kann in Iops oder Bytes angegeben werden. Aber sie vergessen die Latenz und die Auslastung der Festplattengeräte. Dies sind wichtigere Parameter, anhand derer wir beurteilen können, wie ausgelastet unsere Festplatten sind und wie stark sie langsamer werden. Wenn wir eine hohe Latenz haben, bedeutet das, dass es Probleme mit den Festplatten gibt. Wenn wir eine hohe Auslastung haben, bedeutet dies, dass die Festplatten nicht damit zurechtkommen. Dabei handelt es sich eher um qualitative Merkmale als um Bandbreite.

Diese Statistiken können jedoch auch aus dem /proc-Dateisystem abgerufen werden, wie dies beim Prozessor-Recycling der Fall ist. Warum diese Informationen nicht in die Überwachung einfließen, weiß ich nicht. Aber es ist immer noch wichtig, es in Ihrer Überwachung zu haben.

Das Gleiche gilt für Netzwerkschnittstellen. Es gibt Informationen zur Netzwerkbandbreite in Paketen, in Bytes, aber dennoch keine Informationen zur Latenz und keine Informationen zur Auslastung, obwohl dies ebenfalls nützliche Informationen sind.

Jede Überwachung hat ihre Nachteile. Und egal welche Art von Überwachung Sie wählen, bestimmte Kriterien werden immer nicht erfüllt. Aber dennoch entwickeln sie sich weiter, es kommen neue Funktionen hinzu, neue Dinge, also wählen Sie etwas aus und beenden Sie es.

Und zum Abschluss müssen Sie immer eine Vorstellung davon haben, was die angegebenen Statistiken bedeuten und wie Sie damit Probleme lösen können.

Und ein paar wichtige Punkte:

• Sie müssen die Verfügbarkeit immer überwachen und über Dashboards verfügen, damit Sie schnell beurteilen können, ob mit der Basis alles in Ordnung ist.
• Sie müssen immer eine Vorstellung davon haben, welche Clients mit Ihrer Datenbank arbeiten, um schlechte Clients auszusortieren und zu erschießen.
• Es ist wichtig zu bewerten, wie diese Kunden mit Daten arbeiten. Sie müssen eine Vorstellung von Ihrem Arbeitsaufwand haben.
• Es ist wichtig zu bewerten, wie diese Arbeitslast mit Hilfe welcher Abfragen entsteht. Sie können Abfragen auswerten, optimieren, umgestalten und Indizes für sie erstellen. Es ist sehr wichtig.
• Hintergrundprozesse können sich negativ auf Kundenanfragen auswirken. Daher ist es wichtig sicherzustellen, dass sie nicht zu viele Ressourcen verbrauchen.
• Mithilfe von Systemmetriken können Sie Pläne für die Skalierung und Erhöhung der Kapazität Ihrer Server erstellen. Daher ist es wichtig, diese auch zu verfolgen und auszuwerten.

Wenn Sie sich für dieses Thema interessieren, können Sie diesen Links folgen.
http://bit.do/stats_collector ist die offizielle Dokumentation des Statistiksammlers. Es gibt eine Beschreibung aller Statistikansichten und eine Beschreibung aller Felder. Sie können sie lesen, verstehen und analysieren. Erstellen Sie auf dieser Grundlage Ihre eigenen Diagramme und ergänzen Sie Ihre Überwachung.

Anfragebeispiele:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Dies ist unser Unternehmens-Repository und mein eigenes. Sie haben Musteranfragen. Es gibt keine Abfragen aus der Serie „select* from“, so etwas. Es gibt bereits vorgefertigte Anfragen mit Verknüpfungen, die interessante Funktionen verwenden, mit denen Sie aus Rohzahlen, also Bytes und Zeit, lesbare, praktische Werte erstellen können. Sie können sie auswählen, beobachten, analysieren, zu Ihren Überwachungen hinzufügen und darauf basierend Ihre eigenen Überwachungen erstellen.

Fragen

Frage: Sie haben gesagt, dass Sie keine Werbung für Marken machen würden, aber ich frage mich immer noch: Welche Art von Dashboards verwenden Sie in Ihren Projekten?
Antwort: Auf unterschiedliche Weise. Es kommt vor, dass wir zum Kunden kommen und er bereits über eine eigene Überwachung verfügt. Und wir beraten den Kunden, was zu seiner Überwachung hinzugefügt werden muss. Die schlimmste Situation ist bei Zabbix. Weil es nicht in der Lage ist, TopN-Grafiken zu erstellen. Wir selbst nutzen Okmeterweil wir diese Leute zur Überwachung konsultiert haben. Sie führten eine PostgreSQL-Überwachung basierend auf unserem TOR durch. Ich schreibe mein eigenes Lieblingsprojekt, das über Prometheus Daten sammelt und einspeist Grafana. Meine Aufgabe ist es, in Prometheus meinen eigenen Exporter zu erstellen und dann alles in Grafana zu zeichnen.

Frage: Gibt es Analogien zu AWR-Berichten oder ... Aggregationen? Ist Ihnen so etwas bekannt?
Antwort: Ja, ich weiß, was AWR ist, es ist eine coole Sache. Derzeit gibt es eine Vielzahl von Fahrrädern, die in etwa das folgende Modell umsetzen. In bestimmten Zeitabständen werden einige Baselines in dasselbe PostgreSQL oder in einen separaten Speicher geschrieben. Sie können sie im Internet googeln, das sind sie. Einer der Entwickler so etwas sitzt im sql.ru-Forum im PostgreSQL-Thread. Dort kannst du ihn fangen. Ja, solche Dinge gibt es, man kann sie nutzen. plus in seinem pgCenter Ich schreibe auch etwas, das es Ihnen ermöglicht, dasselbe zu tun.

PS1 Wenn Sie postgres_exporter verwenden, welches Dashboard verwenden Sie? Es gibt mehrere davon. Sie sind bereits veraltet. Kann die Community eine aktualisierte Vorlage erstellen?

PS2 pganalyze wurde entfernt, da es sich um ein proprietäres SaaS-Angebot handelt, das sich auf Leistungsüberwachung und automatisierte Optimierungsvorschläge konzentriert.

An der Umfrage können nur registrierte Benutzer teilnehmen. Einloggenbitte.

Welche selbst gehostete PostgreSQL-Überwachung (mit Dashboard) ist Ihrer Meinung nach die beste?

• 30,0%Zabbix + Ergänzungen von Alexey Lesovsky oder Zabbix 4.4 oder libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze ist ein proprietäres SaaS – kann nicht gelöscht werden1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

10 Benutzer haben abgestimmt. 26 Benutzer enthielten sich der Stimme.

Source: habr.com