Viktig PostgreSQL-övervakning - Del 1

Vilka mätvärden för din PostgreSQL-distribution bör du övervaka? Denna serie av blogginlägg syftar till att tillhandahålla en minimal startuppsättning av viktiga övervakningsåtgärder som du bör implementera för att säkerställa hälsan och stabiliteten hos dina Postgres-servrar.

Den första delen täcker parametrar på klusternivå.

Del 1:Klusternivå

I Postgres-jargong, ett kluster är en uppsättning databaser som hanteras av en singlePostgres-serverinstans. Funktioner som replikering och WAL-arkivering fungerar på klusternivå.

1. Transaktions-ID-intervall

Ur en normal klients perspektiv kommer datafilerna i ett PostgreSQL-kluster att tyckas innehålla ögonblicksbilden av data som modifierats av den senaste genomförda transaktionen. Men på grund av Postgres MVCC-arkitektur innehåller de fysiska filerna inte bara data för den senaste transaktionen, utan för en rad transaktioner som slutar med den senaste. (Vanlig dammsugning tar bort data för de äldre transaktionerna.)

Varje transaktion har en unik 32-bitars heltalsidentifierare, kallad transaktions-ID . Av olika anledningar bör skillnaden mellan första och sista transaktions-ID vara mindre än 2, vilket är cirka 2 miljarder. Att hålla intervallet långt under denna gräns är ett måste – läs denna verkliga berättelse om vad som händer annars.

Åtgärd:Övervaka kontinuerligt transaktions-ID-intervallet, varna om värdet överstiger en inställd tröskel.

Så här gör du:

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

Varje backend representerar antingen en klient som är ansluten till servern eller en systembackend-process (som automatisk vakuumarbetare, bakgrundsskrivare etc). Varje backend är också en OS-process som förbrukar OS-resurser som minne, öppna fildeskriptorer etc. För många backends, vanligtvis på grund av för många klienter eller för många långvariga frågor kan sätta press på OS-resurser och sakta ner frågesvarstider för varje klient.

Åtgärd:Övervaka det maximala antalet backend över varje dag/vecka, undersök ökande trender.

Så här gör du:

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

3. Inaktiva replikeringsplatser

Replikeringsplatser markeras som "inaktiva" när replikeringsklienten som är ansluten till platsen kopplas bort. Inaktiva replikeringsplatser gör att WAL-filer behålls, eftersom de måste skickas till klienten när den återansluts och platserna blir aktiva. Det första du bör kontrollera om dina WAL-filantal inte går ner är att se om du har inaktiva replikeringsplatser.

Ofta är inaktiva replikeringsplatser resultatet av en backupklient som togs bort, en slav som togs ner, kampanjer, failovers och liknande.

Åtgärd:Kontrollera kontinuerligt efter inaktiva replikeringsplatser, varna om några.

Så här gör du:

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

4. Backends som väntar på lås

SQL-satser kan explicit eller implicit få andra SQL-satser att vänta. Om du till exempel kör en "SELECT .. FOR UPDATE" deklarerar man uttryckligen ett lås för de valda raderna, och att köra en "UPDATE" placerar implicit radexklusiva lås. Andra SQL-satser när Om du stöter på låset måste du vänta tills det första uttalandet släpper låset, innan du fortsätter att köra det.

Detta kan visa sig som långsam applikationsprestanda under veckovisa rapportkörningar, timeout transaktioner/webbsidor och liknande.

Även om en viss mängd låsning inte kan undvikas, kräver en ökande trend av backends som väntar på lås vanligtvis frågor eller programlogik som ska omstruktureras.

Åtgärd:Övervaka det maximala antalet backends som väntar på lås varje dag/vecka, undersök ökande trender.

Så här gör du:

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

5. Backends inaktiv i transaktion

Långvariga transaktioner är inte särskilt trevliga att ha i PostgreSQL-världen. De kan få WAL-filer att byggas upp, förhindra autovakuum och manuellt vakuum och använda upp resurser. Inget mycket kan göras åt äkta transaktioner som tar lång tid att slutföra, men det finns fall som felaktiga appar/skript och en och annan psql-klient som startar transaktioner men inte stänger dem. Backends som betjänar sådana klienter visas som "tomgång i transaktion".

Backends som går på tomgång i transaktionen bör upptäckas och stängas av innan de börjar påverka systemstabiliteten.

