Vigtig PostgreSQL-overvågning - del 1

Hvilke målinger for din PostgreSQL-implementering skal du overvåge? Denne serie af blogindlæg har til formål at give et minimalt startsæt af væsentlige overvågningshandlinger, som du bør implementere for at sikre sundheden og stabiliteten af ​​dine Postgres-servere.

Den første del dækker parametre på klyngeniveau.

Del 1:Klyngeniveau

I Postgres-jargon, en klynge er et sæt databaser, der administreres af en enkeltPostgres-serverinstans. Funktioner som replikering og WAL-arkivering fungerer på klyngeniveau.

1. Transaktions-id-interval

Fra en normal klients perspektiv vil datafilerne i en PostgreSQL-klynge synes at indeholde øjebliksbilledet af data som ændret af den sidste forpligtede transaktion. Men på grund af Postgres' MVCC-arkitektur indeholder de fysiske filer ikke kun data for den seneste transaktion, men for en række transaktioner, der slutter med den seneste. (Almindelig støvsugning fjerner dataene for de ældre transaktioner.)

Hver transaktion har en unik 32-bit heltal-id, kaldettransaktions-id'et . Af forskellige årsager bør forskellen mellem første og sidste transaktions-id være mindre end 2, hvilket er omkring 2 milliarder. Det er et must at holde området et godt stykke under denne grænse. – læs denne virkelige historie om, hvad der ellers sker.

Handling:Overvåg løbende transaktions-id-intervallet, advar, hvis værdien overstiger en fastsat tærskel.

Sådan:

-- returns the first and last transactions IDs for the cluster
SELECT oldest_xid::text::int as first,
       regexp_replace(next_xid, '^[0-9]+:', '')::int-1 as last
  FROM pg_control_checkpoint();

-- returns the transaction ID range for each database
SELECT datname, age(datfrozenxid)
  FROM pg_database;

2. Antal backends

Hver backend repræsenterer enten en klient, der er forbundet til serveren, eller en systembackend-proces (som autostøvsuger, baggrundsforfatter osv.). Hver backend er også en OS-proces, der bruger OS-ressourcer som hukommelse, åbne filbeskrivelser osv. For mange backends, typisk på grund af for mange klienter eller for mange langvarige forespørgsler, kan lægge pres på OS-ressourcer og nedsætte forespørgselssvartider for hver klient.

Handling:Overvåg det maksimale antal backends over hver dag/uge, undersøg stigende tendenser.

Sådan:

-- returns the count of currently running backends
SELECT count(*)
  FROM pg_stat_activity;

3. Inaktive replikeringspladser

Replikationspladser er markeret som 'inaktive', når den replikeringsklient, der er tilsluttet til åbningen, afbrydes. Inaktive replikeringsslots forårsager, at WAL-filer bevares, da de skal sendes til klienten, når den genoprettes, og slotsene bliver aktive. Faktisk er den første ting at kontrollere, om dine WAL-filtal ikke falder, at se, om du har inaktive replikeringspladser.

Ofte er inaktive replikeringspladser resultatet af en backupklient, der blev fjernet, en slave, der blev fjernet, promoveringer, failovers og lignende.

Handling:Kontroller løbende for inaktive replikationspladser, advar om nogen.

Sådan:

-- returns the count of inactive replication slots
SELECT count(*)
  FROM pg_replication_slots
 WHERE NOT active;

4. Backends venter på låse

SQL-sætninger kan eksplicit eller implicit få andre SQL-sætninger til at vente. For eksempel erklærer kørsel af en "SELECT .. FOR UPDATE" eksplicit en lås for de valgte rækker, og kørsel af en "UPDATE" placerer implicerede rækkeeksklusive låse. Andre SQL-sætninger, når støder man på låsen, skal man vente, indtil den første erklæring opgiver låsen, før den fortsætter med udførelsen.

Dette kan vise sig som langsom applikationsydelse under ugentlige rapportkørsler, timeout-transaktioner/websider og lignende.

Selvom en vis mængde låsning ikke kan undgås, kræver en stigende tendens til, at backends venter på låse, typisk forespørgsler eller applikationslogik, der skal omstruktureres.

Handling:Overvåg det maksimale antal backends, der venter på låse hver dag/uge, undersøg stigende tendenser.

Sådan:

-- returns the count of backends waiting on locks
SELECT count(*)
  FROM pg_stat_activity
 WHERE wait_event = 'Lock';

5. Backends tomgang i transaktion

Langvarige transaktioner er ikke særlig rart at have i PostgreSQL-verdenen. De kan få WAL-filer til at bygge op, forhindre autovakuum og manuel vakuum og opbruge ressourcer. Der kan ikke gøres meget ved ægte transaktioner, der tager lang tid at gennemføre, men der er tilfælde som dårlige apps/scripts og lejlighedsvis psql-klient, der starter transaktioner, men som ikke lukker dem. Backends, der betjener sådanne klienter, vises som "tomgang i transaktion".

Backends, der er i tomgang i transaktionen, bør detekteres og lukkes ned, før de begynder at påvirke systemstabiliteten.

Handling:Overvåg kontinuerligt antallet af backends, der er inaktiv i transaktionen, gennemse, hvis der findes nogen.

Sådan:

-- returns the count of backends waiting on locks
SELECT count(*)
  FROM pg_stat_activity
 WHERE state = 'idle in transaction';

6. Replikeringsforsinkelse for aktive forbindelser

Når der er aktive streaming-replikeringsklienter (som hot standbys) eller aktive logiske replikeringsklienter, kører Postgres en system-backend kaldet enWAL-afsender for hver aktiv (forbundet) klient. WAL-afsenderen er ansvarlig for at sende de WAL-registreringsdata, som klienten har brug for.

