Ti propongo di dare un'occhiata alla trascrizione della relazione di Alexey Lesovsky di Data Egret "Nozioni fondamentali sul monitoraggio di PostgreSQL"
In questa relazione, Alexey Lesovsky parlerà dei punti chiave delle statistiche di PostgreSQL, del loro significato e del perché debbano essere incluse nel monitoraggio; dei grafici che dovrebbero essere presenti nel monitoraggio, di come aggiungerli e interpretarli. La relazione sarà utile per gli amministratori di database, gli amministratori di sistema e gli sviluppatori interessati alla risoluzione dei problemi di Postgres.
Mi chiamo Alexey Lesovsky e rappresento l'azienda Data Egret.
Un po' di informazioni su di me. Ho iniziato tanto tempo fa come amministratore di sistema.
Amministravo vari sistemi Linux, occupandomi di diverse questioni legate a Linux, come virtualizzazione, monitoraggio, lavorando con proxy, ecc. Ma a un certo punto ho cominciato a concentrarmi maggiormente sui database, in particolare su PostgreSQL. Mi è piaciuto molto e così, nel tempo, sono diventato un DBA di PostgreSQL.
E per tutta la mia carriera sono sempre stato interessato a temi come la statistica, il monitoraggio e la raccolta di telemetria. Quando ero un amministratore di sistema, ho lavorato molto con Zabbix. Ho scritto un piccolo set di script come . Era piuttosto popolare ai tempi. Lì si potevano monitorare diverse cose importanti, non solo Linux, ma anche vari componenti.
Ora mi occupo di PostgreSQL. Sto scrivendo un'altra cosa che permette di lavorare con le statistiche di PostgreSQL. Si chiama (articolo su Habr — ).
Una breve introduzione. Quali situazioni possono presentarsi ai nostri clienti? Si verifica un guasto legato al database. Una volta ripristinato il database, il capo del reparto o il responsabile dello sviluppo dice: «Ragazzi, dobbiamo monitorare il database, perché è successo qualcosa di brutto e dobbiamo evitare che succeda di nuovo in futuro». E qui inizia un processo interessante di scelta di un sistema di monitoraggio o adattamento del sistema di monitoraggio esistente per poter monitorare il proprio database – PostgreSQL, MySQL o altri. I colleghi iniziano a proporre: «Ho sentito dire che esiste tanto un quel tipo di database. Usiamo quello». I colleghi iniziano a discutere tra di loro. E alla fine, scegliamo un certo database, ma il monitoraggio di PostgreSQL è presentato piuttosto male e dobbiamo sempre aggiustare qualcosa. Prendere alcuni repository da GitHub, clonare, adattare script, configurare ulteriormente. Alla fine, questo si traduce in un certo lavoro manuale.
Pertanto, in questa relazione cercherò di offrirvi alcune conoscenze su come scegliere un sistema di monitoraggio non solo per PostgreSQL, ma anche per altri database. E fornire le conoscenze che vi permetteranno di migliorare il vostro monitoraggio, in modo da ottenere benefici dall'utilizzo, per poter monitorare il proprio database in maniera utile, per essere in grado di prevenire possibili situazioni di emergenza che potrebbero verificarsi.
Le idee presenti in questo rapporto possono essere direttamente adattate a qualsiasi database, sia esso un DBMS o un noSQL. Quindi non si parlerà solo di PostgreSQL, ma ci saranno molte ricette su come implementare questo in PostgreSQL. Ci saranno esempi di query, esempi di entità disponibili in PostgreSQL per il monitoraggio. E se il vostro DBMS presenta caratteristiche simili che possono essere integrate nel monitoraggio, potrete anche adattarle, aggiungerle e andrà bene.
Nella presentazione non parlerò
di come trasmettere e memorizzare le metriche. Non dirò nulla sulla post-elaborazione dei dati e su come fornirli all'utente. E non parlerò affatto di avvisi.
Ma nel corso della narrazione mostrerò diversi screenshot di monitoraggi esistenti, criticandoli in qualche modo. Tuttavia cercherò di non menzionare i marchi, per non fare pubblicità né antireclamo a questi prodotti. Pertanto, tutte le coincidenze sono casuali e rimangono nella vostra fantasia.
Iniziamo con il capire cosa sia il monitoraggio. Il monitoraggio è una cosa molto importante di cui avere bisogno. Tutti lo capiscono. Ma allo stesso tempo, il monitoraggio non è considerato un prodotto commerciale e non influisce direttamente sui profitti dell'azienda, quindi il tempo dedicato al monitoraggio è sempre un tempo residuale. Se abbiamo tempo, ci occupiamo del monitoraggio; se non abbiamo tempo, va bene, lo mettiamo in backlog e prima o poi torneremo a questi compiti.
Pertanto, dalla nostra esperienza, quando ci presentiamo dai clienti, il monitoraggio è spesso trascurato e non ha elementi interessanti che ci aiuterebbero a lavorare meglio con il database. E quindi il monitoraggio ha sempre bisogno di essere affinato.
I database sono sistemi complessi che devono anch'essi essere monitorati, perché i database sono contenitori di informazioni. E l'informazione è molto importante per l'azienda, non può in alcun modo essere persa. Ma allo stesso tempo, i database sono porzioni molto complesse di software. Sono composti da un grande numero di componenti. E molti di questi componenti devono essere monitorati.
Se parliamo specificamente di PostgreSQL, possiamo rappresentarlo come uno schema che consiste in un elevato numero di componenti. Questi componenti interagiscono tra loro. E allo stesso tempo, in PostgreSQL esiste una sottosistema chiamata Stats Collector, che consente di raccogliere statistiche sul funzionamento di questi sottosistemi e di fornire un certo interfaccia all'amministratore o all'utente, così che possa visualizzare queste statistiche.
Queste statistiche sono presentate sotto forma di un certo numero di funzioni e viste (view). Possono anche essere chiamate tabelle. Vale a dire, utilizzando un normale client psql puoi connetterti al database, eseguire un select su queste funzioni e viste, e ottenere già alcuni numeri concreti sul funzionamento dei sottosistemi di PostgreSQL.
Puoi aggiungere questi numeri al tuo sistema di monitoraggio preferito, disegnare grafici, aggiungere funzioni e ottenere analisi a lungo termine.
Ma in questo rapporto non prenderò in considerazione tutte queste funzionalità, perché questo potrebbe richiedere un'intera giornata. Mi concentrerò letteralmente su due, tre o quattro aspetti e parlerò di come aiutano a migliorare il monitoraggio.
E se parliamo del monitoraggio del database, cosa bisogna monitorare? Prima di tutto è necessario monitorare la disponibilità, perché il database è un servizio che fornisce accesso ai dati ai clienti, e dobbiamo monitorare la disponibilità, che include anche alcune caratteristiche qualitative e quantitative.
È anche importante monitorare i clienti che si connettono al nostro database, poiché possono essere sia clienti normali che clienti dannosi, i quali potrebbero provocare danni al database. Anche loro devono essere monitorati e dobbiamo seguire la loro attività.
Quando i clienti si collegano al database, è ovvio che iniziano a lavorare con i nostri dati, perciò dobbiamo monitorare anche come i clienti interagiscono con i dati: con quali tabelle, e in misura minore con quali indici. In altre parole, dobbiamo valutare il carico di lavoro (workload) generato dai nostri clienti.
Ma il carico di lavoro consiste ovviamente in richieste. Le applicazioni si connettono al database, accedono ai dati tramite richieste, quindi è importante valutare quali richieste abbiamo nel database, monitorare la loro adeguatezza, assicurarsi che non siano scritte male, e che alcune opzioni debbano essere riscritte e ottimizzate per funzionare più velocemente e con migliori prestazioni.
E poiché parliamo di database, dobbiamo ricordare che un database è sempre composto da processi in background. I processi in background aiutano a mantenere le prestazioni del database a un buon livello, quindi per il loro funzionamento richiedono una certa quantità di risorse. Allo stesso tempo, queste risorse possono sovrapporsi a quelle delle richieste dei clienti, quindi un uso eccessivo delle risorse da parte dei processi in background può influenzare direttamente le prestazioni delle richieste dei clienti. Pertanto, anche questi processi devono essere monitorati e dobbiamo assicurarci che non ci siano sbilanciamenti nel funzionamento dei processi in background.
E tutto ciò nel monitoraggio del database rimane nella metrica di sistema. Ma considerando che gran parte della nostra infrastruttura si sta spostando nel cloud, le metriche di sistema di un host singolo passano sempre in secondo piano. Tuttavia, nelle database sono ancora rilevanti e monitorare le metriche di sistema è certamente necessario.
Con le metriche di sistema tutto sommato va bene, tutti i moderni sistemi di monitoraggio supportano già queste metriche, ma in generale alcune componenti sono comunque insufficienti e alcune cose devono essere aggiunte. Di esse ne parlerò, ci saranno alcune diapositive a riguardo.
Il primo punto del piano è la disponibilità. Cos'è la disponibilità? La disponibilità, a mio avviso, è la capacità del database di servire le connessioni, cioè il database è attivo e, come servizio, accetta le connessioni dai clienti. E questa disponibilità può essere valutata tramite alcune caratteristiche. È molto comodo portare queste caratteristiche sui dashboard.
Tutti sanno cosa sono i dashboard. È quando lanci uno sguardo allo schermo, dove è raccolta l'informazione necessaria. E puoi già determinare subito se ci sono problemi nel database o no.
Di conseguenza, la disponibilità del database e altre caratteristiche chiave devono sempre essere visualizzate sui dashboard affinché queste informazioni siano a portata di mano, sempre con te. Alcuni dettagli aggiuntivi, che aiutano già nell'indagine degli incidenti o delle situazioni di emergenza, devono essere mostrati su dashboard secondari, o nascosti in link di drilldown che portano a sistemi di monitoraggio esterni.
Un esempio di un noto sistema di monitoraggio. È un sistema di monitoraggio davvero eccezionale. Raccoglie una grande quantità di dati, ma dal mio punto di vista ha una concezione strana di dashboard. C'è un link "crea dashboard". Ma quando crei un dashboard, stai creando una sorta di elenco composto da due colonne, una sorta di elenco di grafici. E quando devi controllare qualcosa, inizi a cliccare con il mouse, sfogliare, cercare il grafico giusto. E questo richiede tempo, cioè i dashboard, come tali, non esistono. Ci sono solo elenchi di grafici.
Cosa bisogna aggiungere a questi dashboard? Si può iniziare da una caratteristica come il tempo di risposta. In PostgreSQL c'è la vista pg_stat_statements. Di default è disabilitata, ma è una delle viste sistemiche più importanti che bisogna sempre attivare e utilizzare. Contiene informazioni su tutte le query che sono state eseguite nel database.
Pertanto, possiamo partire dal fatto che si può prendere il tempo totale di esecuzione di tutte le query e dividerlo per il numero di query utilizzando i campi sopra citati. Ma questo è solo una media generale. Possiamo considerare altri campi: il tempo minimo, il tempo massimo e quello mediano per l'esecuzione delle query. Possiamo persino calcolare i percentili; in PostgreSQL ci sono funzioni adatte per questo. E possiamo ottenere dei numeri che caratterizzano il tempo di risposta del nostro database in base alle query già eseguite, cioè non stiamo eseguendo una query fittizia 'select 1' per vedere il tempo di risposta, ma stiamo analizzando i tempi di risposta delle query già completate, e disegniamo i risultati o come un numero singolo oppure costruiamo un grafico.
È anche importante monitorare il numero di errori che il sistema sta generando in quel momento. E per questo si può utilizzare la vista pg_stat_database. Ci concentriamo sul campo xact_rollback. Questo campo mostra non solo il numero di rollback che avvengono nel database, ma tiene anche conto degli errori. In termini semplici, possiamo mostrare questo numero nel nostro dashboard e vedere quanti errori abbiamo al momento. Se ci sono molti errori, è già un buon motivo per controllare i log e vedere quali errori si stanno verificando e perché, e successivamente investigare e risolverli.
Si può aggiungere una cosa come il Tachimetro. Questo misura il numero di transazioni al secondo e il numero di query al secondo. In termini semplici, si possono utilizzare questi numeri come attuale performance del proprio database e osservare se ci sono picchi di query, picchi di transazioni o, al contrario, se il database è sotto carico perché qualche backend è andato in crash. È fondamentale monitorare sempre questo numero e ricordare che per il nostro progetto una certa performance è considerata normale, mentre valori più elevati o inferiori sono anomali e richiedono attenzione per capire perché si registrano tali numeri.
Per valutare il numero di transazioni, possiamo nuovamente fare riferimento alla vista pg_stat_database. Possiamo sommare il numero di commit e il numero di rollback e ottenere così il numero di transazioni al secondo.
Tutti comprendono che in una transazione possono rientrare più richieste? Ecco perché TPS e QPS sono un po' diversi.
Il numero di richieste al secondo può essere ottenuto tramite pg_stat_statements e calcolando semplicemente la somma di tutte le richieste eseguite. È chiaro che stiamo confrontando il valore attuale con quello precedente, sottraendo, ottenendo la delta e quindi il numero.
Si possono aggiungere metriche aggiuntive, se lo si desidera, che aiutano anche a valutare la disponibilità del nostro database e a monitorare eventuali downtime.
Una di queste metriche è l'uptime. Ma l'uptime in PostgreSQL è una cosa un po' complicata. Spiegherò perché. Quando PostgreSQL viene avviato, inizia a contare l'uptime. Ma se in un certo momento, ad esempio di notte, viene eseguita qualche operazione e l'OOM-killer termina forzatamente un processo secondario di PostgreSQL, in quel caso PostgreSQL termina la connessione di tutti i client, resetta lo spazio di memoria sharded e inizia il ripristino dall'ultimo checkpoint. E mentre dura questo ripristino dal checkpoint, il database non accetta connessioni, cioè questa situazione può essere valutata come downtime. Tuttavia, il contatore dell'uptime non si resetta, poiché considera il tempo di avvio del postmaster fin dal primo momento. Pertanto, si possono trascurare situazioni di questo tipo.
È inoltre importante monitorare il numero di worker di vacuum. Tutti sanno cos'è l'autovacuum in PostgreSQL? È un sottosistema interessante in PostgreSQL. Sono stati scritti molti articoli, sono state fatte molte presentazioni su di esso. Ci sono molte discussioni sul vacuum e su come dovrebbe funzionare. Molti lo considerano un male inevitabile. Ma è così. È un qualche tipo di analogia con un garbage collector che pulisce le versioni obsolete delle righe che non sono necessarie a nessuna delle transazioni e libera spazio nelle tabelle, negli indici per nuove righe.
Perché è necessario monitorarlo? Perché il vacuum a volte fa molto male. Consuma molte risorse e le richieste dei clienti iniziano a soffrirne.
E dovremmo monitorarlo attraverso la vista pg_stat_activity, di cui parlerò nel prossimo paragrafo. Questa vista mostra l'attività corrente nel database. E attraverso questa attività possiamo tracciare il numero di vacuum che stanno lavorando in questo momento. Possiamo monitorare i vacuum e vedere che se superiamo il limite, è un segnale per controllare le impostazioni di PostgreSQL e ottimizzare in qualche modo il funzionamento del vacuum.
Un'altra caratteristica di PostgreSQL è che PostgreSQL soffre molto di transazioni lunghe. In particolare, di transazioni che rimangono in sospeso senza fare nulla. Queste sono le cosiddette stat idle-in-transaction. Una transazione di questo tipo mantiene i blocchi, ostacola il funzionamento del vacuum. Di conseguenza, le tabelle si gonfiano e aumentano di dimensioni. E le query che lavorano con queste tabelle iniziano a funzionare più lentamente, perché devono scavare tutte le vecchie versioni delle righe dalla memoria al disco e viceversa. Pertanto, è necessario monitorare anche il tempo e la durata delle transazioni più lunghe, delle query di vacuum più lunghe. E se vediamo dei processi che funzionano già da molto tempo, più di 10-20-30 minuti per un carico OLTP, su di essi dobbiamo prestare attenzione e terminare forzatamente, oppure ottimizzare l'applicazione affinché non vengano chiamati e non rimangano in sospeso per così tanto tempo. Per un carico analitico, 10-20-30 minuti è normale, a volte anche di più.
Successivamente abbiamo l'opzione con i client connessi. Quando abbiamo già creato il dashboard e abbiamo visualizzato le metriche chiave di disponibilità, possiamo anche aggiungere ulteriori informazioni sui client connessi.
Le informazioni sui client connessi sono importanti, perché, dal punto di vista di PostgreSQL, i client possono essere diversi. Ci sono buoni client e ci sono cattivi client.
Un esempio semplice. Per client intendo l'applicazione. L'applicazione si è connessa al database e inizia immediatamente a inviare lì le sue richieste, il database le elabora ed esegue, restituendo i risultati al client. Questi sono client buoni e corretti.
Ci sono situazioni in cui un client si è connesso, mantiene la connessione, ma nel frattempo non fa nulla. Si trova in stato di inattività.
Ma ci sono clienti problematici. Ad esempio, lo stesso cliente si è collegato, ha aperto una transazione, ha fatto qualcosa nel database e poi è passato al codice, per esempio, per fare riferimento a una fonte esterna o per elaborare i dati acquisiti. Ma non ha chiuso la transazione. E la transazione rimane aperta nel database e blocca una riga. Questa è una situazione critica. E se l'applicazione dovesse improvvisamente bloccarsi con un'eccezione (Exception), la transazione potrebbe rimanere aperta per molto tempo. E questo influisce direttamente sulle prestazioni di PostgreSQL. PostgreSQL funzionerà più lentamente. Pertanto, è importante monitorare tempestivamente questi clienti e terminare forzatamente il loro lavoro. È necessario ottimizzare la propria applicazione per evitare tali situazioni.
Altri clienti problematici sono i clienti in attesa. Ma diventano problematici a causa delle circostanze. Ad esempio, una semplice transazione in attesa: può aprire una transazione, acquisire bloccaggi su alcune righe, poi da qualche parte nel codice potrebbe bloccarsi, lasciando una transazione sospesa. Arriva un altro cliente, richiede gli stessi dati, ma si imbatte in un blocco, perché quella transazione in attesa ha già bloccato alcune righe necessarie. E la seconda transazione rimarrà in attesa che la prima transazione venga completata o chiusa forzatamente dall'amministratore. In tal modo, le transazioni in attesa possono accumularsi e superare il limite di connessioni al database. E quando il limite è superato, l'applicazione non può più lavorare con il database. Questa è una situazione di emergenza per il progetto. Pertanto, è necessario monitorare i clienti problematici e reagire tempestivamente.
Un altro esempio di monitoraggio. E qui già abbiamo un dashboard decente. Ci sono informazioni sui collegamenti in alto. Connessione al DB – 8 unità. E questo è tutto. Non abbiamo informazioni su quali clienti siano attivi, quali clienti siano semplicemente inattivi, senza fare nulla. Non ci sono informazioni sulle transazioni in sospeso e sui collegamenti in attesa, ossia si tratta di un numero che mostra solo la quantità di collegamenti e null'altro. E da lì vedete voi stessi.
Pertanto, per aggiungere queste informazioni al monitoraggio, è necessario fare riferimento alla vista di sistema pg_stat_activity. Se trascorri molto tempo con PostgreSQL, questa vista è davvero utile e dovrebbe diventare un tuo alleato, poiché mostra l'attività attuale in PostgreSQL, ovvero cosa sta accadendo. Per ogni processo c'è una riga separata che mostra informazioni relative a quel processo: da quale host è stata stabilita la connessione, sotto quale utente, con quale nome, quando è stata avviata la transazione, quale query è attualmente in esecuzione e quale query è stata eseguita per ultima. E, di conseguenza, possiamo valutare lo stato del client attraverso il campo stat. Possiamo, in questo modo, raggruppare in base a questo campo e ottenere le statistiche che attualmente esistono nel database e il numero di connessioni associate a quella statistica nel database. E i numeri ottenuti possiamo inviarli al nostro monitoraggio e tracciare grafici su di essi.
È anche fondamentale valutare la durata delle transazioni. Ho già accennato all'importanza di monitorare la durata dei vacuum, ma le transazioni vengono valutate allo stesso modo. Ci sono i campi xact_start e query_start. Questi mostrano, in modo semplificato, il tempo di inizio della transazione e il tempo di inizio della query. Utilizziamo la funzione now(), che mostra il timestamp corrente, e sottraiamo il timestamp della transazione e della query. Così otteniamo la durata della transazione e la durata della query.
Se vediamo transazioni lunghe, dobbiamo già terminarle. Per i carichi OLTP, le transazioni lunghe sono già superiori a 1-2-3 minuti.. Per i carichi OLAP, le transazioni lunghe sono normali, ma se durano più di due ore, è anche un segnale che c'è qualche squilibrio.
Quando i clienti si connettono al database, iniziano a lavorare con i nostri dati. Accedono alle tabelle, si rivolgono agli indici per estrarre i dati dalla tabella. È importante valutare come i clienti interagiscono con questi dati.
Questo è necessario per valutare il nostro carico di lavoro e avere un'idea di quali tabelle siano le più "calde". Ad esempio, è utile in situazioni in cui vogliamo posizionare le tabelle "calde" su un'unità SSD veloce. Ad esempio, alcune tabelle di archivio che non utilizziamo più da tempo possono essere spostate in un "freddo" archivio, su dischi SATA, e possano rimanere lì; l'accesso a esse avverrà solo se necessario.
Questo è anche utile per rilevare anomalie dopo vari rilasci e deployment. Supponiamo che un progetto abbia lanciato una nuova funzionalità. Ad esempio, è stata aggiunta una nuova funzionalità per lavorare con il database. Se costruiamo dei grafici sull'uso delle tabelle, in questi grafici potremo facilmente identificare queste anomalie. Ad esempio, picchi di update o picchi di delete. Questo sarà molto evidente.
Inoltre, è possibile rilevare anomalie nella statistica "distorta". Cosa significa? In PostgreSQL esiste un pianificatore di query molto potente e molto buono. Gli sviluppatori dedicano molto tempo al suo sviluppo. Come funziona? Per costruire buoni piani, PostgreSQL raccoglie statistiche sulla distribuzione dei dati nelle tabelle a intervalli regolari. Queste statistiche includono i valori più frequenti: il numero di valori unici, informazioni sui NULL nelle tabelle e molte altre informazioni.
Sulla base di queste statistiche, il pianificatore costruisce diverse query, sceglie la più ottimale e utilizza questo piano di query per eseguire la query stessa e restituire i dati.
Può capitare che le statistiche "si disperdano". La qualità e la quantità dei dati siano cambiate in qualche modo nella tabella, ma le statistiche non sono state aggiornate. I piani formati potrebbero risultare non ottimali. Se i nostri piani non risultano ottimali in base al monitoraggio raccolto, possiamo vedere queste anomalie. Ad esempio, in alcuni casi i dati sono cambiati qualitativamente e insieme all'indice è stato utilizzato un accesso sequenziale alla tabella, cioè se la query deve restituire solo 100 righe (c'è una limitazione di limit 100), per questa query verrà eseguita una scansione completa. E questo influisce sempre molto negativamente sulle prestazioni.
E potremo vedere questo nel monitoraggio. E già guardare a questa richiesta, eseguire un explain per essa, raccogliere statistiche, costruire un nuovo indice aggiuntivo. E già reagire a questo problema. Perciò è importante.
Un altro esempio di monitoraggio. Penso che molti lo riconoscano, perché è molto popolare. Chi lo utilizza nei propri progetti ? А кто использует этот продукт совместно с Prometheus? Дело в том, что в стандартном репозитории этого мониторинга есть дашборд для работы с PostgreSQL – Prometheus. Ma qui c'è un piccolo inconveniente.
Ci sono diversi grafici. E come unità sono indicati i byte, cioè ci sono 5 grafici. Questo è Insert data, Update data, Delete data, Fetch data e Return data. Come unità di misura sono indicati i byte. Ma il fatto è che le statistiche in PostgreSQL restituiscono dati in tuple (righe). E, di conseguenza, questi grafici sono un ottimo modo per sottovalutare il vostro carico di lavoro di diversi ordini di grandezza, perché una tupla non è un byte, una tupla è una riga, è molti byte e ha sempre una lunghezza variabile. Cioè, calcolare il carico di lavoro in byte usando le tuple è un compito irrealizzabile o molto complesso. Pertanto, quando si utilizza un dashboard o un monitoraggio integrato, è sempre importante comprendere che funziona correttamente e restituisce dati valutati in modo corretto.
Come ottenere statistiche su queste tabelle? Per questo in PostgreSQL c'è una certa famiglia di viste. E la vista principale è . User_tables significa che le tabelle create a nome dell'utente. Al contrario, ci sono viste di sistema, utilizzate da PostgreSQL stesso. E c'è una tabella riepilogativa Alltables, che include sia quelle di sistema che quelle utente. È possibile partire da qualsiasi di esse, quella che preferite di più.
Sui campi sopra indicati è possibile valutare il numero di insert, update e delete. L'esempio di dashboard che ho utilizzato, infatti, utilizza questi campi per valutare le caratteristiche del carico di lavoro. Perciò possiamo anche fare riferimento a loro. Ma vale la pena ricordare che si tratta di tuple, non di byte, quindi non possiamo semplicemente convertirli in byte.
Sulla base di questi dati possiamo costruire, così detto, TopN-tabelle. Ad esempio, Top-5, Top-10. E possiamo monitorare quelle tabelle 'calde' che vengono utilizzate di più rispetto alle altre. Ad esempio, le 5 tabelle 'calde' per l'inserimento. E attraverso queste TopN-tabelle valutiamo il nostro carico di lavoro e possiamo misurare i picchi di carico di lavoro dopo vari rilasci, aggiornamenti e deploy.
È anche importante valutare le dimensioni della tabella, perché a volte gli sviluppatori rilasciano una nuova funzionalità, e le nostre tabelle iniziano ad espandersi nelle loro grandi dimensioni, poiché hanno deciso di aggiungere un volume extra di dati senza prevedere come questo impatterà sulle dimensioni del database. Anche questi casi possono sorprenderci.
E ora una piccola domanda per voi. Quale domanda sorge quando notate un carico sul server con il database? Qual è la prossima domanda che vi viene in mente?
Ma in realtà, la domanda successiva è: quali query stanno causando il carico? Cioè, non è interessante osservare i processi che causano il carico. È chiaro che se l'host è con il database, lì è in esecuzione il database e è evidente che solo i database utilizzeranno le risorse. Se apriamo Top, vedremo un elenco di processi in PostgreSQL che stanno facendo qualcosa. Da Top non si capisce cosa stanno facendo.
Pertanto, è necessario individuare quelle query che causano il maggiore carico, poiché il tuning delle query di solito offre più vantaggi rispetto al tuning della configurazione di PostgreSQL, del sistema operativo o persino dell'hardware. A mio avviso, si tratta di circa l'80-85-90%. Inoltre, questo processo è molto più veloce. È più semplice modificare una query che sistemare la configurazione, pianificare un riavvio, specialmente se il database non può essere riavviato, o aggiungere hardware. È più facile riscrivere una query o aggiungere un indice per ottenere un risultato migliore da essa.
Pertanto, è necessario monitorare le query e la loro adeguatezza. Consideriamo un altro esempio di monitoraggio. Anche qui sembra esserci un ottimo monitoraggio. Ci sono informazioni sulla replica, sulla larghezza di banda, sui blocchi e sullo sfruttamento delle risorse. Tutto bene, ma mancano informazioni sulle query. Non è chiaro quali query vengano eseguite nel nostro database, quanto tempo impiegano e quante di queste query ci siano. È essenziale avere sempre queste informazioni nel monitoraggio.
E per ottenere queste informazioni possiamo utilizzare il modulo pg_stat_statements. Su questa base è possibile costruire i grafici più diversi. Ad esempio, è possibile ottenere informazioni sulle query più frequenti, cioè quelle che vengono eseguite più spesso. Sì, dopo i deployment è molto utile guardare a questo e capire se c'è stato un picco nelle query.
È possibile monitorare le query più lunghe, cioè quelle che impiegano più tempo a essere eseguite. Queste utilizzano la CPU e consumano input/output. Possiamo anche valutare questi dati tramite i campi total_time, mean_time, blk_write_time e blk_read_time.
Possiamo valutare e monitorare le query più pesanti in termini di utilizzo delle risorse, quelle che leggono dal disco, quelle che lavorano con la memoria o, al contrario, quelle che generano un carico in scrittura.
Possiamo valutare le query più generose. Queste sono le query che restituiscono un gran numero di righe. Ad esempio, potrebbero essere delle query in cui si è dimenticato di impostare un limite, e quindi restituiscono semplicemente tutto il contenuto della tabella o delle tabelle richieste.
E possiamo anche monitorare le query che utilizzano file temporanei o tabelle temporanee.
E abbiamo i processi in background. I processi in background sono prima di tutto i checkpoint, o come vengono chiamati, i punti di controllo, l'autovacuum e la replica.
Un altro esempio di monitoraggio. C'è la scheda Manutenzione a sinistra, ci spostiamo su di essa e speriamo di vedere qualcosa di utile. Ma qui ci sono solo i tempi di funzionamento dell'autovacuum e della raccolta della statistica, nient'altro. Queste sono informazioni molto povere, quindi è sempre necessario avere informazioni su come funzionano i processi in background nel nostro database e se ci sono problemi derivanti dal loro funzionamento.
Quando consideriamo i punti di controllo, dobbiamo ricordare che i punti di controllo trasferiscono le pagine "sporche" dalla memoria volatile al disco, quindi creano un punto di controllo. E questo punto di controllo può quindi essere utilizzato come un certo punto di riferimento durante il ripristino, se per caso PostgreSQL si arresta in modo anomalo.
Pertanto, per scrivere tutte le pagine "sporchie" su disco, è necessario eseguire un certo volume di scritture. E, di norma, su sistemi con una grande quantità di memoria - questo è davvero molto. E se i nostri checkpoint vengono effettuati molto spesso in un breve intervallo, le prestazioni del disco ne risentiranno notevolmente. Le richieste dei clienti soffriranno per la scarsità di risorse. Combatteranno per le risorse e non avranno abbastanza prestazioni.
Di conseguenza, attraverso pg_stat_bgwriter, possiamo monitorare il numero di checkpoint che si verificano in base ai campi specificati. E se in un certo intervallo di tempo (dai 10 ai 15-20 minuti, mezz'ora) ci sono molti checkpoint, ad esempio 3-4-5, questo potrebbe già essere un problema. E già dovremmo esaminare il database, controllare la configurazione, per capire cosa causa tale abbondanza di checkpoint. Potrebbe esserci una grande scrittura in corso. Possiamo già valutare il carico di lavoro, poiché abbiamo grafici del carico di lavoro già aggiunti. Possiamo già ottimizzare i parametri dei checkpoint e fare in modo che non influenzino troppo le prestazioni delle richieste.
Torno a parlare di autovacuum, perché è qualcosa che, come ho già detto, può facilmente compromettere le prestazioni sia dei dischi che delle richieste, quindi è sempre importante valutare il numero di autovacuum.
Il numero di worker autovacuum nel database è limitato. Di default ce ne sono tre, quindi se abbiamo sempre tre worker che operano nel database, significa che il nostro autovacuum è sottoconfigurato, e dobbiamo aumentare i limiti, rivedere le impostazioni di autovacuum e andare a modificare la configurazione.
È importante valutare quali worker di vacuum stanno operando. O è un'operazione avviata dall'utente, un DBA che è venuto e ha avviato manualmente un vacuum, il che ha creato un carico. Abbiamo avuto qualche problema. Oppure è il numero di vacuum che stanno contando le transazioni. Per alcune versioni di PostgreSQL, si tratta di vacuum molto pesanti. E possono facilmente compromettere le prestazioni, perché leggono l'intera tabella e scansionano tutti i blocchi di quella tabella.
E, naturalmente, la durata dei vacuum. Se abbiamo vacuum lunghi che funzionano per molto tempo, significa che dobbiamo nuovamente prestare attenzione alla configurazione del vacuum e, forse, rivedere le sue impostazioni. Perché può sorgere una situazione in cui il vacuum lavora su una tabella per un lungo periodo (3-4 ore), ma durante il funzionamento del vacuum nella tabella si accumula nuovamente un grande volume di righe morte. E non appena il vacuum termina, deve nuovamente effettuare il vacuum su quella tabella. Così arriviamo a una situazione di vacuum infinito. In questo caso, il vacuum non riesce a fare il proprio lavoro, e le tabelle iniziano a gonfiarsi gradualmente, anche se il volume dei dati utili in esse rimane invariato. Pertanto, durante i vacuum prolungati, controlliamo sempre la configurazione e cerchiamo di ottimizzarla, senza compromettere però le prestazioni delle query dei clienti.
Attualmente non esistono quasi installazioni di PostgreSQL senza replica streaming. La replica è il processo di trasferimento dei dati dal master alla replica.
La replica in PostgreSQL è organizzata tramite il log delle transazioni. Il master genera il log delle transazioni. Il log delle transazioni viene inviato attraverso la connessione di rete alla replica, dove viene riprodotto. Tutto molto semplice.
Di conseguenza, per monitorare il lag della replica si utilizza la vista pg_stat_replication. Ma non è tutto così semplice. Nella versione 10, la vista ha subito alcune modifiche. Innanzitutto, alcuni campi sono stati rinominati e sono stati aggiunti nuovi campi. Nella versione 10 sono stati introdotti campi che permettono di valutare il lag della replica in secondi. Questo è molto utile. Fino alla versione 10 era possibile valutare il lag della replica in byte. Questa possibilità è rimasta anche nella versione 10, ovvero puoi scegliere ciò che ti è più comodo: valutare il lag in byte o in secondi. Molti fanno entrambe le cose.
Tuttavia, per valutare il lag della replica, è necessario conoscere la posizione del log nelle transazioni. E queste posizioni del log delle transazioni sono proprio nella vista pg_stat_replication. In un certo senso, utilizzando la funzione pg_xlog_location_diff() possiamo prendere due punti nel log delle transazioni. Calcolare la delta tra di essi e ottenere il lag della replica in byte. Questo è molto utile e semplice.
Nella decima versione, questa funzione è stata rinominata in pg_wal_lsn_diff(). In generale, in tutte le funzioni, viste e utility in cui era presente la parola «xlog», è stata sostituita con il valore «wal». Questo vale sia per le viste che per le funzioni. È una novità interessante.
Inoltre, nella decima versione sono state aggiunte righe che mostrano specificamente il lag. Questi sono write lag, flush lag e replay lag. Vale a dire, è importante monitorare queste cose. Se notiamo un lag nella replica, dobbiamo indagare sul perché si sia verificato, da dove proviene e risolvere il problema.
Per quanto riguarda le metriche di sistema, praticamente tutto è a posto. Quando si avvia un qualsiasi monitoraggio, si inizia dalle metriche di sistema. Queste riguardano l'utilizzo di CPU, memoria, swap, rete e disco. Tuttavia, molti parametri di default non sono inclusi.
Se l'utilizzo della CPU è in ordine, ci sono problemi con l'utilizzo del disco. Di solito, i progettisti delle soluzioni di monitoraggio includono informazioni sulla larghezza di banda. Questa può essere espressa in iops o byte. Ma dimenticano la latenza e l'utilizzo dei dispositivi di archiviazione. Questi sono parametri più importanti che permettono di valutare quanto siano caricati i dischi e quanto rallentino. Se abbiamo alta latenza, significa che ci sono problemi con i dischi. Se abbiamo un alto utilizzo, significa che i dischi stanno cedendo. Queste sono caratteristiche di qualità superiori rispetto alla larghezza di banda.
Anche se questa statistica può essere ottenuta dal file di sistema /proc, come avviene per l'utilizzo della CPU. Non so perché queste informazioni non vengano aggiunte nei monitoraggi. Tuttavia, è importante includerle nel proprio monitoraggio.
Lo stesso vale per le interfacce di rete. Ci sono informazioni sulla larghezza di banda della rete in pacchetti e in byte, ma non ci sono informazioni sulla latenza né sull'utilizzo, sebbene siano entrambe informazioni utili.
Qualsiasi monitoraggio ha delle carenze. E qualunque monitoraggio si prenda, non soddisferà sempre alcuni criteri. Tuttavia, si evolvono, vengono aggiunte nuove funzionalità, quindi scegliete qualcosa e migliorate.
E per migliorare, è sempre necessario avere chiaro cosa significhi la statistica fornita e come può essere utilizzata per risolvere i problemi.
Ecco alcuni punti chiave:
- È sempre necessario monitorare la disponibilità, avere dashboard per poter valutare rapidamente se tutto va bene con il database.
- È fondamentale avere un'idea di quali clienti interagiscono con il vostro database in modo da poter escludere quelli problematici.
- È importante valutare come questi clienti utilizzano i dati. Dovete avere un'idea del vostro carico di lavoro.
- È cruciale esaminare come si forma questo carico di lavoro e quali query viene utilizzata. Potete analizzare le query, ottimizzarle, rifattorizzarle e costruire indici per esse. Questo è molto importante.
- I processi in background possono influenzare negativamente le richieste dei clienti, quindi è importante monitorare per assicurarsi che non consumino troppe risorse.
- Le metriche di sistema vi permettono di pianificare l'espansione e l'aumento della capacità dei vostri server; quindi, è fondamentale anche tracciarle e valutarle.
Se siete interessati a questo argomento, potete visitare questi link.
— è la documentazione ufficiale del collector di statistiche. Ci sono descrizioni di tutte le viste statistiche e di tutti i campi. Potete leggerle, comprenderle e analizzarle. E sulla base di esse potete creare i vostri grafici e aggiungerli alle vostre monitoraggi.
Esempi di query:
Questo è il nostro repository aziendale e personale. Contiene esempi di query. Non ci sono query del tipo select * from qualcosa. Ci sono già query pronte con join, utilizzando funzioni interessanti che trasformano i numeri grezzi in valori leggibili e utili, cioè byte, tempo. Potete esplorarle, esaminarle, analizzarle, aggiungerle ai vostri monitoraggi e costruire le vostre intuizioni basate su di esse.
Domande
Domanda: Hai detto che non pubblicizzerai marchi, ma sono comunque curioso: quali dashboard usi nei tuoi progetti?
Risposta: Dipende. A volte arriviamo dal cliente e lui ha già il proprio monitoraggio. E noi lo consigliamo su cosa aggiungere al suo monitoraggio. La situazione è peggiore con Zabbiх. Perché non ha la possibilità di creare grafici TopN. Noi usiamo , perché abbiamo consulato quei ragazzi per il monitoraggio. Hanno realizzato monitoraggio per PostgreSQL sulla base delle nostre specifiche. Sto scrivendo il mio pet-project che raccoglie dati attraverso Prometheus e li visualizza in . Ho il compito di creare il mio esportatore in Prometheus e poi visualizzare tutto in Grafana.
Domanda: Esistono analoghi dei report AWR o … aggregazioni? Siete a conoscenza di qualcosa del genere?
Risposta: Sì, so cosa sia AWR, è una funzione interessante. Attualmente ci sono diversi strumenti che implementano più o meno il seguente modello. A intervalli di tempo regolari, vengono scritti alcuni baselines nello stesso PostgreSQL o in un archivio separato. Potete trovarli su Internet, esistono. Uno degli sviluppatori di uno di questi strumenti si trova sul forum sql.ru nella sezione PostgreSQL. Potete trovarlo lì. Sì, ci sono strumenti di questo tipo che possono essere utilizzati. Inoltre, sto scrivendo anch'io uno strumento che permette di fare la stessa cosa.
P.S.1 Se stai utilizzando postgres_exporter, quale dashboard utilizzi? Ce ne sono alcune, ma sono già obsolete. Magari la comunità potrebbe creare un template aggiornato?
P.S.2 Ho rimosso pganalyze, poiché è un'offerta SaaS proprietaria che si concentra sul monitoraggio delle prestazioni e sui suggerimenti automatizzati.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Quale monitoraggio self-hosted di postgresql (con dashboard) consideri il migliore?
30,0%Zabbix + integrazioni da Alexey Lesovsky oppure zabbix 4.4 oppure libzbxpgsql + zabbix libzbxpgsql + zabbix3
0,0%https://github.com/lesovsky/pgcenter0
0,0%https://github.com/pg-monz/pg_monz0
20,0%https://github.com/cybertec-postgresql/pgwatch22
20,0%https://github.com/postgrespro/mamonsu2
0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0
10,0%pganalyze è un SaaS proprietario — non posso rimuoverlo1
10,0%https://github.com/powa-team/powa1
0,0%https://github.com/darold/pgbadger0
0,0%https://github.com/darold/pgcluu0
0,0%https://github.com/zalando/PGObserver0
10,0%https://github.com/spotify/postgresql-metrics1
10 utenti hanno votato. 26 utenti si sono astenuti.
Fonte: habr.com
