👹 🏆 🧔 Memantau kesalahan dan kejadian di log PostgreSQL (grok

Selamat siang, kolega dan habretchiki! Hari ini, saya ingin berbagi dengan Anda catatan kecil tentang bagaimana Anda dapat mengatur pemantauan operasional kesalahan dan peristiwa yang muncul di log PostgreSQL menggunakan Prometheus dan pengekspor metrik grok_exporter.

Saya harus segera mengatakan bahwa ini tentu saja kasus khusus menggunakan eksportir ini. Jadi mengapa itu dibutuhkan dan siapa yang mungkin tertarik?

pengantar

Siapa yang butuh ini?

Jika Prometheus sudah ada di infrastruktur Anda dan membuat infrastruktur terpisah untuk mengumpulkan dan menganalisis log, seperti ELK atau Greylog, mahal dan tidak praktis (jika tidak ada Prometheus, itu bukan masalah, mudah dan cepat untuk menginstal).

Alat ini akan berguna tidak hanya untuk DBA, tetapi juga untuk administrator aplikasi, secara umum, untuk semua orang yang entah bagaimana bekerja dengan log aplikasi. Ini memungkinkan Anda untuk dengan cepat mendapatkan informasi tentang perilaku freelance dan memiliki titik referensi tertentu untuk analisis situasi lebih lanjut.

Untuk apa semua ini?

Log pemantauan akan memungkinkan Anda untuk memiliki gambar yang lebih lengkap dan merespons lebih cepat terhadap masalah yang muncul, baik itu: upaya otorisasi (termasuk yang tidak berhasil), berbagai kesalahan, atau peristiwa tertentu.

Ada daftar yang bagus di sini, dibentuk oleh kategori acara (Lihat bagian Kategori Acara Log), ini dapat digunakan untuk membuat aturan di Prometheus.

grok_exporter

Pengekspor metrik grok_exporter memungkinkan Anda membaca data yang tidak terstruktur dari sumbernya, mengonversinya menjadi data terstruktur, sesuai aturan, dan memberikannya sebagai metrik dalam format yang dipahami Prometheus.

Eksportir dibuat dalam gambar plug-in di ELK plugins-filter-grok , yang memungkinkan Anda untuk menggunakan satu set templat plugins-filter-grok sebagaimana adanya.

Instalasi

Instalasi mudah dan sederhana. Untuk melakukan ini, cukup ikuti tautan dan unduh versi yang Anda suka (dan ya mereka semua pra-rilis, dan versi terbaru masih dalam tahap kandidat pelepasan) dan unzip arsip yang dihasilkan.

Hasilnya, kami mendapatkan perangkat berikut:

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

dimana:

grok_exporter - eksportir dapat dieksekusi
pola - berisi serangkaian pola
contoh - berisi kumpulan data uji dan contoh file konfigurasi

Untuk memulai eksportir, jalankan saja file yang dapat dieksekusi. File konfigurasi config.yml dicari di direktori dari mana aplikasi diluncurkan atau lokasinya ditentukan oleh opsi -config

Pengaturan dan persiapan untuk pekerjaan

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

Pertama-tama, kita akan mengedit pola / template postgresql sesuai dengan format file log kita dan menambahkan konstruksi tambahan. Saya menekankan sekali lagi bahwa sintaks template sepenuhnya konsisten dengan yang digunakan dalam plugins-filter-grok , oleh karena itu, untuk semua masalah yang berkaitan dengan sintaks, Anda dapat dan harus pergi ke dokumentasinya. Jadi, mari kita bawa templat kita untuk PostgreSQL ke formulir (file pola / grok-pola sudah berisi seperangkat besar templat dasar):

#     - 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

Desain ()?memungkinkan Anda menunjukkan bahwa nilainya opsional.

Di sini, secara cukup rinci, dengan contoh, proses membuat file konfigurasi dijelaskan. Di bawah ini, hanya apa yang akan digunakan yang diberikan.

Deskripsi singkat tentang file konfigurasi (dari dokumentasi)

File konfigurasi adalah file dalam format YAML dan dibagi menjadi beberapa bagian:

global yang pengaturan 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

Dalam sintaks file konfigurasi versi ke-3, mengimpor metrik dari file individual menjadi mungkin, ini memungkinkan Anda untuk mengelompokkan metrik berdasarkan tujuan.

Selanjutnya, buat file konfigurasi base config.yml . Di dalamnya, kita: mengatur path ke file log PostgreSQL dengan mask; impor templat dari direktori pola dan metrik dari direktori metrics.d ; kami menunjukkan dengan protokol apa dan pada port mana perlu untuk menerapkan metrik.

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, ;
Jika kumulatif disetel ke true, nilai metrik dengan set label yang sama akan dijumlahkan, yang merupakan perilaku yang diharapkan. Situasi tak terduga dapat muncul ketika, pada permintaan kedua, Anda bisa mendapatkan jumlah nilai dalam permintaan ditambah nilai sebelumnya.
Jika kumulatif disetel ke false, jika ada metrik dengan set label yang sama, hanya nilai terakhir yang akan ditampilkan;

Ternyata banyak surat, membingungkan dan tidak bisa dipahami di beberapa tempat, tetapi saya akan mencoba untuk mengungkapkannya dalam contoh di bawah ini.

Jadi, kami memiliki file konfigurasi yang dapat mengembalikan empat metrik, tiga penghitung, dan satu nilai arbitrer. Faktanya, tiga yang pertama mempertimbangkan jumlah kecocokan dari bidang templat kecocokan dengan string yang diterima dari sumber, yang keempat - menampilkan jumlah nilai.

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'

Praktek

pg_grok_error_count

Metrik menghitung jumlah acara ERROR, PERINGATAN, FATAL dan PANIC, sesuai dengan pola. Ini dapat berguna untuk pemantauan dan peringatan jika terjadi keadaan darurat. Misalnya, Anda dapat mengonfigurasi peringatan dalam kasus berikut: upaya otorisasi yang gagal, melebihi ambang jumlah kesalahan per unit waktu, atau ketika database berada dalam keadaan pemulihan setelah kegagalan, dan banyak lagi ( Log Kategori Acara ).

Misalnya, kami akan menyiapkan lansiran tentang upaya otorisasi yang gagal. Contoh upaya login yang gagal di file log PostgreSQL terlihat seperti ini:

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"

Dalam output grok_exporter, upaya otentikasi yang gagal dapat diidentifikasi oleh label pesan yang berisi otentikasi kata sandi substring gagal untuk ... :

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

Data yang diperoleh akan membantu merumuskan aturan untuk Prometheus. Sensitivitas dapat disesuaikan berdasarkan realitas Anda sendiri.

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

Demikian pula, Anda dapat melacak eksekusi perintah pg_reload_conf. Selain itu, perlu memperhatikan daftar label, atau lebih tepatnya, fakta bahwa hanya satu label sesi yang digunakan. Ini karena fakta bahwa acara dibuat sebagai bagian dari proses server, dan bukan sesi pengguna.

Dalam file log PostgreSQL, acara ini terlihat seperti ini:

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

Itu dapat dilihat bahwa label yang digunakan pada contoh sebelumnya kosong. Dalam hal ini, kami akan menggunakan pengidentifikasi sesi untuk identifikasi, dan itu tidak akan berubah sampai instance PostgreSQL dihentikan atau dimulai kembali.

Situasi serupa akan terjadi pada kasus serupa lainnya, misalnya, menghentikan instance:

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

Dalam output grok_exporter, kita mendapatkan:

# 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

Aturan untuk notifikasi, tidak ada gunanya membawanya, itu akan mirip dengan yang dibahas di atas.

pg_grok_tpm_file_size_bytes

Segera buat reservasi bahwa contoh ini berasal dari kategori "kuda bulat dalam ruang hampa" dan diberikan lebih banyak untuk menunjukkan bagaimana Anda dapat mengubah perilaku metrik.

Perilaku metrik pengukur dapat dipengaruhi dengan mengubah retensi dan parameter kumulatif . Memang, tidak seperti penghitung biasa, yang mempertimbangkan jumlah garis yang cocok dengan pola kecocokan, pengukur memungkinkan Anda untuk beroperasi pada data dari file log. Ternyata kami dapat mengakumulasikannya dengan menambah atau mengurangi nilai yang diperoleh, atau menggunakannya sebagai nilai yang berubah secara sewenang-wenang. Jadi, dalam kasus pertama, kita akan tertarik pada besarnya kenaikan, pada yang kedua - nilai itu sendiri.

Mari kita lihat beberapa contoh:

, (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

, . , .

Tidak diragukan lagi grok_exporter adalah alat yang tepat untuk memonitor aplikasi. Ini memungkinkan Anda untuk melihat "sulit untuk diakses", untuk sistem pemantauan, tempat dan memperkaya pemantauan dengan metrik (kontrol) tambahan, namun tetap cukup sederhana, fungsional dan ringan.

Pada saat yang sama, ini juga akan berguna bagi pengembang, karena memberikan setidaknya akses tidak langsung ke log aplikasi melalui sistem pemantauan. Di mana Anda dapat menghubungkan metrik dari berbagai sumber.

Poin positif lainnya adalah bahwa proyek ini sedang mengembangkan dan memperoleh fungsionalitas baru.

Pada gilirannya, saya berharap bahwa catatan singkat ini akan bermanfaat, termasuk untuk proyek itu sendiri. Lebih banyak bintang, lebih banyak pekerjaan menyenangkan!

Terimakasih untuk semua!

Memantau kesalahan dan kejadian di log PostgreSQL (grok_exporter)

pengantar

Siapa yang butuh ini?

Untuk apa semua ini?

grok_exporter

Instalasi

Pengaturan dan persiapan untuk pekerjaan

PostgreSQL

grok_exporter

Praktek

pg_grok_error_count

pg_grok_reload_conf_count

pg_grok_tpm_file_size_bytes

More articles: