Nei due post precedenti del blog abbiamo trattato sia la distribuzione dei quattro tipi di clustering/replica (MySQL/Galera, MySQL Replication, MongoDB e PostgreSQL) sia la gestione/monitoraggio dei database e dei cluster esistenti. Quindi, dopo aver letto questi due primi post del blog, sei stato in grado di aggiungere le tue 20 configurazioni di replica esistenti a ClusterControl, espanderle e inoltre hai distribuito due nuovi cluster Galera facendo un sacco di altre cose. O forse hai distribuito sistemi MongoDB e/o PostgreSQL. Quindi ora, come mantenerli sani?
Questo è esattamente l'argomento di questo post del blog:come sfruttare il monitoraggio delle prestazioni di ClusterControl e la funzionalità dei consulenti per mantenere sani i database e i cluster MySQL, MongoDB e/o PostgreSQL. Quindi, come si fa in ClusterControl?
Elenco dei cluster di database
Le informazioni più importanti si trovano già nell'elenco dei cluster:fintanto che non ci sono allarmi e non viene mostrato nessun host inattivo, tutto funziona correttamente. Viene generato un allarme se viene soddisfatta una determinata condizione, ad es. l'host si sta scambiando e porta alla tua attenzione il problema su cui dovresti indagare. Ciò significa che gli allarmi non solo vengono generati durante un'interruzione, ma anche per consentirti di gestire in modo proattivo i tuoi database.
Supponiamo che tu acceda a ClusterControl e vedi un elenco di cluster come questo, avrai sicuramente qualcosa su cui indagare:ad esempio un nodo è inattivo nel cluster Galera e ogni cluster ha vari allarmi:
Dopo aver cliccato su uno degli allarmi, si andrà a una pagina dettagliata su tutti gli allarmi del cluster. I dettagli dell'allarme spiegheranno il problema e nella maggior parte dei casi consiglieranno anche l'azione per risolverlo.
Puoi impostare i tuoi allarmi creando espressioni personalizzate, ma questo è stato deprecato a favore del nostro nuovo Developer Studio che ti consente di scrivere Javascript personalizzati ed eseguirli come Advisor. Torneremo su questo argomento più avanti in questo post.
Panoramica del cluster - Dashboard
Quando si apre la panoramica del cluster, è possibile visualizzare immediatamente le metriche delle prestazioni più importanti per il cluster nelle schede. Questa panoramica può variare in base al tipo di cluster poiché, ad esempio, Galera ha parametri di prestazione diversi da tenere d'occhio rispetto ai tradizionali MySQL, PostgreSQL o MongoDB.
Sia la panoramica predefinita che le schede preselezionate sono personalizzabili. Facendo clic su Panoramica -> Impostazioni Dash ti viene data una finestra di dialogo che ti permette di definire la dashboard:
Premendo il segno più puoi aggiungere e definire le tue metriche per rappresentare graficamente la dashboard. Nel nostro caso definiremo una nuova dashboard con la media delle code di invio e ricezione specifiche di Galera:
Questa nuova dashboard dovrebbe darci una buona visione della lunghezza media della coda del nostro cluster Galera.
Dopo aver premuto Salva, la nuova dashboard sarà disponibile per questo cluster:
Allo stesso modo puoi farlo anche per PostgreSQL, ad esempio possiamo monitorare i blocchi condivisi colpiti rispetto ai blocchi letti:
Quindi, come puoi vedere, è relativamente facile personalizzare la tua dashboard (predefinita).
Panoramica del cluster - Query Monitor
La scheda Query Monitor è disponibile sia per le configurazioni basate su MySQL che PostgreSQL ed è composta da tre dashboard:Top Query, Running Query e Query Outliers.
Nella dashboard Query in esecuzione, troverai tutte le query correnti in esecuzione. Questo è fondamentalmente l'equivalente dell'istruzione SHOW FULL PROCESSLIST nel database MySQL.
Le query principali e gli outlier di query si basano entrambi sull'input del registro delle query lente o dello schema delle prestazioni. L'utilizzo dello schema delle prestazioni è sempre consigliato e verrà utilizzato automaticamente se abilitato. In caso contrario, ClusterControl utilizzerà il log delle query lente di MySQL per acquisire le query in esecuzione. Per evitare che ClusterControl sia troppo invadente e che il registro delle query lente diventi troppo grande, ClusterControl analizzerà il registro delle query lente attivandolo e disattivandolo. Questo ciclo è impostato per impostazione predefinita su 1 secondo di acquisizione e long_query_time è impostato su 0,5 secondi. Se desideri modificare queste impostazioni per il tuo cluster, puoi modificarle tramite Impostazioni -> Query Monitor .
Le query principali mostreranno, come dice il nome, le query principali che sono state campionate. Puoi ordinarli su varie colonne:ad esempio la frequenza, il tempo medio di esecuzione, il tempo totale di esecuzione o il tempo di deviazione standard:
Puoi ottenere maggiori dettagli sulla query selezionandola e questo presenterà il piano di esecuzione della query (se disponibile) e suggerimenti/consigli di ottimizzazione. I valori anomali della query sono simili alle query principali, ma ti consentono di filtrare le query per host e confrontarle nel tempo.
Panoramica del cluster - Operazioni
Simile ai sistemi PostgreSQL e MySQL, i cluster MongoDB hanno la panoramica delle operazioni ed è simile alle query in esecuzione di MySQL. Questa panoramica è simile all'emissione del comando db.currentOp() all'interno di MongoDB.
Panoramica del cluster - Rendimento
MySQL/Galera
La scheda delle prestazioni è probabilmente il posto migliore per trovare le prestazioni complessive e l'integrità dei tuoi cluster. Per MySQL e Galera è costituito da una pagina Panoramica, gli Advisor, le panoramiche di stato/variabili, lo Schema Analyzer e il Registro delle transazioni.
La pagina Panoramica ti fornirà una panoramica grafica delle metriche più importanti nel tuo cluster. Questo è, ovviamente, diverso per tipo di cluster. Per impostazione predefinita sono state impostate otto metriche, ma puoi facilmente impostarne di tue - fino a 20 grafici se necessario:
Gli Advisor sono una delle caratteristiche chiave di ClusterControl:gli Advisor sono controlli tramite script che possono essere eseguiti su richiesta. I consulenti possono valutare quasi tutti i fatti noti sull'host e/o sul cluster e dare la propria opinione sullo stato di salute dell'host e/o del cluster e possono anche dare consigli su come risolvere i problemi o migliorare i tuoi host!
La parte migliore deve ancora venire:puoi creare i tuoi controlli in Developer Studio (ClusterControl -> Manage -> Developer Studio ), eseguirli a intervalli regolari e riutilizzarli nella sezione Advisors. Abbiamo scritto sul blog di questa nuova funzione all'inizio di quest'anno.
Salteremo la panoramica di stato/variabili di MySQL e Galera poiché è utile come riferimento ma non per questo post sul blog:è abbastanza buono che tu sappia che è qui.
Ora supponiamo che il tuo database stia crescendo ma desideri sapere quanto velocemente è cresciuto nell'ultima settimana. Puoi effettivamente tenere traccia della crescita sia dei dati che delle dimensioni degli indici direttamente da ClusterControl:
E oltre alla crescita totale su disco, può anche riportare i primi 25 schemi più grandi.
Un'altra caratteristica importante è lo Schema Analyzer all'interno di ClusterControl:
ClusterControl analizzerà i tuoi schemi e cercherà indici ridondanti, tabelle MyISAM e tabelle senza una chiave primaria. Ovviamente sta a te mantenere una tabella senza una chiave primaria perché alcune applicazioni potrebbero averla creata in questo modo, ma almeno è fantastico ricevere i consigli qui gratuitamente. Schema Analyzer consiglia anche l'istruzione ALTER necessaria per risolvere il problema.
PostgreSQL
Per PostgreSQL gli Advisor, lo stato del database e le variabili del database possono essere trovati qui:
MongoDB
Per MongoDB, le statistiche Mongo e la panoramica delle prestazioni sono disponibili nella scheda Prestazioni. Mongo Stats è una panoramica dell'output di mongostat e la panoramica delle prestazioni offre una buona panoramica grafica dei contatori operativi MongoDB:
Pensieri finali
Ti abbiamo mostrato come tenere d'occhio le più importanti funzionalità di monitoraggio e controllo dello stato di ClusterControl. Ovviamente questo è solo l'inizio del viaggio poiché presto inizieremo un'altra serie di blog sulle capacità di Developer Studio e su come puoi fare la maggior parte dei tuoi controlli. Tieni inoltre presente che il nostro supporto per MongoDB e PostgreSQL non è ampio quanto il nostro set di strumenti MySQL, ma stiamo migliorando continuamente.
Potresti chiederti perché abbiamo saltato il monitoraggio delle prestazioni e i controlli dello stato di HAProxy, ProxySQL e MaxScale. L'abbiamo fatto deliberatamente poiché la serie di blog riguardava solo le distribuzioni di cluster fino ad ora e non la distribuzione di componenti HA. Quindi questo è l'argomento che tratteremo la prossima volta.