ClusterControl 1.7.0 introduce una nuova audace funzionalità:l'integrazione con Prometheus per il monitoraggio basato su agenti. Abbiamo chiamato questo SCUMM (Severalnines ClusterControl Unified Management and Monitoring). Nelle versioni precedenti, le attività di monitoraggio venivano eseguite esclusivamente senza agenti. Se ti chiedi come ClusterControl svolga le sue funzioni di monitoraggio, dai un'occhiata a questa pagina della documentazione.
ProxySQL, un proxy inverso ad alte prestazioni che comprende i protocolli MySQL, si trova comunemente sopra MySQL Replication e Galera Cluster per fungere da gateway per il servizio MySQL di back-end. Può essere configurato come router di query, firewall di query, cache di query, dispatcher di traffico e molti altri. ProxySQL raccoglie ed espone anche le metriche chiave tramite il suo schema STATS che è molto utile per analizzare le prestazioni e capire cosa accade effettivamente dietro le quinte. Visita il nostro tutorial completo per ProxySQL per saperne di più.
In questo post del blog, esamineremo in modo approfondito il monitoraggio delle istanze ProxySQL con questo nuovo approccio. In questo esempio, abbiamo un'istanza ProxySQL in cima alla nostra replica MySQL a due nodi (1 master, 1 slave), distribuita tramite ClusterControl. La nostra architettura di alto livello è simile a questa:
Abbiamo anche le seguenti regole di query definite nell'istanza ProxySQL (solo per riferimento, per dare un senso alle metriche di monitoraggio raccolte più in basso):
Abilitazione di Prometeo
Il monitoraggio basato su agente di ClusterControl è abilitato per cluster. ClusterControl può distribuire un nuovo server Prometheus per te o utilizzare un server Prometheus esistente (distribuito da ClusterControl per altri cluster). Abilitare Prometheus è piuttosto semplice. Basta andare su ClusterControl -> selezionare il cluster -> Dashboard -> Abilita monitoraggio basato su agente:
Quindi, specifica l'indirizzo IP o il nome host del nuovo server Prometheus o scegli semplicemente un host Prometheus esistente dal menu a discesa:
ClusterControl installerà e configurerà i pacchetti necessari (Prometheus sul server Prometheus, esportatori sul database e nodi ProxySQL), si connetterà a Prometheus come origine dati e inizierà a visualizzare i dati di monitoraggio nell'interfaccia utente.
Al termine del processo di distribuzione, dovresti essere in grado di accedere alla scheda Dashboard come mostrato nella sezione successiva.
Dashboard ProxySQL
È possibile accedere ai dashboard di ProxySQL accedendo al rispettivo cluster nella scheda Dashboard. Facendo clic sul menu a discesa Dashboard verranno elencati i dashboard relativi al nostro cluster (replica MySQL). Puoi trovare la dashboard Panoramica di ProxySQL nella sezione "Load Balancer":
Esistono numerosi pannelli per ProxySQL, alcuni dei quali sono autoesplicativi. Tuttavia, visitiamoli uno per uno.
Dimensione gruppo host
La dimensione del gruppo host è semplicemente il numero totale di host su tutti i gruppi host:
In questo caso, abbiamo due gruppi host:10 (scrittore) e 20 (lettore). Il gruppo host 10 è costituito da un host (master) mentre il gruppo host 20 ha due host (master e slave), per un totale di tre host.
A meno che tu non modifichi la configurazione del gruppo host (introduzione di un nuovo host, rimozione di un host esistente) da ProxySQL, dovresti aspettarti che non cambi nulla in questo grafico.
Connessioni client
Il numero di connessioni client elaborate da ProxySQL per tutti i gruppi host:
Il grafico sopra ci dice semplicemente che ci sono costantemente 8 client MySQL collegati alla nostra istanza ProxySQL sulla porta 6033 negli ultimi 45 minuti (puoi cambiarlo nell'opzione "Selezione intervallo"). Se interrompi la connessione della tua applicazione a ProxySQL (o la eviti), il valore dovrebbe eventualmente scendere a 0.
Domande dei clienti
Il grafico visualizza il numero di domande elaborate da ProxySQL per tutti i gruppi host:
Secondo la documentazione di MySQL, le domande sono semplicemente il numero di istruzioni eseguite dal server. Ciò include solo le istruzioni inviate al server dai client e non le istruzioni eseguite all'interno dei programmi memorizzati, a differenza della variabile Query. Questa variabile non conta i comandi COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE o COM_STMT_RESET. Anche in questo caso, se interrompi la connessione dell'applicazione a ProxySQL (o la escludi), il valore dovrebbe scendere a 0.
Connessioni back-end attive
Il numero di connessioni che ProxySQL mantiene ai server MySQL di back-end per host:
Ci dice semplicemente quante connessioni sono attualmente utilizzate da ProxySQL per inviare query al server back-end. Finché il valore massimo non è vicino al limite di connessione per il particolare server (impostato tramite max_connections quando il server viene aggiunto al gruppo host ProxySQL), siamo in buone condizioni.
Connessioni back-end fallite
Il numero di connessioni che non sono state stabilite correttamente da ProxySQL:
L'esempio sopra mostra semplicemente che non si è verificato alcun errore di connessione back-end negli ultimi 45 minuti.
Query inoltrate
Questo grafico fornisce informazioni dettagliate sulla distribuzione delle istruzioni in entrata ai server back-end:
Come puoi vedere, la maggior parte delle letture andrà al gruppo host del lettore (HG20). Da qui possiamo comprendere il modello di bilanciamento eseguito da ProxySQL che corrisponde alle nostre regole di query in questo carico di lavoro ad alta intensità di lettura.
Connessione gratuita
Il grafico mostra quante connessioni sono attualmente libere:
Le connessioni vengono mantenute aperte per ridurre al minimo il costo del tempo necessario per inviare una query al server di backend.
Latenza
Il tempo di ping corrente in microsecondi, come riportato dal thread di monitoraggio di ProxySQL:
Questo ci dice semplicemente quanto è stabile la connessione dal ProxySQL ai server MySQL di back-end. Un valore elevato per un periodo di tempo lungo e costante indica principalmente un problema di rete tra di loro.
Query memoria cache
Questo grafico visualizza il consumo di memoria delle query memorizzate nella cache da ProxySQL:
Dal grafico sopra, possiamo dire che ProxySQL consuma una quantità totale di 8 MB di memoria dalla cache delle query. Dopo aver raggiunto il limite di 8 MB (configurabile tramite mysql-query_cache_size_MB variabile), la memoria verrà eliminata dal thread di eliminazione di ProxySQL. Questo grafico non verrà compilato se non sono state definite regole per la cache delle query.
A proposito, la memorizzazione nella cache di una query in ProxySQL può essere eseguita in soli due clic con ClusterControl. Vai alla pagina Query principali di ProxySQL, passa il mouse su una query, fai clic su Query Cache e fai clic su "Aggiungi regola":
Efficienza della cache delle query
Questo grafico visualizza l'efficienza delle query memorizzate nella cache:
La linea blu indica il rapporto di successo delle richieste GET eseguite sulla cache delle query in cui il set di risultati era presente e non scaduto. La linea rosa mostra il rapporto tra i dati scritti (inseriti) o letti dalla Query Cache. In questo caso, i nostri dati letti da Query Cache sono superiori ai dati scritti che indicano un'efficiente configurazione della cache.
Questo grafico non verrà compilato se non sono state definite regole per la cache delle query.
Traffico di rete
Questo grafico visualizza il traffico di rete (ricezione dati + dati inviati) da/verso i server MySQL di back-end, per host:
La schermata sopra ci dice che una quantità significativa di traffico viene inoltrata/ricevuta da/verso il gruppo host del lettore (HG20). In questo carico di lavoro ad alta intensità di lettura, le operazioni di lettura consumano comunemente un traffico molto più elevato principalmente a causa delle dimensioni del set di risultati delle istruzioni SELECT.
Solo un rapporto più piccolo del traffico viene inoltrato/ricevuto da/al gruppo host di scrittura (HG10), il che è previsto poiché le operazioni di scrittura di solito consumano meno traffico di rete con un set di risultati significativamente piccolo restituito ai client.
Efficienza di mirroring
Il grafico mostra semplicemente lo stato relativo al mirroring del traffico come Mirror_concurrency vs Mirror_queue_length:
Il grafico viene popolato solo se hai configurato il mirroring del traffico (mirror_hostgroup all'interno della regola di query). Se la coda di mirroring si sta attivando, la riduzione del limite di concorrenza del mirroring aumenterà l'efficienza del mirroring, che può essere controllata tramite mysql-mirror_max_concurrency variabile. In parole semplici, le voci di coda zero sono l'obiettivo del mirroring più efficiente.
Utilizzo della memoria
Il grafico illustra l'utilizzo della memoria da parte dei componenti principali all'interno di ProxySQL:pool di connessioni, cache di query e archiviazione persistente (SQLite):
Lo screenshot sopra ci dice che l'ingombro della memoria ProxySQL è piuttosto piccolo, inferiore a 12 MB in totale. Il pool di connessioni consuma solo 1,3 MB in alto per ospitare il nostro carico di lavoro a 8 thread (client). Con più RAM disponibile sull'host, dovremmo essere in grado di aumentare il numero di connessioni client a ProxySQL da tre a quattro volte o memorizzare nella cache molte più query calde all'interno di ProxySQL per scaricare i nostri server di backend MySQL.
Funzione bonus - Rendimento del nodo
ClusterControl 1.7.0 ora include le metriche delle prestazioni dell'host per le istanze ProxySQL. Nella versione precedente, ClusterControl monitorava solo le metriche relative a ProxySQL come esposte dallo schema delle statistiche ProxySQL. È possibile accedere a questa nuova funzionalità nella scheda Node -> Istanza ProxySQL -> Prestazioni nodo:
Gli istogrammi forniscono informazioni dettagliate sulle metriche principali dell'host, simili a quelle che vengono campionati per i nodi del database nella sezione Nodi -> Panoramica. Se la tua istanza ProxySQL si trova nello stesso server con l'applicazione, stai letteralmente usando ClusterControl per monitorare anche il server delle applicazioni. Quanto è bello?!
Pensieri finali
L'integrazione di ClusterControl con Prometheus offre un modo alternativo per monitorare e analizzare lo stack del database, fino al livello proxy inverso. Ora puoi scegliere di scaricare i lavori di monitoraggio su Prometheus o continuare a utilizzare l'approccio di monitoraggio senza agente ClusterControl predefinito per la tua infrastruttura di database.
