🦇 🐃 👩🏾‍⚖️ Überwachen von Fehlern und Ereignissen im PostgreSQL-Protokoll (grok

Guten Tag, Kollegen und Habretchiki! Heute möchte ich Ihnen einen kleinen Hinweis geben, wie Sie die betriebliche Überwachung von Fehlern und Ereignissen, die im PostgreSQL-Protokoll angezeigt werden, mit Prometheus und dem Exporteur von Metriken grok_exporter organisieren können.

Ich muss sofort sagen, dass dies natürlich ein Sonderfall bei der Verwendung dieses Exporteurs ist. Warum wird es benötigt und wer könnte interessiert sein?

Einführung

Wer braucht das?

Wenn Prometheus bereits in Ihrer Infrastruktur vorhanden ist und die Erstellung einer separaten Infrastruktur zum Sammeln und Analysieren von Protokollen wie ELK oder Greylog teuer und unpraktisch ist (wenn Prometheus nicht vorhanden ist, ist dies kein Problem, es ist einfach und schnell zu installieren).

Das Tool ist nicht nur für DBAs nützlich, sondern auch für Anwendungsadministratoren im Allgemeinen für alle, die irgendwie mit Anwendungsprotokollen arbeiten. Es ermöglicht Ihnen, schnell Informationen über das Verhalten von Freiberuflern zu erhalten und einen bestimmten Bezugspunkt für die weitere Analyse der Situation zu haben.

Wofür ist das alles?

Durch die Überwachung von Protokollen erhalten Sie ein vollständigeres Bild und können schneller auf neu auftretende Probleme reagieren, sei es: Autorisierungsversuche (einschließlich erfolgloser), verschiedene Fehler oder bestimmte Ereignisse.

Hier gibt es eine gute Liste, die aus Ereigniskategorien besteht (siehe Abschnitt Protokollereigniskategorien). Sie kann zum Erstellen von Regeln in Prometheus verwendet werden.

grok_exporter

Mit dem Metrikexporter grok_exporter können Sie unstrukturierte Daten aus der Quelle lesen, sie gemäß den Regeln in strukturierte Daten konvertieren und als Metriken in einem von Prometheus verstandenen Format weitergeben.

Der Exporter wurde im Image eines Plug- Ins in ELK Plugins-Filters-Grok erstellt , mit dem Sie eine Reihe von Plugins-Filtern-Grok-Vorlagen unverändert verwenden können .

Installation

Die Installation ist unkompliziert und einfach. Folgen Sie dazu einfach dem Link und laden Sie die gewünschte Version herunter (und ja, alle sind Vorabversionen, und die neuesten Versionen befinden sich noch im Release Candidate-Stadium) und entpacken Sie das resultierende Archiv.

Als Ergebnis erhalten wir den folgenden Satz:

grok_exporter-1.0.0.RC3.linux-amd64
├── patterns
│   ├── ruby
│   ├── redis
│   ├── rails
│   ├── postgresql
│   ├── nagios
│   ├── mongodb
│   ├── mcollective-patterns
│   ├── mcollective
│   ├── linux-syslog
│   ├── junos
│   ├── java
│   ├── haproxy
│   ├── grok-patterns
│   ├── firewalls
│   ├── exim
│   ├── bro
│   ├── bacula
│   └── aws
├── grok_exporter
└── example
    ├── exim-rejected-RCPT-examples.log
    ├── config.yml
    └── config_logstash_http_input_ipv6.yml

wo:

grok_exporter - ausführbare Exporter-Datei
Muster - enthält eine Reihe von Mustern
Beispiel - enthält einen Testdatensatz und eine Beispielkonfigurationsdatei

Um den Exporter zu starten, führen Sie einfach die ausführbare Datei aus. Die Konfigurationsdatei config.yml wird in dem Verzeichnis durchsucht, aus dem die Anwendung gestartet wird, oder ihr Speicherort wird durch die Option -config angegeben

Einrichtung und Vorbereitung der Arbeit

PostgreSQL

, PostgreSQL. :

grok_exporter . , pg_reload_conf.

alter system set log_directory to '/var/log/postgresql';

alter system set log_file_mode to '0644';

log_line_prefix, . , . :

 alter system set log_line_prefix to '%t datname:%d,client:%h,app:%a,usename:%u,session:%c ';

grok_exporter

Zunächst bearbeiten wir die Vorlage pattern / postgresql entsprechend dem Format unserer Protokolldatei und fügen zusätzliche Konstruktionen hinzu. Ich betone noch einmal, dass die Syntax der Vorlagen vollständig mit der in Plugins-Filters-Grok verwendeten übereinstimmt . Daher können und sollten Sie für alle Probleme im Zusammenhang mit der Syntax die Dokumentation lesen . Lassen Sie uns also unsere Vorlage für PostgreSQL in das Formular bringen (die Datei patterns / grok-patterns enthält bereits eine große Anzahl grundlegender Vorlagen):

#     - postgresql
PG_TIMESTAMP %{YEAR}-%{MONTHNUM}-%{MONTHDAY} %{HOUR}:%{MINUTE}:%{SECOND} [A-Z]{3,4}

#    
PG_ERROR_PATTERN (ERROR|WARNING|FATAL|PANIC)

# log_line_prefix   - PostgreSQL
PG_PREFIX %{PG_TIMESTAMP} datname:(%{DATA:datname})?,client:(%{DATA:client_host})?,app:(%{DATA:app_name})?,usename:(%{USER:usename})?,session:(%{DATA:session})?

#    log_level     
PG_ERROR_LEVEL %{PG_ERROR_PATTERN:log_level}:

#    
PG_EVENT_AUTH LOG:  connection authorized:

#      SIGHUP,   
PG_EVENT_RELOAD LOG:  received SIGHUP, reloading configuration files

Mit dem Design ()?können Sie angeben, dass der Wert optional ist.

Hier wird anhand von Beispielen ausführlich beschrieben, wie eine Konfigurationsdatei erstellt wird. Im Folgenden wird nur angegeben, was verwendet wird.

Eine kurze Beschreibung der Konfigurationsdatei (aus der Dokumentation)

YAML :

global —
- config_version — . grok_exporter, ≥ 1.0.0.RC3, 3
  retention_check_interval — . , .
input — .
- type — . : file, stdin, webhook. , file;
- path|paths — c -(-). ;
- readall — , .
  true — , . Prometheus .
  false — , grok_exporter;
- fail_on_missing_logfile — -. true — , ;
imports — , , . 2, , grok.
- type — grok_patterns () metrics ();
- file|dir — . , .
grok_patterns — , .
metrics — . — counter, gauge, histogram, or summary.

server —

  protocol: https
  host: localhost
  port: 9144
  path: /metrics
  cert: /path/to/cert
  key: /path/to/key

In der Syntax der 3. Version der Konfigurationsdatei wurde es möglich, Metriken aus einzelnen Dateien zu importieren. Auf diese Weise können Sie Metriken nach Zweck gruppieren.

Erstellen Sie als Nächstes die Konfigurationsdatei base config.yml . Darin setzen wir: den Pfad zu den PostgreSQL-Protokolldateien per Maske; Importvorlagen aus dem Muster - Verzeichnis und Metriken aus dem metrics.d Verzeichnis ; Wir geben an, nach welchem Protokoll und an welchem Port Metriken beantragt werden müssen.

config.yml

  config_version: 3
  retention_check_interval: 10s
input:
  type: file
  path: /var/log/postgresql/postgresql-*.log
  readall: false
imports:
- type: grok_patterns
  dir: ./patterns
- type: metrics
  dir: ./metrics.d
server:
  protocol: http
  port: 9144

, metrics.d postgresql.yml, .

, , .. ( retention, - 2 30 ) , . retention_check_interval.

, :

, ;
— GAUGE COUNTER, . .. GAUGE, ;
Wenn kumulativ auf true gesetzt ist, werden die Werte der Metriken mit demselben Satz von Beschriftungen summiert. Dies ist das erwartete Verhalten. Eine unerwartete Situation kann auftreten, wenn Sie bei der zweiten Anforderung die Summe der Werte in der Anforderung plus des vorherigen Werts abrufen können.
Wenn kumulativ auf falsch gesetzt ist und Metriken mit denselben Beschriftungen vorhanden sind, wird nur der letzte Wert angezeigt.

Es stellte sich heraus, dass viele Briefe verwirrend und stellenweise unverständlich waren, aber ich werde versuchen, dies in den folgenden Beispielen offenzulegen.

Wir haben also eine Konfigurationsdatei, die vier Metriken, drei Zähler und einen beliebigen Wert zurückgeben kann. Tatsächlich berücksichtigen die ersten drei die Anzahl der Übereinstimmungen des Übereinstimmungsvorlagenfelds mit den von der Quelle empfangenen Zeichenfolgen, die vierte - zeigt die Summe der Werte an.

postgresql.yaml

#  - 
- type:   counter
  name:   pg_grok_error_count
  help:   Count of line error
  match:  '%{PG_PREFIX} %{PG_ERROR_LEVEL}  %{GREEDYDATA:message}'
  labels:
    log_level:   '{{.log_level}}'
    usename:     '{{.usename}}'
    datname:     '{{.datname}}'
    app_name:    '{{.app_name}}'
    client_host: '{{.client_host}}'
    message:     '{{.message}}'

#   
- type:   counter
  name:   pg_grok_auth_succes_count
  help:   Count of connections authorized
  match:  '%{PG_PREFIX} %{PG_EVENT_AUTH}'
  labels:
    usename:     '{{.usename}}'
    datname:     '{{.datname}}'
    app_name:    '{{.app_name}}'
    client_host: '{{.client_host}}'

#   
- type:   counter
  name:   pg_grok_reload_conf_count
  help:   Count of call pg_reload_conf
  match:  '%{PG_PREFIX} %{PG_EVENT_RELOAD}'
  labels:
    session:     '{{.session}}'

#   
- type:       gauge
  name:       pg_grok_tpm_file_size_bytes
  help:       Size of tmp file created by time
  match:      '%{PG_PREFIX} %{PG_EVENT_TMP_FILE}'
  value:      '{{.size}}'
  cumulative: true
  retention:  5s
  labels:
    static:     'temp_file'

Trainieren

pg_grok_error_count

Die Metrik zählt die Anzahl der Ereignisse ERROR, WARNING, FATAL und PANIC gemäß dem Muster. Es kann zur Überwachung und Warnung im Notfall nützlich sein. Beispielsweise können Sie eine Warnung in den folgenden Fällen konfigurieren: Versuche einer nicht erfolgreichen Autorisierung, Überschreiten des Schwellenwerts für die Anzahl der Fehler pro Zeiteinheit oder wenn sich die Datenbank nach einem Fehler in einem Wiederherstellungszustand befindet, und vieles mehr ( Protokollereigniskategorien ).

Beispielsweise richten wir eine Warnung über fehlgeschlagene Autorisierungsversuche ein. Ein Beispiel für einen erfolglosen Anmeldeversuch in der PostgreSQL-Protokolldatei sieht folgendermaßen aus:

2020-04-20 23:34:53 AEST datname:test,client:127.0.0.1,app:[unknown],usename:test_user,session:5e9da4fd.733 FATAL:  password authentication failed for user "test_user"
2020-04-20 23:34:53 AEST datname:test,client:127.0.0.1,app:[unknown],usename:test_user,session:5e9da4fd.733 DETAIL:  Password does not match for user "test_user".
        Connection matched pg_hba.conf line 86: "host    all             all             127.0.0.1/32            md5"

In der Ausgabe von grok_exporter können fehlgeschlagene Authentifizierungsversuche anhand des Nachrichtenetiketts identifiziert werden, das die Kennwortkennwortauthentifizierung enthält, die für ... fehlgeschlagen ist :

pg_grok_error_count{app_name="[unknown]",client_host="127.0.0.1",datname="postgres",log_level="FATAL",message="password authentication failed for user "postgres"", usename="postgres"} 15
pg_grok_error_count{app_name="[unknown]",client_host="127.0.0.1",datname="test",log_level="FATAL",message="password authentication failed for user \"test_user\"",usename="test_user"} 5

Die erhaltenen Daten helfen bei der Formulierung einer Regel für Prometheus. Die Empfindlichkeit kann basierend auf Ihren eigenen Realitäten angepasst werden.

groups:
- name: AuthAlert
  rules:
  - alert: AuthFail
    expr: sum(rate(pg_grok_error_count{message=~"password authentication failed for user.*"}[1m])) by (instance) > 0.1
    for: 30s
    labels:
      severity: warning
    annotations:
      summary: Too many fail authorization for {{ $labels.instance }}

pg_grok_reload_conf_count

Ebenso können Sie die Ausführung des Befehls pg_reload_conf verfolgen. Darüber hinaus lohnt es sich, auf die Liste der Labels oder vielmehr auf die Tatsache zu achten, dass nur ein Session-Label verwendet wird. Dies liegt an der Tatsache, dass das Ereignis als Teil des Serverprozesses und nicht der Benutzersitzung erstellt wird.

In der PostgreSQL-Protokolldatei sieht dieses Ereignis folgendermaßen aus:

2020-04-21 01:20:26 AEST datname:,client:,app:,usename:,session:5e9d9371.564 LOG:  received SIGHUP, reloading configuration files

Jene. Es ist ersichtlich, dass die im vorherigen Beispiel verwendeten Beschriftungen leer sind. In diesem Fall verwenden wir die Sitzungskennung zur Identifizierung und sie ändert sich erst, wenn die Instanz von PostgreSQL gestoppt oder neu gestartet wird.

Eine ähnliche Situation besteht für andere ähnliche Fälle, z. B. das Stoppen einer Instanz:

2020-04-21 01:32:52 AEST datname:,client:,app:,usename:,session:5e9d9371.564 LOG:  received fast shutdown request
2020-04-21 01:32:53 AEST datname:,client:,app:,usename:,session:5e9d9371.564 LOG:  database system is shut down

In der Ausgabe von grok_exporter erhalten wir:

# HELP pg_grok_reload_conf_count Count of call pg_reload_conf
# TYPE pg_grok_reload_conf_count counter
pg_grok_reload_conf_count{session="5e9d9371.564"} 5

Die Regel für die Benachrichtigung, es macht keinen Sinn, sie zur Sprache zu bringen, sie wird der oben diskutierten ähnlich sein.

pg_grok_tpm_file_size_bytes

Ich werde sofort reservieren, dass dieses Beispiel aus der Kategorie "Kugelpferd im Vakuum" stammt und in größerem Umfang angegeben wird, um zu zeigen, wie Sie das Verhalten von Metriken ändern können.

Das Verhalten der Spurmetriken kann durch Änderung der beeinflusst werden Retention und kumulative Parameter . Im Gegensatz zu einem normalen Zähler, der die Anzahl der Zeilen berücksichtigt, die mit dem Übereinstimmungsmuster übereinstimmen, können Sie mit der Anzeige Daten aus der Protokolldatei bearbeiten. Es stellt sich heraus, dass wir es akkumulieren können, indem wir es um den erhaltenen Wert erhöhen oder verringern oder es als willkürlich ändernden Wert verwenden. Im ersten Fall interessiert uns also die Größe des Inkrements, im zweiten der Wert an sich.

Schauen wir uns einige Beispiele an:

, (cumulative: true). , , . , retention_check_interval + retention <= scrape_interval — Prometheus.

- PostgreSQL :

2020-04-21 02:51:15 AEST datname:,client:,app:,usename:,session:5e9dd2f3.1278 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4728.0", size 46931968
2020-04-21 02:51:15 AEST datname:,client:,app:,usename:,session:5e9dd2f3.1279 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4729.0", size 46276608
2020-04-21 02:51:15 AEST datname:postgres,client:[local],app:psql,usename:postgres,session:5e9dc0a8.112c LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4396.14", size 47194112

, :

pg_grok_tpm_file_size_bytes{static="temp_file"} 1.40402688e+08

.

, :

pg_grok_tpm_file_size_bytes{static="temp_file"} 1.1911168e+07

: , .

, , (retention) (cumulative: true)
, - PostgreSQL :

2020-04-21 03:03:40 AEST datname:,client:,app:,usename:,session:5e9dd5dc.12c6 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4806.0", size 46260224
2020-04-21 03:03:40 AEST datname:,client:,app:,usename:,session:5e9dd5dc.12c5 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4805.0", size 46833664
2020-04-21 03:03:40 AEST datname:postgres,client:[local],app:psql,usename:postgres,session:5e9dc0a8.112c LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4396.15", size 47316992

pg_grok_tpm_file_size_bytes{static="temp_file"} 1.40402688e+08

, . :

2020-04-21 03:10:40 AEST datname:,client:,app:,usename:,session:5e9dd76e.1325 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4901.0", size 46776320
2020-04-21 03:10:40 AEST datname:,client:,app:,usename:,session:5e9dd76e.1324 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4900.0", size 45768704
2020-04-21 03:10:40 AEST datname:postgres,client:[local],app:psql,usename:postgres,session:5e9dc0a8.112c LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4396.18", size 47841280

pg_grok_tpm_file_size_bytes{static="temp_file"} 2.80772608e+08

, . , .

, cumulative false , .

:

2020-04-21 03:41:04 AEST datname:,client:,app:,usename:,session:5e9ddea4.1393 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp5011.0", size 11763712
2020-04-21 03:41:04 AEST datname:,client:,app:,usename:,session:5e9ddea4.1392 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp5010.0", size 11501568
2020-04-21 03:41:04 AEST datname:postgres,client:[local],app:psql,usename:postgres,session:5e9dc0a8.112c LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4396.19", size 11911168

# HELP pg_grok_tpm_file_size_bytes Size of tmp file created by time
# TYPE pg_grok_tpm_file_size_bytes gauge
pg_grok_tpm_file_size_bytes{static="temp_file"} 1.1911168e+07

, . , .

Zweifellos ist grok_exporter das richtige Werkzeug zur Überwachung von Anwendungen. Es ermöglicht Ihnen, die "schwer zugänglichen" Systeme für Überwachungssysteme und -orte zu untersuchen und die Überwachung mit zusätzlichen (Kontroll-) Metriken zu bereichern, während Sie recht einfach, funktional und leicht bleiben.

Gleichzeitig ist es auch für Entwickler nützlich, da es zumindest indirekt über ein Überwachungssystem auf Anwendungsprotokolle zugreift. Hier können Sie Metriken aus verschiedenen Quellen korrelieren.

Ein weiterer positiver Punkt ist, dass das Projekt neue Funktionen entwickelt und erwirbt.

Ich hoffe wiederum, dass diese kurze Notiz nützlich sein wird, auch für das Projekt selbst. Mehr Sterne, mehr Spaß bei der Arbeit!

Danke an alle!

Überwachen von Fehlern und Ereignissen im PostgreSQL-Protokoll (grok_exporter)

Einführung

Wer braucht das?

Wofür ist das alles?

grok_exporter

Installation

Einrichtung und Vorbereitung der Arbeit

PostgreSQL

grok_exporter

Trainieren

pg_grok_error_count

pg_grok_reload_conf_count

pg_grok_tpm_file_size_bytes

More articles: