Chi gestisce server [MySQL](https://spcnet.it/tag/mysql/) o MariaDB in produzione conosce bene il problema: `SHOW GLOBAL STATUS` e `SHOW ENGINE INNODB STATUS` restituiscono decine di contatori grezzi, ma trasformarli in un quadro leggibile della [salute](https://spcnet.it/tag/salute/) del database richiede script, query a mano e un po’ di esperienza. Strumenti come Percona Monitoring and Management o Datadog fanno un ottimo lavoro, ma spesso sono sovradimensionati per chi vuole solo un colpo d’occhio rapido via [SSH](https://spcnet.it/tag/ssh/), senza installare agent o aprire dashboard [web](https://spcnet.it/tag/web/). **MySQL Monitor** è uno script [bash](https://spcnet.it/tag/bash/) [open source](https://spcnet.it/tag/open-source/), pubblicato su [GitHub](https://spcnet.it/tag/github/) da Hayden James, che riempie esattamente questo [spazio](https://spcnet.it/tag/spazio/): un top-like da terminale, dipendente solo da `awk` e dai client MySQL standard, pensato per dare in pochi secondi una diagnosi dello stato del server. Cos’è e perché è utile ai sistemisti ------------------------------------ A differenza di una semplice dashboard di contatori, MySQL Monitor calcola i **tassi al secondo** tra un refresh e l’altro (query al secondo, lock al secondo, scritture nel redo log…), mostra uno **sparkline** [dell](https://spcnet.it/tag/dell/)’ultimo minuto per i valori chiave e confronta tutto con la **media dall’avvio** del server. Questo terzo punto di vista è importante: un valore che sembra alto nell’ultimo minuto può essere perfettamente normale se è sempre stato così dal boot, o essere il sintomo di una regressione se si allontana dalla baseline storica. Ogni riga del dashboard è marcata con un simbolo di stato (✓, ⚠, ✗) e solo i valori fuori soglia vengono evidenziati in grassetto colorato, per non costringere l’occhio a scansionare trenta numeri per trovare il problema. Un riquadro di alert riepiloga le anomalie rilevate indicando direttamente quale parametro di configurazione andrebbe rivisto. Il layout si adatta alla larghezza del terminale (da una a tre colonne), con una modalità compatta per terminali 80×24, utile su connessioni SSH datate o console seriali. Installazione e primo avvio --------------------------- Lo script non richiede installazione: si scarica ed esegue in due comandi. ``` curl -O https://raw.githubusercontent.com/haydenjames/mysqlmonitor-script/main/mysqlmonitor.sh chmod +x mysqlmonitor.sh ./mysqlmonitor.sh ``` Per l’autenticazione ci sono due strade: eseguirlo come utente `root` di sistema (che in molte distribuzioni ha accesso MySQL via socket Unix), oppure, più correttamente in produzione, creare un file `~/.my.cnf` con le credenziali nella sezione `[client]`: ``` [client] user=monitor_user password=una_password_sicura ``` Il file va protetto con permessi restrittivi, altrimenti MySQL (e lo stesso buon senso) si lamenterà: ``` chmod 600 ~/.my.cnf ``` Da notare che lo script non accetta la password come argomento da riga di comando: una scelta corretta dal punto di vista della [sicurezza](https://spcnet.it/category/sicurezza/), perché evita che la password finisca nella `history` della shell o nell’output di `ps aux` visibile ad altri utenti del sistema. Per cambiare la frequenza di refresh (il default è pensato per un uso interattivo comodo) basta passare i secondi come argomento: ``` ./mysqlmonitor.sh 1 ``` Ed è disponibile anche una modalità **snapshot singolo**, pensata esplicitamente per l’uso non interattivo via cron o in script di raccolta diagnostica lanciati da SSH: ``` ./mysqlmonitor.sh --once ``` Questa modalità è particolarmente comoda per allegare automaticamente lo stato del database a un ticket di incident, o per salvare uno snapshot “prima/dopo” quando si applica una modifica ai parametri di configurazione. Cosa monitora davvero --------------------- Il valore dello strumento sta nella scelta delle metriche, che coprono i punti dove più spesso si annidano i problemi di performance su MySQL/MariaDB: - **InnoDB buffer pool**: dimensione, pagine libere, attese per pagine libere e hit ratio — se l’hit ratio scende sotto il 99%, è quasi sempre il segnale che il buffer pool è troppo piccolo rispetto al working set dei dati. - **Redo log e row lock**: attese sul log buffer, byte scritti nel redo log con una stima delle ore di scrittura che il log corrente può contenere, e attese sui lock di riga — utili per individuare contention su transazioni concorrenti. - **Connessioni**: thread connessi e in esecuzione, connessioni rifiutate per il raggiungimento di `max_connections`, client abortiti. - **Query**: query al secondo (QPS), percentuale di slow query, scansioni complete di tabella (`Select_scan`) e join senza indice (`Select_full_join`) — due dei principali indicatori di query che andrebbero riscritte o che mancano di un indice. - **Tabelle e cache**: hit ratio di table cache e thread cache, tabelle temporanee create su disco (sintomo classico di `tmp_table_size` troppo basso o di query con `GROUP BY`/`ORDER BY` su grandi dataset). - **Sistema**: CPU, load average a 1/5/15 minuti, memoria disponibile, swap in uso — perché un problema “MySQL” è spesso, in realtà, un problema di risorse del sistema operativo che lo ospita. Le viste interattive -------------------- Una volta avviato, lo script si naviga con pochi tasti, sullo stile di `htop`: - `h` — **health check**: più di venti controlli automatici raggruppati per area (InnoDB, connessioni, tabelle, query, sistema). Per ogni controllo fallito, lo script indica il parametro di configurazione da modificare e un valore suggerito — ad esempio, se `table_open_cache` è al limite, può suggerire qualcosa come “`table_open_cache = 4000, Open_tables = 4000. Try 8000.`“, risparmiando una ricerca su internet per capire quale parametro toccare. - `t` — **top query**: statistiche aggregate per pattern di statement, ottenute da `performance_schema`: chiamate al secondo, tempo medio e massimo, quota percentuale sul tempo totale, righe esaminate per riga restituita, ed evidenzia gli statement che usano tabelle temporanee su disco o non sfruttano indici. Su un server con un paio di migliaia di query al secondo, questa vista permette di isolare in pochi secondi le decine di pattern che assorbono la maggior parte del tempo macchina. - `p` — lista processi, con possibilità di ordinare (`o`), filtrare (`f`), mostrare le connessioni in sleep (`s`) e terminare una query specifica (`k`, con conferma). - `r` — la vista classica a contatori, `d` per i dettagli, `space` per pausa/ripresa, `+`/`-` per cambiare l’intervallo di refresh. Requisiti e un paio di accortezze --------------------------------- Lo script richiede MySQL 5.7, MySQL 8.0 o MariaDB, una qualsiasi implementazione di `awk` (gawk, mawk o la variante busybox) e un utente con privilegi di lettura sufficienti. Per la vista “top query” serve inoltre il permesso `SELECT` sul `performance_schema`: su MySQL è attivo di default dalla 5.7, mentre su MariaDB va abilitato esplicitamente impostando `performance_schema = ON` in `my.cnf` e riavviando il servizio — un dettaglio da non sottovalutare se si gestisce un parco di istanze MariaDB legacy. Vale anche la pena ricordare che le statistiche “dall’avvio” diventano statisticamente significative solo dopo circa 24 ore di uptime continuo: su un server riavviato di recente, quei numeri vanno letti con cautela. Dove si colloca rispetto ad altri strumenti ------------------------------------------- MySQL Monitor non vuole competere con suite di observability complete come Percona Monitoring and Management, Prometheus con `mysqld_exporter` o le dashboard gestite dei provider cloud: non fa storicizzazione dei dati, non genera alert via email/Slack, non produce grafici persistenti. Il suo punto di forza è l’assenza totale di dipendenze e setup: un singolo file bash, nessun agent da installare, nessun database di metriche da mantenere. È lo strumento giusto per il primo accesso a un server in crisi, per una verifica rapida durante un cambio di configurazione, o per chi amministra pochi server MySQL e non vuole il peso operativo di una suite di monitoring dedicata. Conclusione ----------- Per chi lavora quotidianamente da terminale su server Linux con MySQL o MariaDB, MySQL Monitor è uno di quegli strumenti “a costo zero” che vale la pena avere pronti in una cartella `~/bin` o in un repository di script operativi condivisi col team. Non sostituisce un sistema di monitoring strutturato, ma riduce drasticamente il tempo necessario per rispondere alla domanda più comune in un incident: “cosa sta succedendo a questo database, adesso?”. *Fonte originale: [LinuxBlog.io – MySQL Monitor: MySQL Monitoring Script](https://linuxblog.io/mysql-monitor-script/). Repository del progetto: [github.com/haydenjames/mysqlmonitor-script](https://github.com/haydenjames/mysqlmonitor-script).*