MongoDB
 sql >> Database >  >> NoSQL >> MongoDB

Monitoraggio database senza agente con ClusterControl

Con la crescente complessità delle configurazioni del database, molti SysAdmin e DBA si stanno rivolgendo a un approccio agentless per alleviare il carico delle sfide di monitoraggio del database. Il monitoraggio agentless di ClusterControl consente di monitorare i database senza installare il software agent su ciascun sistema monitorato. ClusterControl implementa il monitoraggio utilizzando un raccoglitore di dati remoto che utilizza il protocollo SSH.

Prima di addentrarci direttamente nelle specifiche del monitoraggio senza agente, chiariamo innanzitutto l'ambito e il significato del monitoraggio nel nostro contesto qui. Il monitoraggio viene dopo l'andamento dei dati, il processo di raccolta e archiviazione delle metriche, che consente al sistema di monitoraggio di elaborare i dati raccolti per produrre una giustificazione per l'ottimizzazione, l'avviso e la visualizzazione dei dati di tendenza per i rapporti.

A partire dalla versione 1.7.0 (rilasciata a dicembre 2018), ClusterControl supporta due metodi di monitoraggio:

  • Monitoraggio senza agenti (predefinito)
  • Monitoraggio basato su agenti con Prometheus

Questo post spiega come monitorare i server di database e i cluster con il monitoraggio agentless di ClusterControl. Se stai cercando maggiori informazioni sul monitoraggio basato su agenti di ClusterControl, puoi fare riferimento a questa documentazione.

In generale, ClusterControl esegue attività di monitoraggio, avviso e trend senza agenti utilizzando i tre metodi seguenti:

  • SSH:raccolta delle metriche dell'host (processo, statistiche sui bilanciatori di carico, utilizzo delle risorse, consumo, ecc.) utilizzando la libreria SSH
  • Client del database:raccolta delle metriche del database (stato, query, variabili, utilizzo, ecc.) utilizzando la rispettiva libreria del client del database
  • Advisor – Mini programmi scritti utilizzando ClusterControl DSL e eseguiti all'interno di ClusterControl stesso per scopi di monitoraggio, ottimizzazione e avviso

SSH sta per Secure Shell, un protocollo di rete sicuro utilizzato dalla maggior parte dei server basati su Linux per l'amministrazione remota. ClusterControl Controller, o CMON, è il servizio di back-end che esegue attività di automazione, gestione, monitoraggio e pianificazione, basato su C++.

ClusterControl DSL (Domain Specific Language) ti consente di estendere le funzionalità della tua piattaforma ClusterControl creando Advisor, Auto Tuner o "Mini Programmi". La sintassi DSL è basata su JavaScript, con estensioni per fornire l'accesso alle strutture dati e alle funzioni interne di ClusterControl. Il DSL ti consente di eseguire istruzioni SQL, eseguire comandi/programmi shell su tutti gli host del cluster e recuperare risultati da elaborare per avvisi/avvisi o qualsiasi altra azione.

Strumenti di monitoraggio

Tutti gli strumenti prerequisiti vengono soddisfatti dallo script di installazione o installati automaticamente da ClusterControl durante la fase di distribuzione del database o se il file/binario/pacchetto richiesto non esiste sul server di destinazione prima dell'esecuzione di un lavoro. In generale, il servizio di monitoraggio ClusterControl richiede solo il pacchetto server OpenSSH sugli host monitorati. ClusterControl utilizza la libreria client libssh per raccogliere le metriche host per gli host monitorati:CPU, memoria, disco, rete, IO, processo e così via. Il pacchetto client OpenSSH è richiesto sull'host ClusterControl solo per configurare SSH senza password e scopi di debug. Altre implementazioni SSH come Dropbear e TinySSH non sono supportate.