Replikeringsklienter forsøger typisk at følge med det primære, så meget de kan. Til tider kan WAL-genereringshastigheden på den primære side dog blive højere end den hastighed, hvormed klienten er i stand til at forbruge dem. Dette resulterer i en replikeringsforsinkelse for hver replikeringsforbindelse.

PostgreSQL giver en mekanisme til at forespørge om skriveforsinkelse (antal bytes sendt, men ikke skrevet til klientens disk), flush lag (antal bytes skrevet, men ikke tømt til klientens disk) og replay lag (antal bytes tømt, men ikke afspillet i klientens disk) databasefiler) for hver aktiv WAL-afsender.

Handling:Overvåg løbende replikeringsforsinkelser for aktive forbindelser, advars, hvis værdierne overstiger de fastsatte tærskler.

Sådan:

-- returns the write, flush and replay lags per WAL sender, as described above
SELECT write_lsn - sent_lsn AS write_lag,
       flush_lsn - write_lsn AS flush_lag,
       replay_lsn - flush_lsn AS replay_lag
  FROM pg_stat_replication;

7. Replikeringsforsinkelse for replikeringspladser

Ikke alene kan repikationsklienter halte, de kan også forsvinde helt på grund af nedbrud, topologiændringer eller menneskelige fejl. Det kan også være ved design, hvor kunderne ikke altid er online.

Hvis klienten understøttes af en replikeringsplads, bevares alle WAL-filer, der er nødvendige for, at klienten kan genoptages fra det punkt, den slap af, af PostgreSQL. WAL-filerne vil blive bevaret på ubestemt tid - der er ingen måde at sætte en grænse på. Når klienten opretter forbindelse igen, skal alle bevarede data streames til klienten først, hvilket kan involvere en masse disk- og netværkstrafik på den primære. Af disse grunde bør du også overvåge forsinkelsen på slot-niveau.

(Bemærk:WAL-afsenderprocessen kører kun, når en klient er tilsluttet, og den afsluttes, når klienten afbrydes. WAL-afsendermetoden til at måle, hvor langt efter klienten er, fungerer ikke, når en klient er afbrudt.)

Handling:Overvåg løbende replikeringsforsinkelser for logiske replikationsslots, advars, hvis værdier overstiger en fastsat tærskel.

Sådan:

-- returns the replication slot lag in bytes
-- (works only for logical replication slots)
SELECT pg_current_wal_lsn() - confirmed_flush_lsn
  FROM pg_replication_slots;

8. WAL-filantal

Håndtering af WAL-filer kan være en irriterende opgave, især hvis du har WALarchiving- eller streaming-replikeringsklienter. Antallet af WAL-filer kan begynde at stige uden nogen åbenbar grund, WAL-arkiveringsprocessen kan ikke holde trit med WAL-genereringshastigheden, og den samlede WAL-filstørrelse kan nå op på terabyte.

Som minimum skal du overvåge antallet af WAL-filer, der findes i din database-mappe og sikre, at antallet ser rimeligt ud til din implementering.

Handling:Overvåg kontinuerligt antallet af WAL-filer, advare, hvis værdien overstiger en fastsat tærskel.

Sådan:

-- returns the number of WAL files present in the pg_wal directory (v10+)
SELECT count(*)
  FROM pg_ls_waldir();

-- same, for v9.x
SELECT count(*)
  FROM pg_ls_dir('pg_xlog')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}$';

-- can also count the files physically present in $DBDIR/pg_wal
-- /bin/ls -l $DBDIR/pg_wal | grep -c '^-'

9. Klar til arkivering af WAL-filantal

Når WAL-arkivering er aktiveret, kalder PostgreSQL et brugerscript, hver gang en newWAL-fil genereres. Scriptet formodes at "arkivere" den enkelte WAL-fil, det blev kaldt til (det kopierer det typisk til en anden server eller en S3-bøtte). Hvis scriptet tager for lang tid at udføre sit arbejde, eller hvis det mislykkes, vil sættet af WAL-filer til blive arkiveret hober sig op.

Handling:Overvåg kontinuerligt antal WAL-filer, der er klar til arkivering, advars, hvis værdien overstiger en fastsat tærskel.

Sådan:

-- returns the number of WAL files ready to be archived (v12+)
SELECT count(*)
  FROM pg_ls_archive_statusdir()
 WHERE name ~ '^[0-9A-F]{24}.ready$';

-- same, for v10+
SELECT count(*)
  FROM pg_ls_dir('pg_wal/archive_status')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';

-- same, for v9.x
SELECT count(*)
  FROM pg_ls_dir('pg_xlog/archive_status')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';

-- can also count the *.ready files physically present in $DBDIR/pg_wal/archive_status
-- /bin/ls -l $DBDIR/pg_wal/archive_status | grep -c .ready

Indsamling af disse metrics

Sektionerne ovenfor giver SQL-sætninger til at udtrække de nødvendige metrics fra en kørende Postgres-server. Hvis du hellere ikke vil skrive scripts selv, så tjek open source-værktøjet pgmetrics. Den kan indsamle metrics ovenfor og mere og rapportere dem i tekst- og JSON-formater.

Du kan sende pgmetrics-rapporterne direkte til vores kommercielle tilbud, pgDash, som gemmer og behandler disse rapporter for at vise grafer og udføre advarsler.

Næste op

Yderligere dele i denne serie vil dække database-niveau, tabel-niveau, indeks-niveau og system-niveau metrikker. Hold dig opdateret!