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 terza e ultima parte di una serie di blog e copre le metriche a livello di tabella, indice e sistema. La prima copriva le metriche a livello di cluster e la seconda copriva le metriche a livello di database.
Livello tabella
In genere, i dati in un database seguono la regola 80-20. Il 20% delle tabelle contiene la maggior parte dei dati ed è quello a cui si accede o si modifica di più. L'impostazione di un monitoraggio aggiuntivo solo per queste tabelle può fornire informazioni importanti ma di basso volume.
Ecco alcune metriche a livello di tabella che vale la pena esaminare:
1. Dimensioni del tavolo
È necessario monitorare la dimensione effettiva del disco utilizzata dalla tabella. Nella maggior parte dei casi, la tabella continua a crescere, quindi è il tasso di crescita a essere più interessante.
Accade spesso che il tasso di crescita cambi dopo l'implementazione di una nuova versione dell'applicazione o una modifica di base nei modelli di traffico/carico/input dell'applicazione stessa. Tali modifiche devono essere esaminate, almeno per verificare che la nuova tariffa sia sostenibile dall'hardware fornito.
Azione:monitora l'aumento delle dimensioni della tabella ogni settimana/mese, analizza i cambiamenti improvvisi.
Come fare per:
-- returns the size for each table
SELECT schemaname || '.' || relname,
pg_size_pretty(pg_table_size(schemaname || '.' || relname))
FROM pg_stat_user_tables;2. Gonfiore da tavola
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 bloat, come numero assoluto di byte e percentuale (dati morti rispetto ai dati totali).
Questa metrica può essere monitorata sia a livello di singola tabella, sia come aggregato tra tabelle selezionate oa livello di database.
Azione:monitora continuamente il rigonfiamento della tabella come byte e percentuale, avvisa se i valori superano una soglia impostata, VACUUM se necessario.
Come fare per:
Usa check_postgres orpgmetrics per ottenere stime esagerate. Vedi il wiki per maggiori informazioni.
3. Scansioni sequenziali
Quando vengono eseguite query che non utilizzano in modo ottimale gli indici disponibili, o se le informazioni statistiche associate a una tabella sono troppo obsolete, Postgres potrebbe finire per dover scorrere ogni riga della tabella. Questo è chiamato scansione sequenziale , e non è molto desiderabile nel caso generale. Sarebbe meglio avere una scansione dell'indice , dove si accede alle righe di una tabella indirettamente tramite la ricerca nell'indice.
PostgreSQL può dirti quante volte una tabella è stata scansionata in sequenza e quante volte è stato utilizzato un indice. Puoi usarlo per monitorare il numero di scansioni sequenziali (se desideri evitarle totalmente) o come percentuale delle scansioni totali.
Azione:monitorare continuamente il seq. scansioni conteggio o percentuale, avvisa se il valore supera una soglia impostata.
Come fare per:
-- returns the no. of seq. scans and the percentage of seq. scans for each table
SELECT schemaname || '.' || relname,
seq_scan,
round(seq_scan::numeric*100/(seq_scan+idx_scan), 1)
FROM pg_stat_user_tables
WHERE seq_scan+idx_scan > 0;Livello indice
1. Dimensione indice
Gli indici possono occupare molto spazio su disco. Ogni indice di una tabella può avere potenzialmente lo stesso footprint del disco della tabella stessa. È utile tenere d'occhio la dimensione totale degli indici in un database o gli indici di tabelle importanti, specialmente nelle distribuzioni in cui gli indici possono essere creati tramite processi automatici.
Indici irragionevolmente grandi possono essere dovuti a bloat o semplicemente a un indice mal progettato. In entrambi i casi, la correzione della causa (ricostruendo l'indice o refactoring della query/indice) può produrre tempi di query più rapidi, quindi vale la pena indagare su indici di grandi dimensioni.
Azione:monitora la dimensione totale degli indici interessanti su ogni settimana/mese, analizza quando irragionevolmente grandi.
Come fare per:
-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
pg_size_pretty(pg_total_relation_size(indexrelid))
FROM pg_stat_user_indexes;2. Rigonfiamento dell'indice
Anche gli indici possono gonfiarsi. Ci sono troppi fattori, incluso il carico di lavoro della tabella, il tipo di indice, la versione di Postgres e altro, che decidono quanto diventa gonfio l'anindex. 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 dell'indice 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.
3. Rapporto cache hit
PostgreSQL memorizza nella cache le regioni di indici (e anche tabelle) a cui si accede di frequente. Se hai ottimizzato le tue query in modo che non tocchino le tabelle se non per recuperare le righe, il passaggio successivo consiste nell'assicurare la massima residenza nella cache per quegli indici importanti che stanno davvero velocizzando le tue query.
L'utilizzo della cache di un indice può essere misurato dalla percentuale di hit della cache, che è la percentuale di blocchi dell'indice letti dalla cache rispetto al numero totale di blocchi letti.
Azione:monitora continuamente la percentuale di hit ratio della cache, avvisa se il valore scende al di sotto di una soglia impostata. Esamina valori bassi per indici importanti.
Come fare per:
-- returns the cache hit ratio as a percentage, for each index
SELECT schemaname || '.' || indexrelname AS index_name,
round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 /
pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio
FROM pg_stat_user_indexes
WHERE pg_stat_get_blocks_fetched(indexrelid) > 0
ORDER BY cache_hit_ratio DESC;Livello di sistema
Oltre alle metriche di PostgreSQL, è importante tenere traccia di alcune metriche della macchina o della VM su cui stai eseguendo Postgres. Puoi utilizzare qualsiasi soluzione di monitoraggio popolare per questo, o anche prenderli e rintracciarli tu stesso.
1. Memoria utilizzata
I moderni sistemi Linux hanno una contabilità della memoria complessa. Si consiglia di monitorare la "memoria utilizzata", ovvero la memoria rimasta dopo aver tenuto conto della memoria contrassegnata come libera , come buffer , come memorizzato nella cache e come lastra . Buffer e cache cederanno sotto pressione, così come la maggior parte (in genere oltre il 95%) dello slab.
La memoria utilizzata, tuttavia, deve essere misurata su un periodo adeguatamente lungo. Se disponi di lavori batch, report, ETL ecc. che vengono eseguiti nei fine settimana, il periodo sarebbe di una settimana. La vera metrica che dovrai monitorare è la memoria massima utilizzata in questo periodo.
In genere, all'aumentare delle dimensioni del database, questo valore tende ad aumentare. Dovrai assicurarti che il massimo utilizzo della memoria rientri in un comodo limite di memoria disponibile, ad esempio 60-80%. Trascurare ciò causerebbe il fallimento dei carichi di lavoro di analisi/OLAP per mancanza di memoria.
Azione:monitora la memoria massima utilizzata nell'arco di una settimana/pernottamento, avvisa se supera una soglia impostata, riapprovvigionamento.
Come fare per :
La memoria utilizzata è data da MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab , dove il Mem* i campi provengono da /proc/meminfo . Per ulteriori informazioni, vedere questo articolo di RedHat.
2. Carico medio
Il valore medio del carico semplice è ancora il modo più semplice e veloce per stimare il carico su un server. Ciò è particolarmente vero per i server Postgres, poiché ciascun backend è un processo del sistema operativo separato e averne più in uno stato eseguibile aumenterà il valore medio del carico.
Per un determinato server Postgres, la media del carico dovrebbe rimanere entro un intervallo ragionevole per un ciclo lavorativo (ad esempio una settimana, comprese le esecuzioni di processi batch).
Azione:monitora la media del carico massimo su ogni giorno/settimana, analizzando le tendenze in aumento.
Come fare per :
Le medie di carico di 1 minuto, 5 minuti e 15 minuti sono i primi 3 campi della prima riga nel file /proc/loadavg .
3. Spazio libero su disco
L'ultimo elemento della nostra lista è l'elemento più ovvio da monitorare:la quantità di spazio libero su disco in ciascun filesystem utilizzato dal server PostgreSQL, inclusi tablespace, directory di file WAL, directory di backup e file di registro del server. Nei casi in cui vengono creati troppi file (centinaia di milioni) in un unico filesystem, assicurarsi che venga monitorato anche il conteggio degli inode gratuiti. Viene anche segnalata la mancanza di inode come spazio su disco insufficiente.
Azione:monitora continuamente lo spazio libero su disco e l'utilizzo degli inode su tutti i filesystem rilevanti, avvisa se i valori scendono al di sotto di una soglia prestabilita.
Come fare per :
Lo spazio libero su disco in un filesystem non è recuperabile direttamente leggendo qualsiasi file in /proc . Puoi usare stat -f /path/to/mount o anche df per scoprire lo spazio su disco utilizzato, libero e riservato per uno specifico filesystem montato.
Riferimento rapido
Ecco un elenco completo di tutte le metriche che abbiamo discusso finora in questa serie. Ricorda che queste sono solo le metriche minime ed essenziali che devi monitorare per rilevare quando le cose stanno per andare male con la tua distribuzione di PostgreSQL.
Livello cluster
- Intervallo ID transazione
- Numero di backend
- Slot di replica inattivi
- Backend in attesa di blocchi
- Backend inattivi nella transazione
- Ritardo di replica per connessioni attive
- Ritardo di replica per slot di replica
- Conteggio file WAL
- Conteggio file WAL pronti per l'archiviazione
Livello database
- Clienti connessi
- Taglia
- Tabella rigonfia su tutte le tabelle
- Rigonfiamento dell'indice su tutti gli indici
- Transazioni di lunga durata
- Blocchi di stallo
- Il più vecchio aspirapolvere
- Analisi meno recente
Livello tabella
- Dimensioni del tavolo
- Bloat da tavolo
- Scansioni sequenziali
Livello indice
- Dimensione dell'indice
- Rigonfiamento dell'indice
- Rapporto hit cache
Livello di sistema
- Memoria utilizzata
- Carico medio
- Spazio libero su disco
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.