Durante la raccolta delle statistiche e delle metriche del database, ClusterControl Controller (CMON) si connette al server del database direttamente tramite le librerie client del database:libmysqlclient (MySQL/MariaDB e ProxySQL), libpq (PostgreSQL) e libmongocxx (MongoDB) ). Ecco perché è fondamentale impostare i privilegi appropriati per un server ClusterControl dal punto di vista di un server di database. Per i cluster basati su MySQL, ClusterControl richiede l'utente del database "cmon" mentre per altri database è possibile utilizzare qualsiasi nome utente per il monitoraggio, purché siano concessi i privilegi di superutente. Nella maggior parte dei casi, ClusterControl imposterà automaticamente i privilegi richiesti (o utilizzerà l'utente del database specificato) durante l'importazione del cluster o la fase di distribuzione del cluster.

ClusterControl richiede i seguenti strumenti per i bilanciatori di carico:

  • Maxctrl sul server MariaDB MaxScale
  • netcat e/o socat sul server HAProxy per connettersi al file socket HAProxy e recuperare i dati di monitoraggio
  • ProxySQL richiede un client mysql sul server ProxySQL

Il diagramma seguente illustra i processi di monitoraggio dell'host e del database eseguiti da ClusterControl utilizzando libssh e le librerie client del database:

Sebbene i thread di monitoraggio non necessitino di pacchetti client di database installati sull'host monitorato, è altamente raccomandato averli per scopi di gestione. Ad esempio, il pacchetto client MySQL viene fornito con i programmi mysql, mysqldump, mysqlbinlog e mysqladmin, che verranno utilizzati da ClusterControl durante l'esecuzione di backup e ripristino point-in-time.

Metodi di monitoraggio

Per la raccolta delle statistiche dell'host e del bilanciamento del carico, ClusterControl esegue questa attività tramite SSH con privilegi di superutente. Pertanto, SSH senza password con privilegi di superutente è fondamentale per consentire a ClusterControl di eseguire i comandi necessari in remoto con una corretta escalation. Con questo approccio pull, ci sono un paio di vantaggi rispetto ad altri meccanismi:

  • Senza agente:non è necessario installare, configurare e mantenere un agente.
  • Unificazione della configurazione di gestione e monitoraggio:SSH può essere utilizzato per eseguire il pull delle metriche di monitoraggio o eseguire il push dei processi di gestione sui nodi di destinazione.
  • Semplifica la distribuzione:l'unico requisito è una corretta configurazione SSH senza password, e il gioco è fatto. SSH è anche molto sicuro e crittografato.
  • Configurazione centralizzata:un server ClusterControl può gestire più server e cluster, a condizione che disponga di risorse sufficienti.

Tuttavia, il meccanismo di trazione presenta anche i seguenti inconvenienti:

  • I dati di monitoraggio sono accurati solo dal punto di vista di ClusterControl. Ad esempio, se si verifica un problema tecnico di rete e ClusterControl perde la comunicazione con l'host monitorato, il campionamento verrà saltato fino al prossimo ciclo disponibile.
  • Ci sarà un sovraccarico di rete per il monitoraggio ad alta granularità a causa della maggiore frequenza di campionamento in cui ClusterControl deve stabilire più connessioni a ogni host di destinazione.
  • ClusterControl continuerà a tentare di ristabilire la connessione al nodo di destinazione perché non ha un agente che lo faccia per suo conto.
  • Campionamento dei dati ridondante se si dispone di più server ClusterControl che monitorano un cluster poiché ciascun server ClusterControl deve estrarre i dati di monitoraggio da solo.

Per il monitoraggio delle query MySQL, a partire da ClusterControl 1.9.0 (rilasciato a luglio 2021), ClusterControl supporta due tipi:

  • Monitoraggio query senza agente (predefinito)
  • Monitoraggio delle query basato sull'agente tramite l'agente di query CMON, che richiede passaggi aggiuntivi per abilitarlo. Solo per database basati su MySQL e PostgreSQL.

Il monitoraggio delle query senza agente monitora le query in due modi diversi:

  • Le query vengono recuperate da PERFORMANCE_SCHEMA interrogando lo schema sul nodo del database tramite SSH.
  • Se PERFORMANCE_SCHEMA è disabilitato o non disponibile, ClusterControl analizzerà il contenuto del registro delle query lente tramite SSH.

