Consentitemi di discutere un argomento che non è intrinsecamente specifico di PostgreSQL, ma che mi imbatto regolarmente durante l'analisi dei problemi sui sistemi dei clienti, la valutazione della "supportabilità" di tali sistemi, ecc. È l'importanza di disporre di una soluzione di monitoraggio per le metriche di sistema, configurandola in modo ragionevole e perché sar è ancora di gran lunga il mio strumento preferito (almeno su Linux).
Sull'importanza del monitoraggio
In primo luogo, il monitoraggio delle metriche di base del sistema (CPU, I/O, memoria) è estremamente importante. È un po' strano doverlo sottolineare nelle discussioni con altri ingegneri, ma direi che 1 ingegnere su 10 pensa di non aver davvero bisogno di monitoraggio. Il ragionamento di solito segue queste linee:
È vero che il monitoraggio aggiunge sovraccarico, non c'è dubbio. Ma è probabilmente trascurabile rispetto a ciò che sta facendo l'applicazione. In realtà, sar in realtà non sta aggiungendo alcuna strumentazione aggiuntiva, sta semplicemente leggendo i contatori dal nernel, calcolando i delta e scrivendoli su disco. Potrebbe essere necessario spazio su disco e I/O (a seconda del numero di CPU e dischi), ma questo è tutto.
Ad esempio, la raccolta di statistiche al secondo su una macchina con 32 core e più dischi produrrà circa 5 GB di dati grezzi al giorno, ma si comprime molto bene, spesso fino al 5-10% circa. Ed è appena visibile in top . La risoluzione al secondo è un po' estrema e l'utilizzo di 5 o 10 secondi ridurrà ulteriormente il sovraccarico.
Quindi no, risulta che l'overhead in realtà non è un motivo valido per non abilitare il monitoraggio.
Costi vs. vantaggi
Ancora più importante, però, "Quanto sovraccarico elimino non abilitando il monitoraggio?" è la domanda sbagliata da fare. Invece dovresti chiederti "Quali vantaggi ottengo dal monitoraggio? I vantaggi superano i costi?"
Sappiamo già che i costi (overhead) sono abbastanza piccoli o del tutto trascurabili. Quali sono i vantaggi? Nella mia esperienza, avere i dati di monitoraggio è effettivamente prezioso.
In primo luogo, ti consente di indagare sui problemi:guardare una serie di grafici e cercare cambiamenti improvvisi è sorprendentemente efficace e spesso ti porta direttamente al problema giusto. Allo stesso modo, confrontare i dati attuali (raccolti durante il numero) con una linea di base (raccolti quando tutto è a posto) è molto utile e impossibile se abiliti il monitoraggio solo quando le cose si rompono.
In secondo luogo, ti consente di valutare le tendenze e identificare potenziali problemi prima che ti colpiscano effettivamente. Quanta CPU stai usando? L'utilizzo della CPU cresce nel tempo? Ci sono alcuni modelli sospetti nell'utilizzo della memoria? Puoi rispondere a queste domande solo se hai il monitoraggio in atto.
Perché sar è il mio strumento preferito
Supponiamo che io abbia convinto che il tuo monitoraggio sia importante e che dovresti assolutamente farlo. Ma perché è sar il nostro strumento preferito, quando ci sono varie alternative fantasiose, sia on-premise che basate su cloud?
- È incluso in tutte le distribuzioni, ed è banale da installare/configurare. Questo rende abbastanza semplice convincere le persone ad abilitarlo.
- È proprio sulla macchina. Quindi, se esegui un SSH sulla macchina, puoi anche ottenere i dati di monitoraggio.
- Sta usando un semplice output di testo. Elaborazione banale dei dati:importarli in un database, analizzarli, allegarli a un ticket di supporto. È piuttosto difficile con altri strumenti che generalmente non ti consentono di esportare facilmente i dati, mostrano solo grafici e/o limitano in modo significativo l'analisi che puoi eseguire, ecc.
Ammetto che parte di ciò deriva dal fatto che lavoro per un'azienda che fornisce servizi PostgreSQL ad altre società (che si tratti di supporto 24×7 o DBA remoto. Quindi di solito otteniamo solo un accesso molto limitato ai sistemi dei clienti (per lo più solo server di database e nient'altro). Ciò significa che avere tutti i dati importanti sul server del database stesso, accessibili tramite SSH semplice, è estremamente conveniente ed elimina i viaggi di andata e ritorno non necessari solo per richiedere un altro pezzo di dati da qualche altro sistema. Il che fa risparmiare tempo e sanità mentale su entrambi i lati.
Se hai molti sistemi da gestire, probabilmente preferirai una soluzione di monitoraggio che raccoglie i dati da molte macchine in un unico luogo. Ma per me, sar vince ancora.
Allora, come configurarlo?
Ho menzionato l'installazione e l'abilitazione di sar (o meglio sysstat , che è il pacchetto che include sar ) è molto semplice. Sfortunatamente, la configurazione predefinita è piuttosto scadente. Dopo aver installato sysstat , troverai qualcosa di simile in /etc/cron.d/sysstat (o ovunque la tua distribuzione memorizzi cron configurazione):
*/10 * * * * root /usr/lib64/sa/sa1 1 1
Questo dice effettivamente il sa1 il comando verrà eseguito ogni 10 minuti e raccoglierà un singolo campione in 1 secondo. Ci sono due problemi qui. In primo luogo, 10 minuti sono una risoluzione abbastanza bassa. In secondo luogo, il campione copre solo 1 secondo su 600, quindi i restanti 9:59 non sono realmente inclusi. Questo è in qualche modo OK per i trend a lungo termine, dove è sufficiente un campionamento casuale a bassa risoluzione. Per altri scopi probabilmente devi fare qualcosa del genere invece:
* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1
Che raccoglie un campione al minuto e ogni campione copre un minuto. Il -S XALL significa che tutte le statistiche dovrebbero essere raccolte, inclusi gli interrupt, i singoli dispositivi a blocchi e le partizioni, ecc. Vedi man sadc per maggiori dettagli.
Riepilogo
Quindi, per riassumere questo post in pochi semplici punti:
- Dovresti avere il monitoraggio, anche se pensi di non averne bisogno. Quando si verificano problemi, è troppo tardi.
- I costi del monitoraggio sono probabilmente trascurabili, ma sicuramente molto inferiori ai vantaggi di disporre dei dati di monitoraggio.
sarè comodo e molto efficiente. Forse utilizzerai qualcos'altro in futuro, ma è un buon primo passo.- La configurazione predefinita non è particolarmente eccezionale (bassa risoluzione, campioni da 1 secondo). Valuta la possibilità di aumentare la risoluzione.
Una cosa che non ho menzionato è che sar si occupa solo delle metriche di sistema:CPU, dischi, memoria, processi, non delle statistiche PostgreSQL. Dovresti assolutamente monitorare anche quella parte dello stack, ovviamente.
