Geekly articles weekly

Neue Postgres_exporter PostgreSQL-Überwachungsfunktionen

Guten Tag, liebe Leser!


In der ersten Anmerkung zu posgres_exporter habe ich einen ziemlich speziellen Fall bei der Arbeit mit einer neuen Fitcha untersucht, nämlich die Möglichkeit, eine Reihe von Instanzen und / oder Datenbanken von einem Exporteur zu überwachen. Und er beschrieb die „Menge“ Probleme, auf die er gestoßen war und welche Problemumgehungen er benutzte, um es zum Laufen zu bringen.
Und so wurde am 25. November die nächste Version von postgres_exporter 0.8.0 veröffentlicht. Es hat die im vorherigen Beitrag beschriebenen Probleme gelöst und, was besonders schön ist, neue Funktionen hinzugefügt.


Ich bitte um eine Katze ...


Zunächst möchte ich Ihnen postgre_exporter näher vorstellen und eine Art kurze Kurzanleitung schreiben. Gehen wir die wichtigsten Punkte durch:


  1. Umgebungsvariablen und Startparameter
  2. Was sind Standardmetriken?
  3. So fügen Sie Ihre eigenen Metriken hinzu

Beschreibung


postgres_exporter - Ein Dienstprogramm zum Erfassen von Metriken aus Instanzen eines PostgreSQL-DBMS-Clusters in einem barrierefreien Prometheus-Format, das in Go geschrieben wurde, ist Open Source und wird kostenlos vertrieben.


Umgebungsvariablen und Befehlszeilenargumente


Postgres_exporter verfügt als solches nicht über eine Konfigurationsdatei, und alle Parameter werden entweder über Umgebungsvariablen oder über Befehlszeilenargumente an den Exporter übergeben. Gleichzeitig können die Parameter für die Verbindung zum DBMS nur über Umgebungsvariablen übertragen werden.


Umgebungsvariablen


Wie oben erwähnt, können Umgebungsvariablen in zwei Gruppen unterteilt werden. Ersterer übergibt die Verbindungszeichenfolge, letzterer dupliziert die Befehlszeilenargumente.


Beginnen wir mit der ersten Gruppe. Diese Variablen beginnen mit dem Präfix DATA_SOURCE_ :


  • DATA_SOURCE_NAME - wird standardmäßig verwendet. Ermöglicht die Aufzeichnung der Verbindungszeichenfolge im Format = und in Form eines URI und kann den Anmeldenamen und das Kennwort der Verbindung enthalten.
    Gültige Joboptionen für die Verbindung mit PostgreSQL:


    • postgresql://rolename@dbhost:dbport/datname?sslmode=disable ;
    • postgresql://rolename:rolpass@dbhost:dbport?sslmode=disable&db=datname ;
    • postgresql://rolename:rolpass@?sslmode=disable&dbname=database&host=dbhost&port=dbport ;
    • postgresql://rolename:rolpass@?sslmode=disable&dbname=database&host=/tmp (Verbindung über einen UNIX-Socket aus den unix_socket_directories einer PostgreSQL-Instanz);
    • host=dbhost port=dbport dbname=database user=rolename sslmode=disable ;

    Wenn Sie eine Verbindung zu mehreren Instanzen herstellen müssen (ein Leerzeichen nach dem Komma ist nicht zulässig):


    • postgresql://rolename@dbhost:dbport/datname?sslmode=disable,postgresql://rolename@dbhost:dbport/datname?sslmode=disable ;
    • sslmode=disable dbname=postgres host=127.0.0.1 port=5434 user=postgres,sslmode=disable dbname=postgres port=5432 user=postgres .

  • DATA_SOURCE_URI - Alternative zu DATA_SOURCE_NAME. Diese Option ist nur geeignet, wenn Sie beabsichtigen, eine Verbindung zu einer einzelnen Instanz von PostgreSQL herzustellen.
    Die Variable DATA_SOURCE_URI legt den Teil der URI ohne Benutzernamen und Kennwort in der Form "dbhost: dbport / dbname? Key = value" fest. Der Benutzername und das Kennwort stammen aus den Umgebungsvariablen DATA_SOURCE_USER und DATA_SOURCE_PASS oder aus den Dateien DATA_SOURCE_USER_FILE DATA_SOURCE_PASS_FILE.
    Wenn der Benutzername und das Kennwort in Dateien gespeichert werden, werden deren Inhalte extrahiert und den Variablen DATA_SOURCE_USER und DATA_SOURCE_PASS zugewiesen. Im Code wird all dies in einem vollständigen URI der Form "postgresql://" + DATA_SOURCE_USER + ":" + DATA_SOURCE_PASS + "@" + DATA_SOURCE_URI
  • DATA_SOURCE_URI_FILE - Entspricht DATA_SOURCE_URI und wird nur aus der Datei gelesen.
  • DATA_SOURCE_USER - Legt bei Verwendung von DATA_SOURCE_URI den Benutzernamen für die Verbindung zum DBMS fest.
  • DATA_SOURCE_USER_FILE - Entspricht DATA_SOURCE_USER und wird nur aus der Datei gelesen.
  • DATA_SOURCE_PASS - Legt bei Verwendung von DATA_SOURCE_URI das Benutzerkennwort für die Verbindung zum DBMS fest.
  • DATA_SOURCE_PASS_FILE - Entspricht DATA_SOURCE_PASS und wird nur aus der Datei gelesen.