Åtgärd:Övervaka kontinuerligt antalet backends som går på tomgång i transaktionen, granska om några hittas.

Så här gör du:

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

6. Replikeringsfördröjning för aktiva anslutningar

När det finns aktiva strömmande replikeringsklienter (som hot standbys) eller aktiva logiska replikeringsklienter, kör Postgres en systembackend som kallas enWAL-avsändare för varje aktiv (ansluten) klient. WAL-avsändaren är ansvarig för att skicka WAL-postdata som klienten behöver.

Replikeringsklienter försöker vanligtvis hänga med så mycket de kan med det primära. Ibland kan dock WAL-genereringshastigheten på primärsidan bli högre än den hastighet med vilken klienten kan konsumera dem. Detta resulterar i en replikeringsfördröjning för varje replikeringsanslutning.

PostgreSQL tillhandahåller en mekanism för att fråga efter skrivfördröjning (antal byte som skickats men inte skrivs till klientens disk), flush lag (antal byte skrivna men inte tömda till klientens disk) och replay lag (antal byte tömda men inte spelas om till klientens disk) databasfiler) för varje aktiv WAL-avsändare.

Åtgärd:Övervaka kontinuerligt replikeringsfördröjningar för aktiva anslutningar, varna om värden överskrider inställda tröskelvärden.

Så här gör du:

-- 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. Replikeringsfördröjning för replikeringsplatser

Inte bara kan replikeringsklienter släpa, de kan också försvinna helt på grund av krascher, topologiförändringar eller mänskliga fel. Det kan också vara designat, där kunderna inte alltid är online.

Om klienten backas upp av en replikeringsplats, behålls alla WAL-filer som krävs för att klienten ska kunna återupptas från den punkt den slutade av PostgreSQL. WAL-filerna kommer att behållas på obestämd tid – det finns inget sätt att sätta en gräns. När klienten ansluter igen måste all lagrad data strömmas till klienten först, vilket kan involvera mycket disk- och nätverkstrafik på den primära. Av dessa skäl bör du också övervaka fördröjningen på slot-nivå.

(Obs! WAL-avsändarprocessen körs endast när en klient är ansluten och avslutas när klienten kopplar från. WAL-avsändarmetoden för att mäta hur långt bakom klienten är fungerar inte när en klient kopplas bort.)

Åtgärd:Övervaka kontinuerligt replikeringsfördröjningar för logiska replikeringsplatser, varna om värden överskrider en inställd tröskel.

Så här gör du:

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

Att hantera WAL-filer kan vara en irriterande uppgift, speciellt om du har WALarchiving eller streaming-replikeringsklienter. Antalet WAL-filer kan börja öka utan någon uppenbar anledning, WAL-arkiveringsprocessen kan misslyckas med att hänga med WAL-genereringshastigheten och den totala WAL-filstorleken kan bli terabyte.

Som ett minimum måste du övervaka antalet WAL-filer som finns i din databaskatalog och se till att antalet ser rimligt ut för din distribution.

Åtgärd:Övervaka kontinuerligt antalet WAL-filer, varna om värdet överstiger en inställd tröskel.

Så här gör du:

-- 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. Redo att arkivera WAL-filantal

När WAL-arkivering är aktiverad, anropar PostgreSQL ett användarskript varje gång en newWAL-fil genereras. Skriptet är tänkt att "arkivera" den enda WAL-filen det anropades för (det kopierar det vanligtvis till en annan server eller en S3-bucket). Om skriptet tar för lång tid att göra sitt jobb, eller om det misslyckas, kommer uppsättningen WAL-filer till arkiveras.

Åtgärd:Övervaka kontinuerligt antalet WAL-filer som är redo att arkiveras, varna om värdet överstiger en inställd tröskel.

Så här gör du:

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

Samla in dessa mätvärden

Avsnitten ovan tillhandahåller SQL-satser för att extrahera nödvändiga mätvärden från en körande Postgres-server. Om du hellre inte vill skriva skripten själv, kolla in open source-verktyget pgmetrics. Den kan samla in mätvärdena ovan och mer och rapportera dem i text- och JSON-format.

Du kan skicka pgmetrics-rapporterna direkt till vårt kommersiella erbjudande, pgDash, som lagrar och bearbetar dessa rapporter för att visa grafer och utföra varningar.

Nästa upp

Ytterligare delar i denna serie kommer att täcka databasnivå, tabellnivå, indexnivå och systemnivå. Håll utkik!