Praćenje PostgreSQL logova na Linuxu: jak Kako ranije otkriti probleme?

Article Image

Zašto pratiti PostgreSQL logove na Linuxu

Kao administrator ili razvijač, vi najčešće ne vidite sve što se dešava unutar PostgreSQL instance — ali logovi to otkrivaju. Pravilno praćenje logova omogućava vam da rano otkrijete spore upite, ponavljajuće greške, probleme sa konekcijama i neočekivane restartove. To znači brže reagovanje, manje downtime-a i preciznije usmeravanje optimizacija.

Koje konkretne probleme možete preduprediti

  • Identifikacija sporih upita i potreba za indeksima ili revidiranjem upita.
  • Otkrivanje grešaka autorizacije ili naglog porasta neuspelih konekcija.
  • Praćenje ponovljenih WAL/replication grešaka i problema sa replikacijom.
  • Detektovanje curenja resursa ili memória kroz poruke o OOM, deadlock-ovima ili failover događajima.

Gde su logovi i šta prvo proveriti na Linuxu

Lokacija i format logova zavise od distribucije i podešavanja PostgreSQL-a. Postoje dve osnovne granularnosti: logovanje u fajl (logging_collector) i prosljeđivanje u syslog/systemd journal. Prvo što ćete uraditi je proveriti trenutnu konfiguraciju i putanje.

Brzi komandni pregled konfiguracije

Pokrenite sledeće komande kao korisnik koji ima pristup PostgreSQL-u (obično postgres):

  • sudo -u postgres psql -c “SHOW logging_collector;” — da li PostgreSQL piše fajlove.
  • sudo -u postgres psql -c “SHOW log_directory;” — lokacija direktorijuma za logove kada se koriste fajlovi.
  • sudo -u postgres psql -c “SHOW log_filename;” — format imena fajla.
  • sudo -u postgres psql -c “SHOW log_line_prefix;” — koliko informacija se dodaje svakom zapisu (timestamp, user, db, pid…).

Tipične putanje i journal

  • Ako je logging_collector uključen, logovi su često pod data direktorijumom: /var/lib/pgsql/data/pg_log ili /var/log/postgresql (zavisi od paketa i distribucije).
  • Ako PostgreSQL koristi syslog, proverićete /var/log/syslog ili /var/log/messages u zavisnosti od vaše distribucije.
  • Za systemd-managed servise: journalctl -u postgresql.service — korisno za brzi pregled recentnih poruka i grešaka.

U praksi, kombinacija jasnog log_line_prefix i odgovarajuće vrednosti log_min_messages/log_min_error_statement olakšava filtriranje važnih poruka. Takođe, obratite pažnju na podešavanja rotacije (log_rotation_age, log_rotation_size) da ne biste izgubili istoriju potrebnu za analizu problema.

U sledećem delu ćemo detaljno proći kroz ključne parametre u postgresql.conf, dati predložene vrednosti za tipične sisteme i pokazati kako formatirati prefixe da biste lako parsirali i integrisali logove u alate za centralizaciju i alerting.

Ključni parametri u postgresql.conf koje treba podesiti odmah

Da biste imali upotrebljive logove, nekoliko parametara u postgresql.conf zaslužuje posebnu pažnju. Donosim praktične preporuke i zašto su važne.

  • logging_collector = on — omogućava usmeravanje logova u fajlove (ili csvlog). Ako koristite syslog/journal, proverite da li je to namerno; fajlovi su često praktičniji za obradu i rotaciju.
  • log_destination = ‘stderr’ / ‘csvlog’ / ‘syslog’ — za centralizaciju preporučujem csvlog ili stderr sa logging_collector, jer csvlog olakšava parsiranje i uvoz u ELK/Graylog.
  • log_directory / log_filename — postavite lokaciju na disk sa dovoljno prostora i podesite čitljive formate imena (npr. postgresql-%Y-%m-%d_%H%M%S.log) kako biste lakše pratili rotaciju.
  • log_rotation_age, log_rotation_size — balansirajte da ne gubite istoriju, ali i da ne pretrpate disk; tipično 1d i 100MB za manje sisteme, veće vrednosti za DB sa intenzivnim logovanjem.
  • log_min_messages / log_min_error_statement — u produkciji podešavajte na WARNING ili ERROR da smanjite šum; za dijagnostiku privremeno podignite na INFO ili LOG.
  • log_min_duration_statement — ključan za otkrivanje sporih upita. Preporuka: 200–500 ms za OLTP; za velika okruženja možete početi sa 1000 ms pa spuštati po potrebi.
  • log_statement — izbegavajte „all“ u produkciji (veliki overhead). Koristite samo u dijagnostici (ddl, mod) ako tražite konkretne promene.
  • log_connections / log_disconnections — korisno za praćenje skokova konekcija i curenja sesija; obično ON u sistemima gde su veze kritične.
  • log_lock_waits, deadlock_timeout — uključite log_lock_waits = on i podesite deadlock_timeout na razuman nivo (npr. 1s) da rano otkrijete blokade.
  • log_error_verbosity — setujte na default ili verbose za dublju dijagnostiku grešaka; verbose daje više detalja za post-mortem analize.

