Quali metriche della tua distribuzione di PostgreSQL dovresti monitorare? Questa serie di post del blog mira a fornire una serie minima iniziale di azioni di monitoraggio essenziali che dovresti implementare per garantire la salute e la stabilità dei tuoi server Postgres.
La prima parte riguarda i parametri a livello di cluster.
Parte 1:livello del cluster
Nel gergo di Postgres, un cluster è un insieme di database gestiti da una singola istanza del server Postgres. Funzionalità come la replica e l'archiviazione WAL funzionano a livello di cluster.
1. Intervallo ID transazione
Dal punto di vista di un normale client, i file di dati di un cluster PostgreSQL sembreranno contenere lo snapshot dei dati come modificato dall'ultima transazione impegnata. Tuttavia, a causa dell'architettura MVCC di Postgres, i file fisici contengono non solo i dati per la transazione più recente, ma per una serie di transazioni che terminano con quella più recente. (Regolare aspirazione elimina i dati per le transazioni precedenti.)
Ogni transazione ha un identificatore intero a 32 bit univoco, chiamato ID transazione . Per vari motivi, la differenza tra il primo e l'ultimo ID transazione dovrebbe essere inferiore a 2, ovvero circa 2 miliardi. Mantenere l'intervallo ben al di sotto di questo limite è un must – leggi questa storia di vita reale di ciò che accade altrimenti.
Azione:monitora continuamente l'intervallo di ID transazione, avvisa se il valore supera una soglia impostata.
Come fare per:
-- 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. Numero di backend
Ogni back-end rappresenta un client connesso al server o un processo di back-end di sistema (come auto vacuum worker, background writer ecc.). Ogni backend è anche un processo del sistema operativo che consuma risorse del sistema operativo come memoria, descrittori di file aperti ecc. Troppi backend, in genere a causa di troppi client o troppe query di lunga durata possono mettere sotto pressione le risorse del sistema operativo e rallentare i tempi di risposta delle query per ogni client.
Azione:monitora il numero massimo di back-end per ogni giorno/settimana, analizza le tendenze in aumento.
Come fare per:
-- returns the count of currently running backends
SELECT count(*)
FROM pg_stat_activity;3. Slot di replica inattivi
Gli slot di replica sono contrassegnati come "inattivi" quando il client di replica connesso allo slot si disconnette. Gli slot di replica inattivi causano il mantenimento dei file WAL, poiché dovranno essere inviati al client quando si riconnette e gli slot diventano attivi. In effetti, la prima cosa da controllare se il numero di file WAL non diminuisce è vedere se hai slot di replica inattivi.
Spesso gli slot di replica inattivi sono il risultato di un client di backup che è stato rimosso, uno slave che è stato rimosso, promozioni, failover e simili.
Azione:controlla continuamente gli slot di replica inattivi, avvisa se ce ne sono.
Come fare per:
-- returns the count of inactive replication slots
SELECT count(*)
FROM pg_replication_slots
WHERE NOT active;4. Backend in attesa di blocchi
Le istruzioni SQL possono causare in modo esplicito o implicito l'attesa di altre istruzioni SQL. Ad esempio, l'esecuzione di "SELECT .. FOR UPDATE" dichiara esplicitamente un blocco per le righe selezionate e l'esecuzione di "UPDATE" inserisce blocchi esclusivi di riga impliciti. Altre istruzioni SQL quando incontrando il blocco dovrà attendere fino a quando la prima istruzione rinuncia al blocco, prima di continuare la sua esecuzione.
Ciò può manifestarsi come un rallentamento delle prestazioni dell'applicazione durante l'esecuzione di report settimanali, transazioni/pagine Web scadute e simili.
Sebbene non sia possibile evitare una certa quantità di blocchi, la tendenza crescente dei backend in attesa di blocchi richiede in genere la ristrutturazione delle query o della logica dell'applicazione.
Azione:monitora il numero massimo di backend in attesa di blocco ogni giorno/settimana, studia le tendenze in aumento.
Come fare per:
-- returns the count of backends waiting on locks
SELECT count(*)
FROM pg_stat_activity
WHERE wait_event = 'Lock';5. Backend inattivi nella transazione
Le transazioni di lunga durata non sono molto piacevoli da avere nel mondo PostgreSQL. Possono causare la creazione di file WAL, impedire l'autovuoto e il vuoto manuale e consumare risorse. Non si può fare molto per le transazioni autentiche che richiedono molto tempo per essere completate, ma ci sono casi come app/script che si comportano male e il client psql occasionale che avvia le transazioni ma non le chiude. I backend che servono tali client vengono visualizzati come "transazioni inattive".
I backend che sono inattivi nella transazione dovrebbero essere rilevati e chiusi prima che inizino a influenzare la stabilità del sistema.
Azione:monitora continuamente il numero di back-end inattivi nella transazione, verifica se ne vengono trovati.
Come fare per:
-- returns the count of backends waiting on locks
SELECT count(*)
FROM pg_stat_activity
WHERE state = 'idle in transaction';6. Ritardo di replica per connessioni attive
Quando sono presenti client di replica streaming attivi (come hot standbys) o client di replica logica attivi, Postgres esegue un back-end di sistema chiamato mittente WAL per ogni client attivo (connesso). Il mittente WAL è responsabile dell'invio dei dati del record WAL di cui il cliente ha bisogno.
I client di replica in genere cercano di tenere il passo il più possibile con il primario. A volte, tuttavia, la velocità di generazione WAL sul lato primario può diventare superiore alla velocità con cui il cliente è in grado di consumarli. Ciò provoca un ritardo di replica per ogni connessione di replica.
PostgreSQL fornisce un meccanismo per eseguire query per scrivere lag (n. di byte inviati ma non scritti sul disco del client), flush lag (n. di byte scritti ma non scaricati sul disco del client) e replay lag (n. di byte scaricati ma non riprodotti nel client file di database) per ogni mittente WAL attivo.
Azione:monitora continuamente i ritardi di replica per le connessioni attive, avvisa se i valori superano le soglie impostate.
Come fare per:
-- 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. Ritardo di replica per gli slot di replica
Non solo i client di replica possono ritardare, ma possono anche scomparire del tutto a causa di arresti anomali, modifiche della topologia o errori umani. Potrebbe anche essere di progettazione, dove i clienti non sono sempre online.
Se il client è supportato da uno slot di replica, tutti i file WAL necessari affinché il client riprenda dal punto in cui era stato interrotto vengono conservati da PostgreSQL. I file WAL verranno conservati a tempo indeterminato:non c'è modo di impostare un limite. Quando il client si riconnette, tutti i dati conservati devono essere trasmessi prima al client, il che può comportare molto traffico su disco e rete sul server primario. Per questi motivi, dovresti monitorare il ritardo anche a livello di slot.
(Nota:il processo del mittente WAL viene eseguito solo quando un client è connesso ed esce quando il client si disconnette. Il metodo del mittente WAL per misurare quanto è indietro il client non funziona quando un client viene disconnesso.)
Azione:monitora continuamente i ritardi di replica per gli slot di replica logica, avvisa se i valori superano una soglia impostata.
Come fare per:
-- 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. Conteggio file WAL
La gestione dei file WAL può essere un'attività esasperante, soprattutto se si dispone di client di archiviazione WAL o di replica in streaming. Il conteggio dei file WAL può iniziare ad aumentare senza alcuna ragione apparente, il processo di archiviazione WAL può non riuscire a tenere il passo con la velocità di generazione WAL e la dimensione totale del file WAL può arrivare a terabyte.
Come minimo, devi monitorare il conteggio dei file WAL presenti nella directory del tuo database e assicurarti che il numero sia ragionevole per la tua distribuzione.
Azione:monitora continuamente il conteggio dei file WAL, avvisa se il valore supera una soglia impostata.
Come fare per:
-- 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. Conteggio file WAL pronti per l'archiviazione
Quando l'archiviazione WAL è abilitata, PostgreSQL richiama uno script utente ogni volta che viene generato un nuovo file WAL. Lo script dovrebbe "archiviare" il singolo file WAL per cui è stato invocato (in genere lo copia su un altro server o un bucket S3). Se lo script impiega troppo tempo per svolgere il suo lavoro, o se fallisce, l'insieme di file WAL a essere archiviato si accumula.
Azione:monitora continuamente il conteggio dei file WAL pronti per l'archiviazione, avvisa se il valore supera una soglia impostata.
Come fare per:
-- 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 .readyRaccolta di queste metriche
Le sezioni precedenti forniscono istruzioni SQL per estrarre le metriche necessarie da un server Postgres in esecuzione. Se preferisci non scrivere tu stesso gli script, dai un'occhiata allo strumento open source pgmetrics. Può raccogliere le metriche sopra e altro ancora e segnalarle in formato testo e JSON.
Puoi inviare i rapporti pgmetrics direttamente alla nostra offerta commerciale, pgDash, che archivia ed elabora questi rapporti per visualizzare grafici ed eseguire avvisi.
Avanti
Ulteriori parti di questa serie riguarderanno le metriche a livello di database, tabella, indice e sistema. Resta sintonizzato!
