Chi gestisce server 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 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, senza installare agent o aprire dashboard web.

MySQL Monitor è uno script bash open source, pubblicato su GitHub da Hayden James, che riempie esattamente questo 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’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, 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. Repository del progetto: github.com/haydenjames/mysqlmonitor-script.