Die zweite Gruppe enthält variable doppelte Argumente. Das heißt beim Start haben Sie die Wahl, legen die Betriebsparameter der Anwendung in Form von Umgebungsvariablen fest oder übergeben sie beim Start als Argumente. Beginnen Sie mit dem Präfix PG_EXPORTER_ :


  • PG_EXPORTER_WEB_LISTEN_ADDRESS - Legt die Adresse und den Port fest, über den der Exporteur Anfragen von Prometheus erhält. Standardmäßig :9187 ;
  • PG_EXPORTER_WEB_TELEMETRY_PATH - Der Pfad, entlang dem Metriken angegeben werden. Standardmäßig /metrics ;
  • PG_EXPORTER_DISABLE_DEFAULT_METRICS - deaktiviert standardmäßig die Erfassung von Metriken. Die Tatsache, dass diese Metriken unten sein werden. Nur wahr oder falsch akzeptiert Werte. Standardmäßig "False" (Erfassung von Metriken ist zulässig);
  • PG_EXPORTER_DISABLE_SETTINGS_METRICS - Deaktiviert die Erfassung von Metriken in der Ansicht pg_settings. Die Tatsache, dass diese Metriken unten sein werden. Nur wahr oder falsch akzeptiert Werte. Standardmäßig "False" (Erfassung von Metriken ist zulässig);
  • PG_EXPORTER_AUTO_DISCOVER_DATABASES - Erkennt alle Datenbanken einer Cluster-Instanz, um ihre Metriken zu erfassen. Nur wahr oder falsch akzeptiert Werte. Standardmäßig false (Metriken werden nur in der Datenbank erfasst, die in den Verbindungsparametern angegeben wurde).
  • PG_EXPORTER_EXCLUDE_DATABASES - Schließt die Datenbank aus der Liste der Datenbanken aus, für die Metriken erfasst werden, wenn PG_EXPORTER_AUTO_DISCOVER_DATABASES=true . Stellt eine durch Kommas getrennte Liste von Datenbanknamen dar. Der Standardwert ist eine leere Zeichenfolge. WICHTIG :
    • templates template0 und template1 - müssen nicht ausgeschlossen werden, daher werden sie abgeschnitten, wenn eine Liste von Datenbanken aus pg_databases abgerufen wird.
    • kann die in der URI angegebene Datenbank nicht ausschließen.
  • PG_EXPORTER_EXTEND_QUERY_PATH - Der Pfad zur YAML-Datei, die Benutzerabfragen enthält. Die Datei queries.yaml enthält Beispiele.
  • PG_EXPORTER_CONSTANT_LABELS - Allen Metriken wurde eine Bezeichnung (Konstante) hinzugefügt. Es wird als Liste von Paaren = , die durch ein Komma getrennt sind.

