{"id":56075,"date":"2020-02-04T00:00:00","date_gmt":"2020-02-03T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/osnovy-monitoringa-postgresql-aleksej-lesovskij"},"modified":"2020-02-18T14:04:16","modified_gmt":"2020-02-18T11:04:16","slug":"osnovy-monitoringa-postgresql-aleksej-lesovskij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/osnovy-monitoringa-postgresql-aleksej-lesovskij","title":{"rendered":"Fondamenti del monitoraggio di PostgreSQL. Alexey Lesovskiy","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vi invitiamo a consultare la trascrizione della presentazione di Alexey Lesovskiy di Data Egret \"Fondamenti del monitoraggio di PostgreSQL\"<\/strong><\/p>\n

<\/p>\n

In questa presentazione, Alexey Lesovskiy parler\u00e0 dei punti chiave delle statistiche di PostgreSQL, di cosa significano e del motivo per cui devono essere inclusi nel monitoraggio; discuter\u00e0 dei grafici da includere nel monitoraggio, di come aggiungerli e di come interpretarli. Questo intervento sar\u00e0 utile per gli amministratori di database, gli amministratori di sistema e gli sviluppatori interessati alla risoluzione dei problemi di PostgreSQL.<\/p>\n

\n

\r\n \"Guarda\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Mi chiamo Alexey Lesovsky e rappresento l'azienda Data Egret. <\/p>\n

<\/p>\n

Un po' di informazioni su di me. Ho iniziato tanto tempo fa come amministratore di sistema. <\/p>\n

<\/p>\n

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 \u00e8 piaciuto molto e cos\u00ec, nel tempo, sono diventato un DBA di PostgreSQL.<\/p>\n

<\/p>\n

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 zabbix-extensions<\/a><\/noindex>. Era piuttosto popolare ai tempi. L\u00ec si potevano monitorare diverse cose importanti, non solo Linux, ma anche vari componenti.<\/p>\n

<\/p>\n

Ora mi occupo di PostgreSQL. Sto scrivendo un'altra cosa che permette di lavorare con le statistiche di PostgreSQL. Si chiama pgCenter<\/a><\/noindex> (articolo su Habr \u2014 Statistiche di Postgres senza nervi e stress<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

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: \u00abRagazzi, dobbiamo monitorare il database, perch\u00e9 \u00e8 successo qualcosa di brutto e dobbiamo evitare che succeda di nuovo in futuro\u00bb. 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 \u2013 PostgreSQL, MySQL o altri. I colleghi iniziano a proporre: \u00abHo sentito dire che esiste tanto un quel tipo di database. Usiamo quello\u00bb. I colleghi iniziano a discutere tra di loro. E alla fine, scegliamo un certo database, ma il monitoraggio di PostgreSQL \u00e8 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. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Pertanto, in questa relazione cercher\u00f2 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. <\/p>\n

<\/p>\n

Le idee presenti in questo rapporto possono essere direttamente adattate a qualsiasi database, sia esso un DBMS o un noSQL. Quindi non si parler\u00e0 solo di PostgreSQL, ma ci saranno molte ricette su come implementare questo in PostgreSQL. Ci saranno esempi di query, esempi di entit\u00e0 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\u00e0 bene.<\/p>\n

<\/p>\n

\"FondamentiNella presentazione non parler\u00f2
\ndi come trasmettere e memorizzare le metriche. Non dir\u00f2 nulla sulla post-elaborazione dei dati e su come fornirli all'utente. E non parler\u00f2 affatto di avvisi.
\nMa nel corso della narrazione mostrer\u00f2 diversi screenshot di monitoraggi esistenti, criticandoli in qualche modo. Tuttavia cercher\u00f2 di non menzionare i marchi, per non fare pubblicit\u00e0 n\u00e9 antireclamo a questi prodotti. Pertanto, tutte le coincidenze sono casuali e rimangono nella vostra fantasia.
\n\"Fondamenti
\nIniziamo con il capire cosa sia il monitoraggio. Il monitoraggio \u00e8 una cosa molto importante di cui avere bisogno. Tutti lo capiscono. Ma allo stesso tempo, il monitoraggio non \u00e8 considerato un prodotto commerciale e non influisce direttamente sui profitti dell'azienda, quindi il tempo dedicato al monitoraggio \u00e8 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. <\/p>\n

<\/p>\n

Pertanto, dalla nostra esperienza, quando ci presentiamo dai clienti, il monitoraggio \u00e8 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. <\/p>\n

<\/p>\n

I database sono sistemi complessi che devono anch'essi essere monitorati, perch\u00e9 i database sono contenitori di informazioni. E l'informazione \u00e8 molto importante per l'azienda, non pu\u00f2 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. <\/p>\n

<\/p>\n

\"FondamentiSe 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\u00ec che possa visualizzare queste statistiche. <\/p>\n

<\/p>\n

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\u00e0 alcuni numeri concreti sul funzionamento dei sottosistemi di PostgreSQL. <\/p>\n

<\/p>\n

Puoi aggiungere questi numeri al tuo sistema di monitoraggio preferito, disegnare grafici, aggiungere funzioni e ottenere analisi a lungo termine. <\/p>\n

<\/p>\n

Ma in questo rapporto non prender\u00f2 in considerazione tutte queste funzionalit\u00e0, perch\u00e9 questo potrebbe richiedere un'intera giornata. Mi concentrer\u00f2 letteralmente su due, tre o quattro aspetti e parler\u00f2 di come aiutano a migliorare il monitoraggio.
\n\"Fondamenti
\nE se parliamo del monitoraggio del database, cosa bisogna monitorare? Prima di tutto \u00e8 necessario monitorare la disponibilit\u00e0, perch\u00e9 il database \u00e8 un servizio che fornisce accesso ai dati ai clienti, e dobbiamo monitorare la disponibilit\u00e0, che include anche alcune caratteristiche qualitative e quantitative. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

\u00c8 anche importante monitorare i clienti che si connettono al nostro database, poich\u00e9 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\u00e0.<\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Quando i clienti si collegano al database, \u00e8 ovvio che iniziano a lavorare con i nostri dati, perci\u00f2 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.<\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Ma il carico di lavoro consiste ovviamente in richieste. Le applicazioni si connettono al database, accedono ai dati tramite richieste, quindi \u00e8 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\u00f9 velocemente e con migliori prestazioni. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

E poich\u00e9 parliamo di database, dobbiamo ricordare che un database \u00e8 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\u00e0 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\u00f2 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. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

E tutto ci\u00f2 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 \u00e8 certamente necessario. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Con le metriche di sistema tutto sommato va bene, tutti i moderni sistemi di monitoraggio supportano gi\u00e0 queste metriche, ma in generale alcune componenti sono comunque insufficienti e alcune cose devono essere aggiunte. Di esse ne parler\u00f2, ci saranno alcune diapositive a riguardo. <\/p>\n

<\/p>\n

\"Fondamenti
\nIl primo punto del piano \u00e8 la disponibilit\u00e0. Cos'\u00e8 la disponibilit\u00e0? La disponibilit\u00e0, a mio avviso, \u00e8 la capacit\u00e0 del database di servire le connessioni, cio\u00e8 il database \u00e8 attivo e, come servizio, accetta le connessioni dai clienti. E questa disponibilit\u00e0 pu\u00f2 essere valutata tramite alcune caratteristiche. \u00c8 molto comodo portare queste caratteristiche sui dashboard. <\/p>\n

<\/p>\n

\"Fondamenti
\nTutti sanno cosa sono i dashboard. \u00c8 quando lanci uno sguardo allo schermo, dove \u00e8 raccolta l'informazione necessaria. E puoi gi\u00e0 determinare subito se ci sono problemi nel database o no.
\nDi conseguenza, la disponibilit\u00e0 del database e altre caratteristiche chiave devono sempre essere visualizzate sui dashboard affinch\u00e9 queste informazioni siano a portata di mano, sempre con te. Alcuni dettagli aggiuntivi, che aiutano gi\u00e0 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. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Un esempio di un noto sistema di monitoraggio. \u00c8 un sistema di monitoraggio davvero eccezionale. Raccoglie una grande quantit\u00e0 di dati, ma dal mio punto di vista ha una concezione strana di dashboard. C'\u00e8 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\u00e8 i dashboard, come tali, non esistono. Ci sono solo elenchi di grafici.<\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Cosa bisogna aggiungere a questi dashboard? Si pu\u00f2 iniziare da una caratteristica come il tempo di risposta. In PostgreSQL c'\u00e8 la vista pg_stat_statements. Di default \u00e8 disabilitata, ma \u00e8 una delle viste sistemiche pi\u00f9 importanti che bisogna sempre attivare e utilizzare. Contiene informazioni su tutte le query che sono state eseguite nel database. <\/p>\n

<\/p>\n

Pertanto, possiamo partire dal fatto che si pu\u00f2 prendere il tempo totale di esecuzione di tutte le query e dividerlo per il numero di query utilizzando i campi sopra citati. Ma questa \u00e8 una media generica. Possiamo anche considerarne altri \u2013 il tempo minimo di esecuzione delle query, quello massimo e quello mediano. Possiamo persino costruire percentili, in PostgreSQL ci sono funzioni corrispondenti per questo. E possiamo ottenere alcuni numeri che caratterizzano il tempo di risposta del nostro database in base alle query gi\u00e0 eseguite, cio\u00e8 non eseguiamo una query fittizia \u2018select 1\u2019 e osserviamo il tempo di risposta, ma analizziamo i tempi di risposta delle query gi\u00e0 eseguite e li riportiamo come un singolo valore o costruiamo un grafico su di essi. <\/p>\n

<\/p>\n

\u00c8 anche importante monitorare il numero di errori che il sistema sta generando in quel momento. E per questo si pu\u00f2 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, \u00e8 gi\u00e0 un buon motivo per controllare i log e vedere quali errori si stanno verificando e perch\u00e9, e successivamente investigare e risolverli.<\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Si pu\u00f2 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 \u00e8 sotto carico perch\u00e9 qualche backend \u00e8 andato in crash. \u00c8 fondamentale monitorare sempre questo numero e ricordare che per il nostro progetto una certa performance \u00e8 considerata normale, mentre valori pi\u00f9 elevati o inferiori sono anomali e richiedono attenzione per capire perch\u00e9 si registrano tali numeri.<\/p>\n

<\/p>\n

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\u00ec il numero di transazioni al secondo. <\/p>\n

<\/p>\n

Tutti comprendono che in una transazione possono rientrare pi\u00f9 richieste? Ecco perch\u00e9 TPS e QPS sono un po' diversi. <\/p>\n

<\/p>\n

Il numero di richieste al secondo pu\u00f2 essere ottenuto tramite pg_stat_statements e calcolando semplicemente la somma di tutte le richieste eseguite. \u00c8 chiaro che stiamo confrontando il valore attuale con quello precedente, sottraendo, ottenendo la delta e quindi il numero.<\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Si possono aggiungere metriche aggiuntive, se lo si desidera, che aiutano anche a valutare la disponibilit\u00e0 del nostro database e a monitorare eventuali downtime. <\/p>\n

<\/p>\n

Una di queste metriche \u00e8 l'uptime. Ma l'uptime in PostgreSQL \u00e8 una cosa un po' complicata. Spiegher\u00f2 perch\u00e9. 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\u00e8 questa situazione pu\u00f2 essere valutata come downtime. Tuttavia, il contatore dell'uptime non si resetta, poich\u00e9 considera il tempo di avvio del postmaster fin dal primo momento. Pertanto, si possono trascurare situazioni di questo tipo.<\/p>\n

<\/p>\n

\u00c8 inoltre importante monitorare il numero di worker di vacuum. Tutti sanno cos'\u00e8 l'autovacuum in PostgreSQL? \u00c8 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 \u00e8 cos\u00ec. \u00c8 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. <\/p>\n

<\/p>\n

Perch\u00e9 \u00e8 necessario monitorarlo? Perch\u00e9 il vacuum a volte fa molto male. Consuma molte risorse e le richieste dei clienti iniziano a soffrirne. <\/p>\n

<\/p>\n

E dovremmo monitorarlo attraverso la vista pg_stat_activity, di cui parler\u00f2 nel prossimo paragrafo. Questa vista mostra l'attivit\u00e0 corrente nel database. E attraverso questa attivit\u00e0 possiamo tracciare il numero di vacuum che stanno lavorando in questo momento. Possiamo monitorare i vacuum e vedere che se superiamo il limite, \u00e8 un segnale per controllare le impostazioni di PostgreSQL e ottimizzare in qualche modo il funzionamento del vacuum. <\/p>\n

<\/p>\n

Un'altra caratteristica di PostgreSQL \u00e8 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\u00f9 lentamente, perch\u00e9 devono scavare tutte le vecchie versioni delle righe dalla memoria al disco e viceversa.<\/strong> Pertanto, \u00e8 necessario monitorare anche il tempo e la durata delle transazioni pi\u00f9 lunghe, delle query di vacuum pi\u00f9 lunghe. E se vediamo dei processi che funzionano gi\u00e0 da molto tempo, pi\u00f9 di 10-20-30 minuti per un carico OLTP, su di essi dobbiamo prestare attenzione e terminare forzatamente, oppure ottimizzare l'applicazione affinch\u00e9 non vengano chiamati e non rimangano in sospeso per cos\u00ec tanto tempo.<\/strong> Per un carico analitico, 10-20-30 minuti \u00e8 normale, a volte anche di pi\u00f9. <\/p>\n

<\/p>\n

\"Fondamenti
\nSuccessivamente abbiamo l'opzione con i client connessi. Quando abbiamo gi\u00e0 creato il dashboard e abbiamo visualizzato le metriche chiave di disponibilit\u00e0, possiamo anche aggiungere ulteriori informazioni sui client connessi. <\/p>\n

<\/p>\n

Le informazioni sui client connessi sono importanti, perch\u00e9, dal punto di vista di PostgreSQL, i client possono essere diversi. Ci sono buoni client e ci sono cattivi client. <\/p>\n

<\/p>\n

Un esempio semplice. Per client intendo l'applicazione. L'applicazione si \u00e8 connessa al database e inizia immediatamente a inviare l\u00ec le sue richieste, il database le elabora ed esegue, restituendo i risultati al client. Questi sono client buoni e corretti. <\/p>\n

<\/p>\n

Ci sono situazioni in cui un client si \u00e8 connesso, mantiene la connessione, ma nel frattempo non fa nulla. Si trova in stato di inattivit\u00e0. <\/p>\n

<\/p>\n

Ma ci sono clienti problematici. Ad esempio, lo stesso cliente si \u00e8 collegato, ha aperto una transazione, ha fatto qualcosa nel database e poi \u00e8 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 \u00e8 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\u00e0 pi\u00f9 lentamente. Pertanto, \u00e8 importante monitorare tempestivamente questi clienti e terminare forzatamente il loro lavoro. \u00c8 necessario ottimizzare la propria applicazione per evitare tali situazioni. <\/p>\n

<\/p>\n

Altri clienti problematici sono i clienti in attesa. Ma diventano problematici a causa delle circostanze. Ad esempio, una semplice transazione in attesa: pu\u00f2 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\u00e9 quella transazione in attesa ha gi\u00e0 bloccato alcune righe necessarie. E la seconda transazione rimarr\u00e0 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 \u00e8 superato, l'applicazione non pu\u00f2 pi\u00f9 lavorare con il database. Questa \u00e8 una situazione di emergenza per il progetto. Pertanto, \u00e8 necessario monitorare i clienti problematici e reagire tempestivamente. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Un altro esempio di monitoraggio. E qui gi\u00e0 abbiamo un dashboard decente. Ci sono informazioni sui collegamenti in alto. Connessione al DB \u2013 8 unit\u00e0. E questo \u00e8 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\u00e0 di collegamenti e null'altro. E da l\u00ec vedete voi stessi.
\n\"Fondamenti
\nPertanto, per aggiungere queste informazioni al monitoraggio, \u00e8 necessario fare riferimento alla vista di sistema pg_stat_activity. Se trascorri molto tempo con PostgreSQL, questa vista \u00e8 davvero utile e dovrebbe diventare un tuo alleato, poich\u00e9 mostra l'attivit\u00e0 attuale in PostgreSQL, ovvero cosa sta accadendo. Per ogni processo c'\u00e8 una riga separata che mostra informazioni relative a quel processo: da quale host \u00e8 stata stabilita la connessione, sotto quale utente, con quale nome, quando \u00e8 stata avviata la transazione, quale query \u00e8 attualmente in esecuzione e quale query \u00e8 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.
\n\u00c8 anche fondamentale valutare la durata delle transazioni. Ho gi\u00e0 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\u00ec otteniamo la durata della transazione e la durata della query. <\/p>\n

<\/p>\n

Se vediamo transazioni lunghe, dobbiamo gi\u00e0 terminarle. Per i carichi OLTP, le transazioni lunghe sono gi\u00e0 superiori a 1-2-3 minuti.<\/strong>. Per i carichi OLAP, le transazioni lunghe sono normali, ma se durano pi\u00f9 di due ore, \u00e8 anche un segnale che c'\u00e8 qualche squilibrio.<\/strong> <\/p>\n

<\/p>\n

\"Fondamenti
\nQuando 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. \u00c8 importante valutare come i clienti interagiscono con questi dati.<\/p>\n

<\/p>\n

Questo \u00e8 necessario per valutare il nostro carico di lavoro e avere un'idea di quali tabelle siano le pi\u00f9 \"calde\". Ad esempio, \u00e8 utile in situazioni in cui vogliamo posizionare le tabelle \"calde\" su un'unit\u00e0 SSD veloce. Ad esempio, alcune tabelle di archivio che non utilizziamo pi\u00f9 da tempo possono essere spostate in un \"freddo\" archivio, su dischi SATA, e possano rimanere l\u00ec; l'accesso a esse avverr\u00e0 solo se necessario. <\/p>\n

<\/p>\n

Questo \u00e8 anche utile per rilevare anomalie dopo vari rilasci e deployment. Supponiamo che un progetto abbia lanciato una nuova funzionalit\u00e0. Ad esempio, \u00e8 stata aggiunta una nuova funzionalit\u00e0 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\u00e0 molto evidente.<\/p>\n

<\/p>\n

Inoltre, \u00e8 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\u00f9 frequenti: il numero di valori unici, informazioni sui NULL nelle tabelle e molte altre informazioni. <\/p>\n

<\/p>\n

Sulla base di queste statistiche, il pianificatore costruisce diverse query, sceglie la pi\u00f9 ottimale e utilizza questo piano di query per eseguire la query stessa e restituire i dati. <\/p>\n

<\/p>\n

Pu\u00f2 capitare che le statistiche \"si disperdano\". La qualit\u00e0 e la quantit\u00e0 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 \u00e8 stato utilizzato un accesso sequenziale alla tabella, cio\u00e8 se la query deve restituire solo 100 righe (c'\u00e8 una limitazione di limit 100), per questa query verr\u00e0 eseguita una scansione completa. E questo influisce sempre molto negativamente sulle prestazioni. <\/p>\n

<\/p>\n

E potremo vedere questo nel monitoraggio. E gi\u00e0 guardare a questa richiesta, eseguire un explain per essa, raccogliere statistiche, costruire un nuovo indice aggiuntivo. E gi\u00e0 reagire a questo problema. Perci\u00f2 \u00e8 importante. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Un altro esempio di monitoraggio. Penso che molti lo riconoscano, perch\u00e9 \u00e8 molto popolare. Chi lo utilizza nei propri progetti Prometheus<\/a><\/noindex>? \u0410 \u043a\u0442\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 \u044d\u0442\u043e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u043e \u0441 Prometheus? \u0414\u0435\u043b\u043e \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u0432 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u043e\u043c \u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438 \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0435\u0441\u0442\u044c \u0434\u0430\u0448\u0431\u043e\u0440\u0434 \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441 PostgreSQL \u2013 postgres_exporter<\/a><\/noindex> Prometheus. Ma qui c'\u00e8 un piccolo inconveniente. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Ci sono diversi grafici. E come unit\u00e0 sono indicati i byte, cio\u00e8 ci sono 5 grafici. Questo \u00e8 Insert data, Update data, Delete data, Fetch data e Return data. Come unit\u00e0 di misura sono indicati i byte. Ma il fatto \u00e8 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\u00e9 una tupla non \u00e8 un byte, una tupla \u00e8 una riga, \u00e8 molti byte e ha sempre una lunghezza variabile. Cio\u00e8, calcolare il carico di lavoro in byte usando le tuple \u00e8 un compito irrealizzabile o molto complesso. Pertanto, quando si utilizza un dashboard o un monitoraggio integrato, \u00e8 sempre importante comprendere che funziona correttamente e restituisce dati valutati in modo corretto. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Come ottenere statistiche su queste tabelle? Per questo in PostgreSQL c'\u00e8 una certa famiglia di viste. E la vista principale \u00e8 pg_stat_user_tables<\/a><\/noindex>. User_tables significa che le tabelle create a nome dell'utente. Al contrario, ci sono viste di sistema, utilizzate da PostgreSQL stesso. E c'\u00e8 una tabella riepilogativa Alltables, che include sia quelle di sistema che quelle utente. \u00c8 possibile partire da qualsiasi di esse, quella che preferite di pi\u00f9.<\/p>\n

<\/p>\n

Sui campi sopra indicati \u00e8 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\u00f2 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.<\/p>\n

<\/p>\n

Sulla base di questi dati possiamo costruire, cos\u00ec detto, TopN-tabelle. Ad esempio, Top-5, Top-10. E possiamo monitorare quelle tabelle 'calde' che vengono utilizzate di pi\u00f9 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. <\/p>\n

<\/p>\n

\u00c8 anche importante valutare le dimensioni della tabella, perch\u00e9 a volte gli sviluppatori rilasciano una nuova funzionalit\u00e0, e le nostre tabelle iniziano ad espandersi nelle loro grandi dimensioni, poich\u00e9 hanno deciso di aggiungere un volume extra di dati senza prevedere come questo impatter\u00e0 sulle dimensioni del database. Anche questi casi possono sorprenderci. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

E ora una piccola domanda per voi. Quale domanda sorge quando notate un carico sul server con il database? Qual \u00e8 la prossima domanda che vi viene in mente? <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Ma in realt\u00e0, la domanda successiva \u00e8: quali query stanno causando il carico? Cio\u00e8, non \u00e8 interessante osservare i processi che causano il carico. \u00c8 chiaro che se l'host \u00e8 con il database, l\u00ec \u00e8 in esecuzione il database e \u00e8 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. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Pertanto, \u00e8 necessario individuare quelle query che causano il maggiore carico, poich\u00e9 il tuning delle query di solito offre pi\u00f9 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 \u00e8 molto pi\u00f9 veloce. \u00c8 pi\u00f9 semplice modificare una query che sistemare la configurazione, pianificare un riavvio, specialmente se il database non pu\u00f2 essere riavviato, o aggiungere hardware. \u00c8 pi\u00f9 facile riscrivere una query o aggiungere un indice per ottenere un risultato migliore da essa. <\/p>\n

<\/p>\n

\"Fondamenti
\nPertanto, \u00e8 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 \u00e8 chiaro quali query vengano eseguite nel nostro database, quanto tempo impiegano e quante di queste query ci siano. \u00c8 essenziale avere sempre queste informazioni nel monitoraggio. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

E per ottenere queste informazioni possiamo utilizzare il modulo pg_stat_statements. Su questa base \u00e8 possibile costruire i grafici pi\u00f9 diversi. Ad esempio, \u00e8 possibile ottenere informazioni sulle query pi\u00f9 frequenti, cio\u00e8 quelle che vengono eseguite pi\u00f9 spesso. S\u00ec, dopo i deployment \u00e8 molto utile guardare a questo e capire se c'\u00e8 stato un picco nelle query. <\/p>\n

<\/p>\n

\u00c8 possibile monitorare le query pi\u00f9 lunghe, cio\u00e8 quelle che impiegano pi\u00f9 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. <\/p>\n

<\/p>\n

Possiamo valutare e monitorare le query pi\u00f9 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.<\/p>\n

<\/p>\n

Possiamo valutare le query pi\u00f9 generose. Queste sono le query che restituiscono un gran numero di righe. Ad esempio, potrebbero essere delle query in cui si \u00e8 dimenticato di impostare un limite, e quindi restituiscono semplicemente tutto il contenuto della tabella o delle tabelle richieste.<\/p>\n

<\/p>\n

E possiamo anche monitorare le query che utilizzano file temporanei o tabelle temporanee. <\/p>\n

<\/p>\n

\"Fondamenti
\nE 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. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Un altro esempio di monitoraggio. C'\u00e8 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 \u00e8 sempre necessario avere informazioni su come funzionano i processi in background nel nostro database e se ci sono problemi derivanti dal loro funzionamento. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

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\u00f2 quindi essere utilizzato come un certo punto di riferimento durante il ripristino, se per caso PostgreSQL si arresta in modo anomalo. <\/p>\n

<\/p>\n

Pertanto, per scrivere tutte le pagine \"sporchie\" su disco, \u00e8 necessario eseguire un certo volume di scritture. E, di norma, su sistemi con una grande quantit\u00e0 di memoria - questo \u00e8 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\u00e0 di risorse. Combatteranno per le risorse e non avranno abbastanza prestazioni. <\/p>\n

<\/p>\n

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\u00e0 essere un problema. E gi\u00e0 dovremmo esaminare il database, controllare la configurazione, per capire cosa causa tale abbondanza di checkpoint. Potrebbe esserci una grande scrittura in corso. Possiamo gi\u00e0 valutare il carico di lavoro, poich\u00e9 abbiamo grafici del carico di lavoro gi\u00e0 aggiunti. Possiamo gi\u00e0 ottimizzare i parametri dei checkpoint e fare in modo che non influenzino troppo le prestazioni delle richieste.<\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Torno a parlare di autovacuum, perch\u00e9 \u00e8 qualcosa che, come ho gi\u00e0 detto, pu\u00f2 facilmente compromettere le prestazioni sia dei dischi che delle richieste, quindi \u00e8 sempre importante valutare il numero di autovacuum. <\/p>\n

<\/p>\n

Il numero di worker autovacuum nel database \u00e8 limitato. Di default ce ne sono tre, quindi se abbiamo sempre tre worker che operano nel database, significa che il nostro autovacuum \u00e8 sottoconfigurato, e dobbiamo aumentare i limiti, rivedere le impostazioni di autovacuum e andare a modificare la configurazione.
\n\u00c8 importante valutare quali worker di vacuum stanno operando. O \u00e8 un'operazione avviata dall'utente, un DBA che \u00e8 venuto e ha avviato manualmente un vacuum, il che ha creato un carico. Abbiamo avuto qualche problema. Oppure \u00e8 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\u00e9 leggono l'intera tabella e scansionano tutti i blocchi di quella tabella. <\/p>\n

<\/p>\n

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\u00e9 pu\u00f2 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\u00ec 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\u00f2 le prestazioni delle query dei clienti. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Attualmente non esistono quasi installazioni di PostgreSQL senza replica streaming. La replica \u00e8 il processo di trasferimento dei dati dal master alla replica.<\/p>\n

<\/p>\n

La replica in PostgreSQL \u00e8 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. <\/p>\n

<\/p>\n

Di conseguenza, per monitorare il lag della replica si utilizza la vista pg_stat_replication. Ma non \u00e8 tutto cos\u00ec 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 \u00e8 molto utile. Fino alla versione 10 era possibile valutare il lag della replica in byte. Questa possibilit\u00e0 \u00e8 rimasta anche nella versione 10, ovvero puoi scegliere ci\u00f2 che ti \u00e8 pi\u00f9 comodo: valutare il lag in byte o in secondi. Molti fanno entrambe le cose.<\/p>\n

<\/p>\n

Tuttavia, per valutare il lag della replica, \u00e8 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 \u00e8 molto utile e semplice. <\/p>\n

<\/p>\n

Nella decima versione, questa funzione \u00e8 stata rinominata in pg_wal_lsn_diff(). In generale, in tutte le funzioni, viste e utility in cui era presente la parola \u00abxlog\u00bb, \u00e8 stata sostituita con il valore \u00abwal\u00bb. Questo vale sia per le viste che per le funzioni. \u00c8 una novit\u00e0 interessante. <\/p>\n

<\/p>\n

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, \u00e8 importante monitorare queste cose. Se notiamo un lag nella replica, dobbiamo indagare sul perch\u00e9 si sia verificato, da dove proviene e risolvere il problema. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Per quanto riguarda le metriche di sistema, praticamente tutto \u00e8 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. <\/p>\n

<\/p>\n

Se l'utilizzo della CPU \u00e8 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\u00f2 essere espressa in iops o byte. Ma dimenticano la latenza e l'utilizzo dei dispositivi di archiviazione. Questi sono parametri pi\u00f9 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.<\/strong> Queste sono caratteristiche di qualit\u00e0 superiori rispetto alla larghezza di banda.<\/p>\n

<\/p>\n

Anche se questa statistica pu\u00f2 essere ottenuta dal file di sistema \/proc, come avviene per l'utilizzo della CPU. Non so perch\u00e9 queste informazioni non vengano aggiunte nei monitoraggi. Tuttavia, \u00e8 importante includerle nel proprio monitoraggio.<\/strong> <\/p>\n

<\/p>\n

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\u00e9 sull'utilizzo, sebbene siano entrambe informazioni utili.<\/strong> <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Qualsiasi monitoraggio ha delle carenze. E qualunque monitoraggio si prenda, non soddisfer\u00e0 sempre alcuni criteri. Tuttavia, si evolvono, vengono aggiunte nuove funzionalit\u00e0, quindi scegliete qualcosa e migliorate. <\/p>\n

<\/p>\n

E per migliorare, \u00e8 sempre necessario avere chiaro cosa significhi la statistica fornita e come pu\u00f2 essere utilizzata per risolvere i problemi. <\/p>\n

<\/p>\n

Ecco alcuni punti chiave:<\/p>\n

<\/p>\n