Se lo schema delle prestazioni è abilitato, ClusterControl lo utilizzerà per cercare le query lente. In caso contrario, ClusterControl analizzerà il contenuto del log delle query lente MySQL (tramite slow_query_log=ON variabile dinamica) in base al flusso seguente:

  1. Avvia registro lento (durante il runtime MySQL).
  2. Eseguilo per un breve periodo di tempo (un secondo o un paio di secondi).
  3. Interrompi registro.
  4. Analizza registro.
  5. Tronca registro (nuovo file di registro).
  6. Vai a 1.

Le query raccolte vengono sottoposte a hash, calcolate e digerite (normalizza, media, conteggia, ordina) e quindi archiviate nel database ClusterControl CMON. Tieni presente che per questo metodo di campionamento esiste una leggera possibilità che alcune query non vengano acquisite, specialmente durante le parti "stop log, parse log, tronca log". Puoi abilitare Performance Schema se questa non è un'opzione.

Solo le query che superano il tempo di query lungo verranno elencate qui utilizzando il registro delle query lente. Supponiamo che i dati non siano popolati correttamente e ritieni che ci dovrebbe essere qualcosa lì dentro, potrebbe essere anche quello:

  • ClusterControl non ha raccolto abbastanza query per riepilogare e popolare i dati. Prova a ridurre il tempo di query lungo.
  • Hai configurato le opzioni di configurazione Slow Query Log nel my.cnf del server MySQL e Override Local Query è disattivato. Se vuoi davvero utilizzare il valore che hai definito all'interno di my.cnf, probabilmente dovrai abbassare il valore long_query_time in modo che ClusterControl possa calcolare un risultato più accurato.
  • Si dispone anche di un altro nodo ClusterControl che estrae il registro di query lenta (nel caso in cui si disponga di un server ClusterControl in standby). Consenti a un solo server ClusterControl di eseguire questo lavoro.

Puoi anche utilizzare ClusterControl Query Monitor per MySQL, MariaDB e Percona Server.

Per il monitoraggio delle query PostgreSQL, ClusterControl richiede il modulo pg_stat_statements per tenere traccia delle statistiche di esecuzione di tutte le istruzioni SQL. Popola le viste e le funzioni di pg_stat_statements durante la visualizzazione delle query nell'interfaccia utente (nella scheda Query Monitor).

Intervalli e timeout

ClusterControl Controller (cmon) è un processo multi-thread. Per impostazione predefinita, il thread di campionamento di ClusterControl Controller si connette a ciascun host monitorato una volta e mantiene una connessione persistente fino a quando l'host non si interrompe o si disconnette durante il campionamento delle statistiche dell'host. Può stabilire più connessioni a seconda dei lavori assegnati all'host poiché la maggior parte dei lavori di gestione viene eseguita nel proprio thread. Ad esempio, il ripristino del cluster viene eseguito sul thread di ripristino, l'esecuzione di Advisor viene eseguita su un thread cron e il monitoraggio del processo viene eseguito sul thread di raccolta del processo.

Il thread di monitoraggio di ClusterControl esegue le seguenti operazioni di campionamento nel seguente intervallo:

  • Metriche query/stato MySQL:ogni secondo
  • Raccolta processo (/proc):ogni 10 secondi
  • Rilevamento del server:ogni 10 secondi
  • Metriche host (/proc, /sys):ogni 30 secondi (configurabile tramite host_stats_collection_interval)
  • Metriche del database (solo PostgreSQL e MongoDB):ogni 30 secondi (configurabile tramite db_stats_collection_interval)
  • Metriche dello schema del database:ogni 3 ore (configurabile tramite db_schema_stats_collection_interval)
  • Metriche del bilanciamento del carico:ogni 15 secondi (configurabili tramite lb_stats_collection_interval)