Befehlszeilenargumente


  • Die web.listen-Adresse ist dieselbe wie PG_EXPORTER_WEB_LISTEN_ADDRESS.
  • web.telemetry-path - das gleiche wie PG_EXPORTER_WEB_TELEMETRY_PATH;
  • disable-default-metrics ist dasselbe wie PG_EXPORTER_DISABLE_DEFAULT_METRICS.
  • Disable-Settings-Metrics sind die gleichen wie PG_EXPORTER_DISABLE_SETTINGS_METRICS.
  • Auto-Discovery-Datenbanken sind mit PG_EXPORTER_AUTO_DISCOVER_DATABASES identisch.
  • exclude-databases ist dasselbe wie PG_EXPORTER_EXCLUDE_DATABASES;
  • extend.query-path - das gleiche wie PG_EXPORTER_EXTEND_QUERY_PATH;
  • constantLabels - das gleiche wie PG_EXPORTER_CONSTANT_LABELS;
  • dumpmaps - Zeigt den internen Inhalt der Metrikkarte an. Wird zum Debuggen von Benutzeranforderungen verwendet. Startet die Anwendung nicht.
  • log.level - Legt eine der möglichen Protokollierungsstufen fest: debug , info , warn , error , fatal ;
  • log.format - Legt die Methode und das Format der Protokollausgabe fest. Zum Beispiel: logger:syslog?appname=bob&local=7 oder logger:stdout?json=true . Standardmäßig logger:stderr .

Standardmetriken


- sind bestimmte Überwachungsmetriken, deren Auflistung direkt im Code festgelegt ist. Die Sammlung - kann durch Angabe der Befehlszeilenparameter --disable-default-metrics und / oder --disable-settings-metrics oder durch Definition der entsprechenden Umgebungsvariablen deaktiviert werden.
Ich stelle fest, dass in der aktuellen Version das Problem der Verwendung von Metriken beim Aktivieren von autoDiscovery behoben wurde, wodurch es zu einer Duplizierung von Metriken kam, die zu Fehlern führte.


Standardmäßig werden Metriken aus den folgenden Ansichten an die Überwachung gesendet:


  • pg_stat_bgwriter;
  • pg_stat_database;
  • pg_stat_database_conflicts;
  • pg_locks;
  • pg_stat_replication;
  • pg_stat_activity;
  • pg_settings.

Worauf Sie achten sollten, sind pg_stat_replication und pg_stat_activity, da die Menge der zurückgegebenen Felder von der PostgreSQL-Version abhängt. Dazu wird im Exporter die DBMS-Version geprüft und der entsprechende Auftrag ausgewählt. Sie können in Benutzerabfragen keine Version angeben. Es wird vorausgesetzt, dass der Administrator im Voraus weiß, in welcher Version die Instanz überwacht wird. Probleme können auch auftreten, wenn Sie versuchen, Metriken von einem Exporteur aus Instanzen unterschiedlicher Versionen zu erfassen.
Mit den Metriken für Instanzeinstellungen (pg_settings) ist alles etwas einfacher, sie werden durch die Anforderung gebildet:


 SELECT name, setting, COALESCE(unit, ''), short_desc, vartype FROM pg_settings WHERE vartype IN ('bool', 'integer', 'real');

Standardmäßig wird eine Reihe von Metriken daher nur aus numerischen Werten gebildet.


Des Weiteren werden wir die Schlussfolgerung des Exporteurs berücksichtigen, einschließlich der Frage, wie wir verstehen, warum hartcodierte Metriken ihr Existenzrecht haben. Nehmen Sie zum Beispiel zwei Metriken: shared_buffers und wal_sender_timeout. In der Ausgabe des Exporteurs erhalten wir für jede Metrik drei Zeilen.
Die erste Zeile - stellt den Hinweis dar und besteht aus dem Namen der Metrik in postgres_exporter, einer Beschreibung (die Spalte short_desc der Ansicht pg_settings) und, falls eine Konvertierung in den Basistyp stattgefunden hat, welcher (der Wert in eckigen Klammern).
Die zweite Zeile gibt die Art des Wertes in Prometheus an. Und die dritte Zeile, eine Metrik mit einer Reihe von Beschriftungen und einem zugewiesenen Wert.