Kako formatirati log_line_prefix za lako parsiranje i korelaciju

Prefix zapisa je ključan za automatsko parsiranje i povezivanje događaja (query → session → korisnik). Cilj: imati jedinstveni, čitljiv i strojno parsabilan prefiks koji sadrži timestamp sa milisekundama, PID, korisnika, bazu, udaljenu adresu i ime aplikacije/session identifikator.

Predloženi primer (u postgresql.conf):

log_line_prefix = ‘%m [%p] %u@%d %r %a: ‘

(%m = timestamp sa milisekundama, %p = PID, %u = korisnik, %d = baza, %r = remote host:port, %a = application_name)

Zašto ovako?

  • Timestamp sa ms omogućava preciznu korelaciju sa metrikama i traces.
  • PID i session/application_name pomažu da grupišete logove istog procesa/sesije (npr. dugačak upit koji se pojavljuje kroz više zapisa).
  • Remote host i korisnik pomažu u otkrivanju neautorizovanih ili anomalnih konekcija.

Ako koristite csvlog, mnoge od ovih polja su dostupne kao kolone što znatno olakšava parsiranje u ELK/Graylog/ClickHouse. Ako koristite slobodni format, dosledan prefix olakšava regex parsere i Filebeat/Fluentd konfiguracije.

Osnovne smernice za integraciju logova i alerting

Jednom kada imate strukturisane i dovoljno detaljne logove, sledeći korak je slanje u centralu i postavljanje alertova:

  • Shipovanje: koristite Filebeat/Fluent Bit/Fluentd za čitanje fajlova ili systemd-journal za journal; ako koristite csvlog, aktivirajte Filebeat postgres modul koji parsing olakšava.
  • Parsiranje: za slobodan prefix koristite regex koji izvlači timestamp, pid, user, db, addr, app i poruku; za csvlog koristite CSV parser.
  • Alerting primeri: broj ERROR ili FATAL poruka > N u 5 minuta; više od X sporih upita (> log_min_duration) u Y minuta; nagli porast neuspelih konekcija; greške replikacije ili checkpoint spike.
  • Retention i arhiva: logove koji su važni za forenziku držite duže (npr. 30–90 dana), ostalo arhivirajte na jeftiniji storage.

U narednom delu ćemo proći konkretne primere konfiguracija za OLTP i OLAP sisteme, pokazati komande za testiranje podešavanja i dati spremne Filebeat/Fluentd filtre za parsiranje i slanje u ELK/Prometheus stack.

Brzi kontrolni spisak za implementaciju

  • Proverite gde trenutno idu logovi (psql SHOW log_directory; SHOW logging_collector;).
  • Uključite logging_collector i postavite log_line_prefix sa timestamp-om i PID-om.
  • Odredite log_min_duration_statement i log_min_messages prema opterećenju (testno niže, pa prilagodite).
  • Podesite rotaciju (age/size) i razmislite o arhiviranju važnih fajlova na jeftiniji storage.
  • Konfigurišite shipper (Filebeat/Fluent Bit/Fluentd) za slanje u centralu i napravite parsere za vaš format.
  • Definišite osnovne alerte (ERROR/FATAL rate, broj sporih upita, neuspešne konekcije, greške replikacije) i testirajte ih u staging okruženju.
  • Automatizujte proveru disk prostora i rotaciju logova kako biste sprečili zastoj zbog punog diska.
  • Izvršite periodične revizije log konfiguracije nakon promena aplikacije ili opterećenja.

Završne napomene i sledeći koraci

Praćenje logova treba da bude kontinuirani proces — počnite sa najmanjim potrebnim setom promena u staging okruženju, potvrdite da ne uvodite preveliki overhead, pa postupno podižite vidljivost tamo gde je korisna. Automatizujte shipping i alerting, ali zadržite mogućnost ručne forenzičke analize kada je potrebno.

Za detaljnija uputstva o opcijama logovanja i primerima konfiguracije, pogledajte zvaničnu PostgreSQL dokumentaciju o logovanju.

By Baze