Gli script imperativi (Advisor) possono utilizzare le librerie client di database e SSH fornite con CMON con le seguenti restrizioni:

  • 5 secondi di limite massimo per l'esecuzione SSH.
  • 10 secondi di limite predefinito per la connessione al database, configurabile tramite net_read_timeout, net_write_timeout, connect_timeout nel file di configurazione CMON.
  • 60 secondi di limite di tempo totale per l'esecuzione dello script prima che CMON lo interrompa senza grazia.

Gli advisor possono essere creati, compilati, testati e programmati direttamente dall'interfaccia utente di ClusterControl in Gestisci → Developer Studio . Lo screenshot seguente mostra un esempio di un Advisor per estrarre le prime 10 query da PERFORMANCE_SCHEMA:

L'esecuzione degli advisor dipende dall'attivazione e dal tempo di schedulazione in formato cron:

I risultati dell'esecuzione vengono visualizzati in Prestazioni → Consulenti , come mostrato nella schermata seguente:

Per ulteriori informazioni su quali consulenti vengono forniti per impostazione predefinita, consulta il nostro sviluppatore Pagina del prodotto Studio.

I dati vengono archiviati direttamente nel database CMON per il monitoraggio di dati a breve intervallo come le query e lo stato MySQL. I dati di monitoraggio a lungo intervallo come i punti dati settimanali/mensili/annuali vengono aggregati ogni 60 secondi e archiviati in memoria per 10 minuti. Questi comportamenti non sono configurabili a causa della progettazione dell'architettura.

Parametri

ClusterControl ha molti parametri per adattarsi alla tua politica di monitoraggio e avviso. La maggior parte di essi è configurabile tramite ClusterControl UI → scegli un cluster → Impostazioni . La scheda "Impostazioni" offre molte opzioni per configurare avvisi, soglie, notifiche, layout del grafico, contatori di database, monitoraggio delle query e così via. Ad esempio, le soglie di avviso e di criticità sono configurabili come segue:

La pagina “Runtime Configuration” mostra un elenco riepilogativo dei ClusterControl Controller attivi (CMON) parametri di configurazione runtime:

Ci sono più di 170 opzioni di configurazione di ClusterControl Controller in totale e alcune le impostazioni avanzate possono essere configurate per il monitoraggio e la messa a punto dei criteri di avviso. Alcuni di questi includono:

  • monitor_cpu_temperature
  • swap_warning
  • swap_critical
  • redobuffer_warning
  • redobuffer_critical
  • indexmemory_warning
  • indexmemory_critical
  • datamemory_warning
  • datamemory_critical
  • tablespace_warning
  • tablespace_critical
  • redolog_warning
  • redolog_critical
  • max_replication_lag
  • long_query_time
  • log_queries_not_using_indexes
  • query_monitor_use_local_settings
  • enable_query_monitor
  • enable_query_monitor_auto_purge_ps

È possibile modificare i parametri elencati nella pagina "Configurazione runtime" utilizzando l'interfaccia utente o il file di configurazione CMON che si trova in /etc/cmon.d/cmon_X.cnf, dove X è l'ID del cluster. Puoi elencare tutte le opzioni di configurazione supportate per CMON utilizzando il comando seguente:

$ cmon --help-config

Pensieri finali

Il monitoraggio senza agenti è diventato uno dei metodi più efficaci per la gestione di infrastrutture di database sempre più complesse. Riduce il carico di molte sfide associate al monitoraggio del database ed è facile da gestire.

Oggi sono disponibili molti strumenti di monitoraggio senza agenti. Tuttavia, non molti di essi offrono anche una piattaforma completa ricca di funzionalità per aiutarti a gestire ogni altro aspetto dei tuoi cluster di database. Per vedere cos'altro può fare ClusterControl, assicurati di scaricare la tua versione di prova gratuita di 30 giorni.

Stai cercando un'alternativa basata su agenti al monitoraggio del database? Dai un'occhiata all'infrastruttura di monitoraggio del database basata su agenti di ClusterControl:SCUMM.