Rückgabewerte für shared_buffers.


 # HELP pg_settings_shared_buffers_bytes Sets the number of shared memory buffers used by the server. [Units converted to bytes.] # TYPE pg_settings_shared_buffers_bytes gauge pg_settings_shared_buffers_bytes{server="127.0.0.1:5432"} 1.34217728e+08

pg_settings_shared_buffers_bytes - der Name der Metrik. Es setzt sich nach den Regeln der guten Form aus dem Namen der Tabelle, dem Namen der Metrik und der Maßeinheit zusammen. Als nächstes folgt eine kurze Beschreibung aus der Tabelle pg_settings. Zuletzt ein Hinweis darauf, dass der Metrikwert in eine Einheit von Bytes konvertiert wurde (Einheiten in Bytes konvertiert). Warum es sich lohnt, auf Letzteres zu achten, denn direkt in der Datenbank sieht der Wert etwas anders aus, nämlich:


  name | setting | unit | short_desc ----------------+---------+------+-------------------------------------------------------------- shared_buffers | 16384 | 8kB | Sets the number of shared memory buffers used by the server.

Die Art der Metrik ist GAUGE, was bedeutet, dass sie im Laufe der Zeit beliebige Werte annehmen kann. In unserem Fall kann sich die Anzahl der Puffer bei der Feinabstimmung in beide Richtungen ändern.
Weitere Informationen zu den Metriktypen und ihren Unterschieden finden Sie in der Prometheus-Dokumentation.


Die folgende Metrik lautet wal_sender_timeout. Informationsfelder werden nach dem gleichen Prinzip wie oben beschrieben gesammelt. Nur in diesem Fall wird der Metrikwert in Sekunden konvertiert und die Datenbank in Millisekunden gespeichert. Bei dieser Funktion müssen Sie vorsichtig sein und beim Plotten von Diagrammen berücksichtigen.


 # HELP pg_settings_wal_sender_timeout_seconds Sets the maximum time to wait for WAL replication. [Units converted to seconds.] # TYPE pg_settings_wal_sender_timeout_seconds gauge pg_settings_wal_sender_timeout_seconds{server="127.0.0.1:5432"} 60

Der in der Datenbank gespeicherte Wert:


 demo=# SELECT name, setting, COALESCE(unit, ''), short_desc, vartype FROM pg_settings WHERE name='wal_sender_timeout'; name | setting | coalesce | short_desc | vartype --------------------+---------+----------+----------------------------------------------------+--------- wal_sender_timeout | 60000 | ms | Sets the maximum time to wait for WAL replication. | integer

Alle Werte mit Einheiten werden auf zwei Typen reduziert: Volumenmetriken in Bytes; Zeitmetriken zu Sekunden.


Benutzerdefinierter Metriksatz


Zusätzlich zu oder anstelle der Standardmetriken können Sie Ihre eigenen verwenden. Legen Sie dazu einfach den Dateipfad mit Benutzerabfragen über das Argument --extend.query-path = query.yaml oder über die Umgebungsvariable PG_EXPORTER_EXTEND_QUERY_PATH fest.
Das Projekt-Repository enthält eine YAML-Datei mit Beispielen: queries.yaml


Ich stelle fest, dass im Vergleich zur vorherigen Version in 0.8.0 neue Schlüssel master und cache_seconds hinzugefügt wurden. Im folgenden Beispiel analysieren wir das Aufnahmeformat und den Zweck der Felder.


