Abbiamo aggiunto una serie di nuovi dashboard per MySQL nella nostra ultima versione di ClusterControl 1.7.0. - e nel nostro blog precedente ti abbiamo mostrato come monitorare il tuo ProxySQL con Prometheus e ClusterControl.
In questo blog esamineremo la dashboard Panoramica di MySQL.
Pertanto, abbiamo abilitato il monitoraggio basato sugli agenti nella scheda Dashboard per iniziare a raccogliere le metriche sui nodi. Tieni presente che quando abiliti il monitoraggio basato sugli agenti, hai le opzioni per impostare "Intervallo di scrape (secondi) " e "Conservazione dei dati (giorni) ”. L'intervallo di scraping è il punto in cui desideri impostare l'aggressività con cui Prometheus raccoglierà i dati dal target e Data Retention è il tempo in cui desideri conservare i dati raccolti da Prometheus prima che vengano eliminati.
Se abilitato, puoi identificare quale cluster ha agenti e quale ha il monitoraggio senza agente.
Rispetto all'approccio agentless, la granularità dei tuoi dati nei grafici sarà maggiore con gli agent.
I grafici MySQL
L'ultima versione di ClusterControl 1.7.0 (che puoi scaricare gratuitamente - ClusterControl Community) ha le seguenti dashboard MySQL per le quali puoi raccogliere informazioni per i tuoi server MySQL. Si tratta di Panoramica di MySQL, Metriche di MySQL InnoDB, Schema delle prestazioni di MySQL e Replica di MySQL.
Tratteremo in dettaglio i grafici disponibili nella dashboard Panoramica di MySQL.
Dashboard Panoramica di MySQL
Questa dashboard contiene le solite variabili importanti o informazioni relative allo stato di salute del tuo nodo MySQL. I grafici contenuti in questa dashboard sono specifici del nodo selezionato durante la visualizzazione delle dashboard come mostrato di seguito:
È composto da 26 grafici, ma potrebbero non essere necessari tutti per la diagnosi dei problemi. Tuttavia, questi grafici forniscono una rappresentazione vitale delle metriche complessive per i tuoi server MySQL. Esaminiamo quelli di base, poiché queste sono probabilmente le cose più comuni che un DBA esaminerà regolarmente.
I primi quattro grafici mostrati sopra insieme al tempo di attività di MySQL, alle query al secondo e alle informazioni sul pool di buffer sono i suggerimenti più basilari di cui potremmo aver bisogno. Dai grafici visualizzati sopra, ecco le loro rappresentazioni:
- Connessioni MySQL
Qui è dove vuoi controllare le tue connessioni client totali finora allocate in un determinato periodo di tempo. - Attività thread del client MySQL
A volte il tuo server MySQL potrebbe essere molto occupato. Ad esempio, è possibile che riceva un aumento del traffico in un momento specifico e si desidera monitorare l'attività dei thread in esecuzione. Questo grafico è davvero importante da guardare. Ci possono essere momenti in cui le prestazioni della query potrebbero peggiorare se, ad esempio, un aggiornamento di grandi dimensioni fa sì che altri thread attendano per acquisire il blocco. Ciò comporterebbe un aumento del numero di thread in esecuzione. Il tasso di perdita della cache viene calcolato come Threads_created/Connections. - Domande su MySQL
Queste sono le query in esecuzione in un determinato periodo di tempo. Un thread potrebbe essere una transazione composta da più query e questo può essere un buon grafico da guardare. - Cache dei thread MySQL
Questo grafico mostra il valore thread_cache_size, i thread che vengono memorizzati nella cache (thread che vengono riutilizzati) e i thread che vengono creati (nuovi thread). Puoi controllare questo grafico per quei casi come se dovessi ottimizzare le tue query di lettura quando noti un numero elevato di connessioni in entrata e i tuoi thread creati aumentano rapidamente. Ad esempio, se Threads_running / thread_cache_size> 2, l'aumento di thread_cache_size può aumentare le prestazioni del tuo server. Tieni presente che la creazione e la distruzione dei thread sono costose. Tuttavia, nelle versioni recenti di MySQL (>=5.6.8), questa variabile ha il ridimensionamento automatico per impostazione predefinita, cosa che potresti considerare intatta.
I prossimi quattro grafici sono MySQL Temporary Objects, MySQL Select Types, MySQL Sorts e MySQL Slow Query. Questi grafici sono correlati tra loro specialmente se stai diagnosticando query di lunga durata e query di grandi dimensioni che necessitano di ottimizzazione.
- Oggetti temporanei MySQL
Questo grafico sarebbe una buona fonte su cui fare affidamento se si desidera monitorare query a esecuzione prolungata che finirebbero per utilizzare il disco anziché tabelle temporanee o file in memoria. È un buon punto di partenza per cercare l'occorrenza periodica di query che potrebbero sommarsi creando problemi di spazio su disco, soprattutto durante i periodi dispari. - Tipi di selezione MySQL
Una fonte di prestazioni scadenti sono le query che utilizzano join completi, scansioni di tabelle e intervalli di selezione che non utilizzano indici. Questo grafico mostrerebbe il rendimento della tua query e quali nell'elenco, dai join completi, ai join a intervallo completo, all'intervallo selezionato, alle scansioni delle tabelle ha le tendenze più elevate. - Ordini MySQL
Diagnosi delle query che utilizzano l'ordinamento e di quelle che richiedono molto tempo per essere completate. - Query lente MySQL
Le tendenze delle tue query lente sono raccolte qui su questo grafico. Questo è molto utile soprattutto per diagnosticare la frequenza con cui le tue query sono lente. Quali sono le cose che devono essere messe a punto? Potrebbe trattarsi di un pool di buffer troppo piccolo, tabelle prive di indici e che esegue una scansione completa della tabella, backup logici eseguiti con una pianificazione imprevista, ecc. L'utilizzo del nostro Query Monitor in ClusterControl insieme a questo grafico è vantaggioso, poiché aiuta a determinare le query lente.
I prossimi grafici che tratteremo riguardano maggiormente l'attività di rete, i blocchi delle tabelle e la memoria interna sottostante che MySQL sta consumando durante l'attività di MySQL.
- Connessioni interrotte MySQL
Il numero di connessioni interrotte verrà visualizzato su questo grafico. Questo copre i client interrotti, ad esempio dove la rete è stata chiusa bruscamente o dove la connessione Internet era inattiva o interrotta. Registra anche le connessioni o i tentativi interrotti come password errate o pacchetti errati dopo aver stabilito una connessione dal client. - Blocchi tabella MySQL
Trend per le tabelle che richiedono un blocco tabella che è stato concesso immediatamente e per le tabelle che richiedono un blocco che non è stato acquisito immediatamente. Ad esempio, se hai blocchi a livello di tabella su tabelle MyISAM e richieste in entrata della stessa tabella, questi non possono essere concessi immediatamente. - Traffico di rete MySQL
Questo grafico mostra le tendenze dell'attività di rete in entrata e in uscita nel server MySQL. "Inbound" sono i dati ricevuti dal server MySQL mentre "Outbound" sono i dati inviati o trasferiti dal server dal server MySQL. Questo grafico è meglio controllare se si desidera monitorare il traffico di rete soprattutto quando si diagnostica se il proprio traffico è moderato ma ti stai chiedendo perché ha un numero di dati trasferiti in uscita molto elevato, come ad esempio i dati BLOB. - Utilizzo della rete MySQL ogni ora
Uguale al traffico di rete che mostra i dati ricevuti e inviati. Tieni presente che si basa su "per ora" ed è etichettato con "ultimo giorno" che non seguirà il periodo di tempo selezionato nel selettore di date. - Panoramica della memoria interna MySQL
Questo grafico è familiare per un DBA MySQL esperto. Ognuna di queste legende nel grafico a barre è molto importante soprattutto se desideri monitorare l'utilizzo della memoria, l'utilizzo del pool di buffer o la dimensione dell'indice hash adattivo.
I grafici seguenti mostrano i contatori su cui un DBA può fare affidamento come ad esempio il controllo delle statistiche, le statistiche per selezioni, inserimenti, aggiornamenti, il numero di stato master che è stato eseguito, il numero di SHOW VARIABLES che è stato eseguito, controllo se hai query errate che eseguono scansioni di tabelle o tabelle che non utilizzano indici esaminando i contatori read_*, ecc.
- Contatori comandi principali (ogni ora)
Questi sono i grafici che dovresti probabilmente controllare ogni volta che vorresti vedere le statistiche per i tuoi inserimenti, eliminazioni, aggiornamenti, comandi eseguiti come la raccolta dell'elenco dei processi, lo stato dello slave, lo stato dello spettacolo (statistiche sull'integrità del server MySQL ), e tanti altri. Questo è un buon posto se vuoi controllare che tipo di contatori di comandi MySQL sono più in alto e se è necessaria un'ottimizzazione delle prestazioni o dell'ottimizzazione delle query. Potrebbe anche consentirti di identificare quali comandi vengono eseguiti in modo aggressivo senza che siano necessari. - Gestori MySQL
Spesso, un DBA esamina questi gestori e controlla le prestazioni delle query nel server MySQL. Fondamentalmente, questo grafico copre i contatori dell'API Handler di MySQL. I contatori del gestore più comuni per un DBA per l'API di archiviazione in MySQL sono Handler_read_first, Handler_read_key, Handler_read_last, Handler_read_next, Handler_read_prev, Handler_read_rnd e Handler_read_rnd_next. Ci sono molti gestori MySQL da controllare. Puoi leggerli nella documentazione qui. - Gestori delle transazioni MySQL
Se il tuo server MySQL utilizza transazioni XA, istruzioni SAVEPOINT, ROLLBACK TO SAVEPOINT. Allora questo grafico è un buon riferimento da guardare. Puoi anche utilizzare questo grafico per monitorare tutti i commit interni del tuo server. Tieni presente che il contatore per Handler_commit aumenta anche per le istruzioni SELECT ma differisce dalle istruzioni insert/update/delete che vanno al log binario durante una chiamata all'istruzione COMMIT.
Il grafico successivo mostrerà le tendenze sugli stati di processo e il loro utilizzo orario. Ci sono molti punti chiave qui nella legenda del grafico a barre che un DBA dovrebbe controllare. Incontrare problemi di spazio su disco, problemi di connessione e verificare se il pool di connessioni funziona come previsto, I/O su disco elevato, problemi di rete, ecc.
- Stati di processo/stati di processo principali ogni ora
Questo grafico è il punto in cui puoi monitorare gli stati dei thread principali delle tue query in esecuzione nell'elenco dei processi. Questo è molto istruttivo e utile per tali attività DBA in cui è possibile esaminare qui tutti gli stati in sospeso che necessitano di risoluzione. Ad esempio, apertura di tabelle stato è molto alto e il suo valore minimo è quasi vicino al valore massimo. Ciò potrebbe indicare che è necessario modificare table_open_cache. Se le statistiche è alto e stai notando un rallentamento del tuo server, questo potrebbe indicare che il tuo server è legato al disco e potresti dover considerare di aumentare il tuo pool di buffer. Se hai un numero elevato di creazione di tabelle tmp quindi potresti dover controllare il tuo registro lento e ottimizzare le query offensive. Puoi controllare il manuale per l'elenco completo degli stati dei thread MySQL qui.
Il prossimo grafico che controlleremo riguarda la cache delle query, la cache di definizione della tabella MySQL, la frequenza con cui MySQL apre i file di sistema.
- Memoria/attività della cache di query MySQL
Questi grafici sono correlati tra loro. Se hai query_cache_size <> 0 e query_cache_type <> 0, allora questo grafico può essere di aiuto. Tuttavia, nelle versioni più recenti di MySQL, la cache delle query è stata contrassegnata come obsoleta poiché è noto che la cache delle query MySQL causa problemi di prestazioni. Potresti non averne bisogno in futuro. La versione più recente di MySQL 8.0 ha miglioramenti drastici; tende ad aumentare le prestazioni in quanto viene fornito con diverse strategie per gestire le informazioni della cache nei buffer di memoria. - Aperture di file MySQL
Questo grafico mostra l'andamento dei file aperti dall'uptime del server MySQL, ma esclude file come socket o pipe. Inoltre non include i file aperti dal motore di archiviazione poiché hanno il proprio contatore che è Innodb_num_open_files. - File aperti MySQL
Questo grafico è il punto in cui vuoi controllare i tuoi file InnoDB attualmente aperti, i file MySQL attualmente aperti e la tua variabile open_files_limit. - Stato della cache aperta della tabella MySQL
Se hai table_open_cache molto bassa impostata qui, questo grafico ti parlerà di quelle tabelle che falliscono la cache (tabelle aperte di recente) o mancano a causa dell'overflow. Se riscontri un numero elevato o uno stato di "tabelle di apertura" troppo elevato nel tuo elenco di processi, questo grafico servirà come riferimento per determinarlo. Questo ti dirà se è necessario aumentare la variabile table_open_cache. - Tabelle aperte MySQL
Relativamente allo stato della cache aperta della tabella MySQL, questo grafico è utile in determinate occasioni, ad esempio se desideri identificare se è necessario aumentare la tua table_open_cache o abbassarla se noti un aumento elevato delle tabelle aperte o della variabile di stato di Open_tables . Nota che table_open_cache potrebbe occupare una grande quantità di spazio di memoria, quindi devi impostarlo con cura soprattutto nei sistemi di produzione. - Cache di definizione della tabella MySQL
Se vuoi controllare il numero delle tue variabili di stato Open_table_definitions e Opened_table_definitions, allora questo grafico è ciò di cui hai bisogno. Per le versioni più recenti di MySQL (>=5.6.8), potrebbe non essere necessario modificare il valore di questa variabile e utilizzare il valore predefinito poiché ha la funzione di ridimensionamento automatico.
Conclusione
L'aggiunta SCUMM nell'ultima versione di ClusterControl 1.7.0 offre nuovi vantaggi significativi per una serie di attività DBA chiave. I nuovi grafici possono aiutare a individuare facilmente la causa dei problemi che i DBA o gli amministratori di sistema dovrebbero in genere affrontare e aiutano a trovare soluzioni appropriate più velocemente.
Ci piacerebbe conoscere la tua esperienza e le tue opinioni sull'utilizzo di ClusterControl 1.7.0 con SCUMM (che puoi scaricare gratuitamente - ClusterControl Community).
Nella parte 2 di questo blog, parlerò del monitoraggio efficace della replica di MySQL con i dashboard SCUMM.
