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.
Questa è la seconda parte di una serie di blog e copre i parametri a livello di database. La prima riguarda i parametri a livello di cluster.
Parte 2:livello di database
In questa parte, esamineremo le metriche e le informazioni che dovrebbero essere monitorate per ogni database importante che utilizzi.
La maggior parte delle query SQL elencate di seguito devono essere eseguite mentre si è connessi al database in questione.
1. Clienti connessi
I client connessi occupano il sistema operativo e le risorse di sistema. Postgres ha un'architettura processo per client e troppi client possono rallentare i tempi di risposta alle query per sempre. Prendi in considerazione l'utilizzo di PgBouncer orpgpool per ridurre il numero di connessioni che il server Postgres dovrà servire.
Tieni d'occhio le modifiche alla linea di base dopo gli aggiornamenti delle applicazioni e le interruzioni dovute all'aumento del traffico.
Azione:monitora il numero massimo di clienti connessi ogni giorno/settimana, analizza i cambiamenti di tendenza.
Come fare per:
-- returns the number of clients connected for each database
SELECT datname, count(*)
FROM pg_stat_activity
GROUP BY datname;2. Taglia
È necessario monitorare la dimensione effettiva del disco utilizzata dal database. Nella maggior parte dei casi, la dimensione del database continua a crescere, quindi è il tasso di crescita che è più interessante. Ancora una volta, fai attenzione all'aumento del tasso di crescita dopo il rilascio di nuove applicazioni.
Azione:monitorare la crescita delle dimensioni del database nel corso di ogni settimana/mese, analizzare le tendenze, effettuare nuovamente il provisioning.
Come fare per:
-- returns the size for each database
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database;3. Tavolo gonfio su tutti i tavoli
A causa dell'architettura MVCC di Postgres, le versioni precedenti delle righe si trovano nei file di dati fisici di ogni tabella e vengono chiamate gonfie . L'operazione per eliminare le versioni di riga obsolete è denominata vuoto . Postgres esegue un processo in background chiamato autovacuum , che preleva le tabelle candidate (in base a parametri configurabili) e le aspira per te.
Bloat rallenta le operazioni sul tavolo e spreca spazio su disco e può scappare anche con l'autovacuum. È richiesto il monitoraggio del rigonfiamento, come numero assoluto di byte e percentuale (dai morti rispetto ai dati totali). Questo può essere fatto a livello di database come un totale di tutte le tabelle, con la possibilità di approfondire le "tabelle più gonfie".
Azione:monitora continuamente il rigonfiamento totale come byte e percentuale, avvisa se i valori superano una soglia impostata.
Come fare per:
Usa check_postgres orpgmetrics per ottenere stime esagerate. Vedi il wiki per maggiori informazioni.
4. Rigonfiamento dell'indice su tutti gli indici
Gli indici gonfiati possono rallentare gli inserimenti e ridurre le prestazioni di ricerca. Monitora il volume degli indici sia come valore assoluto (numero di byte) che come percentuale. Gli indici dovranno essere ricostruiti quando diventano troppo gonfi.
Azione:monitora continuamente il rigonfiamento totale come byte e percentuale, avvisa se i valori superano una soglia impostata.
Come fare per:
Usa check_postgres orpgmetrics per ottenere stime esagerate. Vedi il wiki per maggiori informazioni.
5. Transazioni di lunga durata
Le transazioni aperte per troppo tempo non sono buone notizie per PostgreSQL. Le transazioni di lunga durata possono causare la conservazione dei file WAL, possono rimanere bloccati e prevenire il vuoto. Le applicazioni dovrebbero essere progettate per mantenere la durata delle transazioni il più bassa possibile.
Un backend che esegue una transazione di lunga durata può essere terminato con pg_cancel_backend() e pg_terminate_backend() funzioni.
Azione:monitora continuamente il conteggio delle transazioni che sono state eseguite per più di un periodo di tempo impostato, avvisa se i valori superano una soglia impostata.
Come fare per:
-- returns the count of transactions that have been running for more than a day
SELECT count(*)
FROM pg_stat_activity
WHERE xact_start < now() - '24 hours'::interval;6. Deadlock
In PostgreSQL, i backend posizionano i blocchi su righe e tabelle in modo implicito mentre eseguono query che modificano le righe. Le query possono anche inserire blocchi espliciti (come SELECT .. FOR UPDATE ). Proprio come nella programmazione multi-thread, due transazioni che posizionano blocchi, in modo implicito o esplicito, in ordine opposto possono causare un deadlock.
PostgreSQL rileverà i deadlock e eseguirà il rollback di una delle transazioni coinvolte (tutti i blocchi mantenuti da una transazione vengono rilasciati quando viene eseguito il commit o il rollback). I dettagli verranno registrati nella destinazione di registrazione di PostgreSQL.
Le applicazioni dovrebbero essere progettate per evitare la possibilità di deadlock. Possono anche scegliere di riprovare una transazione in caso di deadlock.
Azione:monitora i conteggi dei deadlock ogni giorno/settimana, riprogetta l'applicazione per ridurre il numero, esamina le modifiche.
Come fare per:
Le occorrenze di deadlock, insieme a informazioni aggiuntive, vengono registrate nel file di registro PostgreSQL. Usa pgmetrics, pgbagger o altri strumenti di elaborazione dei log specifici di PostgreSQL per estrarre queste informazioni.
7. Il più vecchio aspirapolvere
L'aspirazione regolare dei tavoli, sia con autovuoto, sia con lavori programmati, o manualmente, è un must per mantenere veloci le operazioni del tavolo. Tuttavia, i vuoti possono fallire per vari motivi, incluse transazioni di lunga durata, slot di replica inattivi ecc.
Poiché l'aspirazione regolare dei tavoli è piuttosto importante nel mondo Postgres, è meglio controllare regolarmente se tutti i tavoli sono stati aspirati almeno una volta in un intervallo prestabilito.
E sebbene tendano a essere fuori dalla vista e fuori dalla mente, anche i catalogabili del sistema dovrebbero essere aspirati.
Azione:controlla continuamente se una tabella non è stata aspirata nell'ultimo numero di ore/giorni impostato, avvisa se presente.
Come fare per:
-- returns the top 5 tables vacuumed least recently
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
ORDER BY last_vacuum ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been vacuumed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
WHERE last_vacuum < now() - '7 days'::interval;8. Analisi più antica
Per eseguire le tue query SELECT, il pianificatore di query prepara un piano di esecuzione che descrive quali indici e tabelle devono essere letti e come. Per elaborare un piano di esecuzione efficiente, il pianificatore deve disporre di statistiche sulla distribuzione dei valori, sulle dimensioni delle tuple e così via. Tali informazioni statistiche sui dati in una tabella vengono raccolte e mantenute da analyze operazioni. Le tabelle con statistiche aggiornate generano query più veloci e I/O inferiori.
Il processo di autovacuum sopra menzionato in genere esegue anche ANALYZE sul tavolo aspira per mantenere queste informazioni aggiornate. Tuttavia, questo da solo potrebbe non fornire una copertura di analisi sufficiente per le tue tabelle. Ti consigliamo di integrare eseguendo ANALYZE come processi pianificati o dopo significative mutazioni di tabella.
Nell'interesse delle prestazioni delle query, è meglio controllare continuamente se tutte le tabelle sono state analizzate almeno una volta in un intervallo prestabilito.
Azione:controlla continuamente se una tabella non è stata analizzata nell'ultimo numero di ore/giorni impostato, avvisa se presente.
Come fare per:
-- returns the top 5 tables analyzed least recently
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
ORDER BY last_analyze ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been analyzed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
WHERE last_analyze < now() - '7 days'::interval;Raccolta 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
La parte successiva di questa serie tratterà le metriche a livello di tabella, di indice e di sistema. Resta sintonizzato!