Beispielinhalt der Datei queries.yaml


 pg_database: query: "SELECT pg_database.datname, pg_database_size(pg_database.datname) as size_bytes FROM pg_database" master: true cache_seconds: 30 metrics: - datname: usage: "LABEL" description: "Name of the database" - size_bytes: usage: "GAUGE" description: "Disk space used by the database"

Schlüssel und Werte aus dem obigen Beispiel:


  • pg_database - ein beliebiges Präfix für die von der Anforderung zurückgegebenen Metriken (Erforderlich);
  • query - enthält eine SQL-Abfrage (Erforderlich);
  • master - führt die Anforderung nur in der Datenbank aus, die beim Herstellen einer Verbindung mit der URI (master database) angegeben wurde. Erforderlich, wenn der Exporter mit dem Flag --auto-discover-databases gestartet wird. Akzeptiert wahr oder falsch. Standardmäßig falsch. (Optional);
  • cache_seconds - Zeit, während der Cache-Daten zurückgegeben werden. Es wird in Sekunden eingestellt;
  • metrics - Enthält eine Liste von Tags und Metriken.
  • datname , size_bytes - Listenelement. Der Name des Listenelements muss mit dem Namen der Spalte in der Abfrage übereinstimmen.
  • usage - Art des Wertes. Akzeptiert COUNTER, GAUGE, LABLE (mehr in der Prometheus-Dokumentation)
  • description - Benutzerdefinierte Metrikbeschreibung

Beispiel für Rückgabemetriken:


 # HELP pg_database_size_bytes Disk space used by the database # TYPE pg_database_size_bytes gauge pg_database_size_bytes{datname="dbtest1",server="localhost:5432"} 1.0105503e+07 pg_database_size_bytes{datname="demo",server="localhost:5432"} 2.813719199e+09 pg_database_size_bytes{datname="postgres",server="localhost:5432"} 4.735491e+06 pg_database_size_bytes{datname="template0",server="localhost:5432"} 7.758339e+06 pg_database_size_bytes{datname="template1",server="localhost:5432"} 7.758339e+06

Zusammenfassung


Nun, wir fassen alles zusammen, was wir in der neuesten Version von postgres_exporter 0.8.0 haben. Grundsätzlich beziehen sich alle Verbesserungen auf die Überwachung mehrerer Instanzen und / oder mehrerer Datenbanken in einer Instanz.


  • Mit dem Argument "Datenbanken ausschließen" (in 0.6.0 erschienen) können Sie Datenbanken aus der Liste der Datenbanken ausschließen, für die Metriken erfasst werden. Sie können jedoch die in der URI-Verbindung angegebene Datenbank nicht ausschließen, da es sich um eine Masterbasis handelt.
  • Jetzt können Sie benutzerdefinierte Abfragen für globale Ansichten (pg_stat_activity, pg_stat_database usw.) zusammen mit dem Argument auto-discover-databases verwenden. Zu diesem Zweck wurde ein zusätzliches Master- Feld hinzugefügt, das angibt, dass die Anforderung nur in der Master-Datenbank ausgeführt werden soll.
  • Jetzt können Sie die Standardmetriken mit dem Argument Auto-Discovery-Datenbanken verwenden.
  • Für Benutzeranforderungen wurde das Feld cache_seconds hinzugefügt, in dem Sie die Zeit (in Sekunden) festlegen können, nach der die Antwort des Servers auf die entsprechende Anforderung zwischengespeichert wird.

Quellen


  • Prometheus [ 1 ] ist eine Open Source-Anwendung zur Überwachung und Warnung von Ereignissen. Es schreibt Echtzeitmetriken in eine Zeitreihendatenbank, die mit dem HTTP-Anforderungsmodell erstellt wurde, mit flexiblen Abfragen und Echtzeitwarnungen.
  • postgres_exporter ist ein Exporteur von PostgreSQL-Metriken für Prometheus.
    Version zum Zeitpunkt des Schreibens, v 0.5.1. Unterstützte Versionen von PostgreSQL 9.4+ (aber wie die Praxis gezeigt hat, funktioniert es mit 9.3).

Source: https://habr.com/ru/post/de480902/

More articles:


All Articles