Essentiële PostgreSQL-bewaking - Deel 1

Welke statistieken van uw PostgreSQL-implementatie moet u controleren? Deze reeks blogposts is bedoeld om een ​​minimale basisset van essentiële monitoringacties te bieden die u moet implementeren om de gezondheid en stabiliteit van uw Postgres-servers te waarborgen.

Het eerste deel behandelt parameters op clusterniveau.

Deel 1:Clusterniveau

In Postgres-jargon, een cluster is een set databases die wordt beheerd door een enkele Postgres-serverinstantie. Functies zoals replicatie en WAL-archiefwerk op clusterniveau.

1. Bereik transactie-ID

Vanuit het perspectief van een normale klant lijken de gegevensbestanden van een PostgreSQL-cluster de momentopname van gegevens te bevatten zoals gewijzigd door de laatste vastgelegde transactie. Vanwege de MVCC-architectuur van Postgres bevatten de fysieke bestanden echter niet alleen de gegevens voor de meest recente transactie, maar voor een reeks transacties die eindigen op de laatste. (Regelmatig stofzuigen verwijdert de gegevens voor de oudere transacties.)

Elke transactie heeft een unieke 32-bits integer-ID, genaamd detransactie-ID . Om verschillende redenen moet het verschil tussen de eerste en de laatste transactie-ID kleiner zijn dan 2, wat neerkomt op ongeveer 2 miljard. Het is een must om het bereik ruim onder deze limiet te houden. – lees dit waargebeurde verhaal over wat er anders gebeurt.

Actie:controleer continu het transactie-ID-bereik, waarschuw als de waarde een ingestelde drempel overschrijdt.

Hoe:

-- 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. Aantal backends

Elke backend vertegenwoordigt ofwel een client die is verbonden met de server, of een systeembackend-proces (zoals een autostofzuiger, een achtergrondschrijver, enz.). Elke back-end is ook een OS-proces dat OS-bronnen zoals geheugen, open bestandsdescriptors enz. verbruikt. Te veel backends, meestal vanwege te veel clients of te veel langlopende query's, kunnen de OS-bronnen onder druk zetten en de reactietijd van query's voor elke client vertragen.

Actie:bewaak het maximale aantal backends per dag/week, onderzoek toenemende trends.

Hoe:

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

3. Inactieve replicatieslots

Replicatieslots worden gemarkeerd als 'inactief' wanneer de verbinding met de replicatieclient die met het slot is verbonden, wordt verbroken. Inactieve replicatieslots zorgen ervoor dat WAL-bestanden worden bewaard, omdat ze naar de client moeten worden verzonden wanneer deze opnieuw verbinding maakt en de slots actief worden. Inderdaad, het eerste dat u moet controleren of uw WAL-bestandstellingen niet afnemen, is kijken of u inactieve replicatieslots hebt.

Vaak zijn inactieve replicatieslots het resultaat van een back-upclient die is verwijderd, een slave die is verwijderd, promoties, failovers en dergelijke.

Actie:controleer continu op inactieve replicatieslots, waarschuw indien aanwezig.

Hoe:

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

4. Backends wachten op sloten

SQL-instructies kunnen er expliciet of impliciet voor zorgen dat andere SQL-instructies wachten. Bijvoorbeeld, het uitvoeren van een "SELECT .. FOR UPDATE" declareert expliciet een vergrendeling voor de geselecteerde rijen, en het uitvoeren van een "UPDATE" plaatst impliciete rij-exclusieve vergrendelingen. Andere SQL-instructies wanneer als u het slot tegenkomt, moet u wachten tot de eerste instructie het slot opgeeft, voordat u doorgaat met de uitvoering ervan.

Dit kan zich manifesteren als trage applicatieprestaties tijdens wekelijkse rapportageruns, time-outtransacties/webpagina's en dergelijke.

Hoewel een zekere mate van vergrendeling niet kan worden vermeden, vraagt ​​een toenemende trend van backends die wachten op vergrendelingen er doorgaans om dat query's of applicatielogica worden geherstructureerd.

Actie:controleer het maximale aantal backends dat elke dag/week op sloten wacht, onderzoek toenemende trends.

Hoe:

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

5. Backends inactief in transactie

Langlopende transacties zijn niet erg prettig om te hebben in de PostgreSQL-wereld. Ze kunnen ervoor zorgen dat WAL-bestanden zich ophopen, autovacuüm en handmatig vacuüm voorkomen en bronnen verbruiken. Er kan niet veel worden gedaan aan echte transacties die lang duren om te voltooien, maar er zijn gevallen zoals apps/scripts die zich misdragen en af ​​en toe een psql-client die transacties start maar deze niet sluit. Backends die dergelijke klanten bedienen, verschijnen als "inactief in transactie".

Backends die inactief zijn in transactie, moeten worden gedetecteerd en afgesloten voordat ze de systeemstabiliteit gaan beïnvloeden.

Actie:controleer continu het aantal backends dat inactief is tijdens een transactie, controleer of deze worden gevonden.

Hoe:

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

6. Replicatievertraging voor actieve verbindingen

Wanneer er actieve streaming-replicatieclients (zoals hot standbys) of actieve logische replicatieclients zijn, voert Postgres een systeembackend uit met de naam WAL-afzender voor elke actieve (verbonden) client. De WAL-afzender is verantwoordelijk voor het verzenden van de WAL-recordgegevens die de klant nodig heeft.

Replicatieclients proberen doorgaans zoveel mogelijk gelijke tred te houden met de primaire. Soms kan de WAL-generatiesnelheid aan de primaire kant echter hoger worden dan de snelheid waarmee de klant ze kan consumeren. Dit resulteert in een replicatievertraging voor elke replicatieverbinding.

PostgreSQL biedt een mechanisme voor het opvragen van schrijfvertraging (aantal bytes verzonden maar niet geschreven naar de schijf van de client), flushvertraging (aantal bytes geschreven maar niet weggespoeld naar de schijf van de databasebestanden) voor elke actieve WAL-afzender.

Actie:controleer continu replicatievertragingen voor actieve verbindingen, waarschuw als waarden de ingestelde drempels overschrijden.

Hoe:

-- 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. Replicatievertraging voor replicatieslots

Repication-clients kunnen niet alleen achterblijven, ze kunnen ook helemaal verdwijnen vanwege crashes, topologiewijzigingen of menselijke fouten. Het kan ook een ontwerp zijn, waarbij klanten niet altijd online zijn.

Als de client wordt ondersteund door een replicatieslot, worden alle WAL-bestanden die de client nodig heeft om verder te gaan vanaf het punt waar hij was gebleven, bewaard door PostgreSQL. De WAL-bestanden worden voor onbepaalde tijd bewaard - er is geen manier om een ​​limiet in te stellen. Wanneer de client opnieuw verbinding maakt, moeten alle bewaarde gegevens eerst naar de client worden gestreamd, wat veel schijf- en netwerkverkeer op de primaire kan veroorzaken. Om deze redenen moet je de vertraging ook op slot-niveau in de gaten houden.

(Opmerking:het WAL-afzenderproces wordt alleen uitgevoerd wanneer een client is verbonden en wordt afgesloten wanneer de client de verbinding verbreekt. De WAL-afzendermethode om te meten hoe ver achter een client is, werkt niet wanneer een client is losgekoppeld.)

Actie:controleer continu replicatievertragingen voor logische replicatieslots, waarschuw als waarden een ingestelde drempel overschrijden.

Hoe:

-- 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. Aantal WAL-bestanden

Het beheren van WAL-bestanden kan een vervelende taak zijn, vooral als u WALarchiving- of streamingreplicatieclients hebt. Het aantal WAL-bestanden kan zonder duidelijke reden toenemen, het WAL-archiveringsproces kan de WAL-generatiesnelheid niet bijhouden en de totale WAL-bestandsgrootte kan terabytes bedragen.

U moet op zijn minst het aantal WAL-bestanden in uw databasedirectory controleren en ervoor zorgen dat het aantal er redelijk uitziet voor uw implementatie.

Actie:controleer continu het aantal WAL-bestanden, waarschuw als de waarde een ingestelde drempel overschrijdt.

Hoe:

-- 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. Aantal WAL-bestanden klaar om te archiveren

Wanneer WAL-archivering is ingeschakeld, roept PostgreSQL een gebruikersscript aan telkens wanneer een nieuw WAL-bestand wordt gegenereerd. Het script wordt verondersteld het enkele WAL-bestand te "archiveren" waarvoor het is aangeroepen (het kopieert het meestal naar een andere server of een S3-bucket). gearchiveerd worden stapelt zich op.

Actie:controleer continu het aantal WAL-bestanden die klaar zijn om te archiveren, waarschuw als de waarde een ingestelde drempel overschrijdt.

Hoe:

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

Deze statistieken verzamelen

De bovenstaande secties bieden SQL-instructies om de benodigde metrieken te extraheren uit een draaiende Postgres-server. Als je de scripts liever niet zelf schrijft, bekijk dan de open source tool pgmetrics. Het kan de bovenstaande statistieken en meer verzamelen en deze rapporteren in tekst- en JSON-indeling.

U kunt de pgmetrics-rapporten rechtstreeks naar ons commerciële aanbod, pgDash, sturen, die deze rapporten opslaat en verwerkt om grafieken weer te geven en waarschuwingen uit te voeren.

Volgende Omhoog

Verdere delen in deze serie gaan over metrische gegevens op databaseniveau, tabelniveau, indexniveau en systeemniveau. Blijf op de hoogte!