Banche dati
    Aggiornato il maggio 2026
    MySQL logo

    MySQL Monitoraggio

    Monitora in tempo reale le prestazioni delle query MySQL, lo stato della replica, i pool di connessioni e le metriche di archiviazione senza alcuna configurazione.

    Perché monitorare MySQL?

    MySQL è il database relazionale open source più diffuso al mondo, utilizzato da milioni di applicazioni, dalle startup alle aziende Fortune 500. Il monitoraggio di MySQL è fondamentale per individuare le query lente, evitare l'esaurimento del pool di connessioni, tenere sotto controllo il ritardo di replica e ottimizzare l'utilizzo dello spazio di archiviazione. L'integrazione di MySQL offerta da Xitoring garantisce una visibilità approfondita sulle prestazioni del database.

    Rilevamento automatico tramite Xitogent — nessuna configurazione manuale richiesta
    Throughput delle query in tempo reale e metriche di performance
    Monitoraggio dell'utilizzo del pool di connessioni e degli stati dei thread
    Monitoraggio del lag di replica e dello stato degli slave
    Metriche del buffer pool InnoDB e del motore di storage
    Rilevamento e monitoraggio delle query lente
    Funziona sia su server Linux che Windows
    Intervalli di raccolta metriche di 1 minuto
    Cos'è il monitoraggio di MySQL?

    Monitoraggio di MySQL, spiegato

    Il monitoraggio di MySQL intercetta churn del buffer pool, query lente, drift di replicazione e saturazione dei thread di connessione prima che rallentino ogni lettura nell'app o sfocino in una tempesta di failover sulle repliche. Per WordPress, Laravel, Magento e qualsiasi workload basato su RDS/Aurora, la visibilità per database è il segnale singolo più utile fra rallentamenti segnalati dagli utenti e la causa principale. Xitoring rileva automaticamente MySQL, interroga performance_schema e le viste di stato standard, e instrada le allerte su Slack, PagerDuty, Telegram o sul Suo sistema di on-call esistente.

    Indicatori

    Ciò che monitoriamo

    Query al secondo

    Tasso di query SELECT, INSERT, UPDATE e DELETE.

    Connessioni attive

    Numero di connessioni attualmente attive a MySQL.

    Query lente

    Conteggio delle query che superano la soglia di slow query.

    Lag della replica

    Secondi di ritardo rispetto al master nella replica.

    Buffer pool InnoDB

    Utilizzo del buffer pool e rapporto di hit.

    Stati dei thread

    Distribuzione degli stati dei thread (running, sleeping, locked).

    Lock di tabella

    Tasso di attese e acquisizioni immediate di lock di tabella.

    Tabelle temporanee

    Tasso di tabelle temporanee create su disco.

    Byte inviati/ricevuti

    Throughput di rete da e verso MySQL.

    Connessioni abortite

    Tentativi di connessione falliti e client abortiti.

    Open_tables vs table_open_cache

    Handle di tabelle attualmente aperti rispetto alla dimensione di cache configurata. Quando Open_tables si avvicina al limite della cache, MySQL effettua eviction e riapertura — con un costo misurabile in latenza.

    Innodb_os_log_pending_fsyncs

    Fsync in attesa verso il redo log InnoDB. Valori sostenuti non-zero indicano che le impostazioni `sync_binlog`/`innodb_flush_log_at_trx_commit` sono in bottleneck sul disco.

    Notifiche e avvisi

    Configurabile condizioni di attivazione

    Imposta dei trigger personalizzati nella tua dashboard per ricevere una notifica non appena le metriche dell{name}e superano le soglie da te definite.

    MySQL pannello di controllo per la configurazione dei trigger di monitoraggio

    Connessioni attive

    critico

    Si attiva quando le connessioni attive si avvicinano a max_connections, rischiando il rifiuto di nuove connessioni ed errori applicativi.

    Lag della replica

    critico

    Si attiva quando la replica resta indietro, rischiando incoerenza dei dati tra master e replica.

    Query lente

    avviso

    Avvisa quando il conteggio delle query lente supera la soglia, indicando degrado delle prestazioni.

    Buffer pool InnoDB

    avviso

    Si attiva quando il rapporto di hit del buffer pool scende, indicando un'eccessiva I/O disco.

    Connessioni abortite

    avviso

    Si attiva su picchi di fallimenti di connessione, indicando problemi di autenticazione o di rete.

    Attese di lock di tabella

    critico

    Avvisa quando la contesa di lock aumenta, degradando le prestazioni delle query.

    01

    Importanza del monitoraggio MySQL

    MySQL gestisce dati critici per milioni di applicazioni. Senza un monitoraggio adeguato, query lente, drift di replica ed esaurimento delle connessioni possono portare a interruzioni e incoerenza dei dati.

    • Rileva query lente prima che impattino sull'esperienza utente
    • Previeni l'esaurimento del pool di connessioni con avvisi a soglia
    • Monitora la replica per la coerenza dei dati tra le repliche
    • Tieni traccia delle prestazioni InnoDB per una salute ottimale del motore di storage
    • Identifica in anticipo la contesa di lock e i colli di bottiglia delle query
    Dashboard di monitoraggio MySQL con metriche delle query
    Timeline degli avvisi di prestazioni del database
    02

    Perché scegliere Xitoring

    Xitoring offre un monitoraggio MySQL di livello enterprise con configurazione zero-config. Il nostro agente leggero rileva automaticamente le tue istanze MySQL, inizia a raccogliere metriche in meno di 60 secondi e si integra con i tuoi canali di notifica esistenti.

    • Installazione con un solo comando — niente YAML o file di configurazione complessi
    • Oltre 15 nodi di monitoraggio globali per controlli a bassa latenza
    • Dashboard unificata per server, database e uptime
    • Alerting flessibile tramite Slack, PagerDuty, Telegram e altri
    • Conservazione dei dati storici per pianificazione della capacità e audit
    Panoramica multi-database di Xitoring
    Canali di notifica e configurazione degli avvisi
    Casi d'uso

    Scenari comuni di monitoraggio MySQL

    Dove MySQL viene tipicamente eseguito oggi — e cosa potrebbe andare storto se nessuno lo monitora.

    Database cloud gestito (AWS, Azure, Google)

    I fornitori di servizi cloud gestiscono i server, ma non ti dicono quando le tue query sono lente, le tue connessioni si stanno esaurendo, o una copia di backup sta silenziosamente rimanendo indietro. Rileviamo i problemi che il fornitore lascia a te, in modo che un rallentamento non colga il team alla sprovvista.

    Database principale con copie di backup live

    I database di produzione eseguono tipicamente un backup live pronto a subentrare in caso di guasto del principale. Quando quel backup rimane silenziosamente indietro, quella che dovrebbe essere una transizione fluida diventa un'interruzione reale — a volte con perdita di dati. Monitoriamo ogni copia in modo che il backup sia veramente pronto quando ne hai bisogno.

    Database in esecuzione all'interno di Kubernetes

    I database in Kubernetes vengono spostati, riavviati e aggiornati automaticamente dalla piattaforma. La maggior parte delle volte è sicuro — quando non lo è, di solito lo scopri dagli utenti frustrati. Rileviamo i primi segnali di avvertimento in modo che il team possa intervenire prima che un aggiornamento di routine diventi un incidente.

    Prima di iniziare

    Prerequisiti per MySQL

    Assicurati di avere tutto questo in posizione — la maggior parte delle installazioni dura 60 secondi una volta soddisfatte le condizioni.

    • MySQL 5.7 o 8.x in esecuzione sul server
    • performance_schema = ON (predefinito da 5.7+, impostalo in [mysqld] se disabilitato)
    • Un utente di monitoraggio con PROCESS, REPLICATION CLIENT e SELECT su performance_schema
    Guida all'installazione

    Inizia con verbali

    1

    Installa Xitogent sul tuo server

    Se non l'hai già fatto, installa il leggero agente di monitoraggio Xitogent sul tuo server.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Crea un utente di monitoraggio in MySQL

    Crea un utente dedicato in sola lettura affinché Xitogent raccolga le metriche:

    CREATE USER 'xitoring'@'%' IDENTIFIED BY 'your_secure_password'; GRANT REPLICATION CLIENT ON *.* TO 'xitoring'@'%' WITH MAX_USER_CONNECTIONS 5; GRANT PROCESS ON *.* TO 'xitoring'@'%'; GRANT SELECT ON performance_schema.* TO 'xitoring'@'%'; FLUSH PRIVILEGES;
    3

    Abilita l'integrazione MySQL

    Usa la dashboard di Xitoring o la CLI per abilitare l'integrazione MySQL con le credenziali di monitoraggio.

    sudo xitogent integrate
    4

    Configura le soglie di allerta (opzionale)

    Imposta soglie personalizzate per metriche come Replication Lag, slow query o numero di connessioni per essere avvisato quando qualcosa richiede attenzione.

    5

    Verifica che funzioni

    Esegui questo comando sul server per confermare che Xitogent ha rilevato l'integrazione. In circa 30 secondi nuove metriche cominceranno a comparire sulla tua dashboard.

    sudo xitogent status

    Spesso domande poste

    Di quali autorizzazioni ha bisogno l'utente addetto al monitoraggio?
    L'utente addetto al monitoraggio deve disporre dei privilegi PROCESS, REPLICATION CLIENT e SELECT. Si tratta di autorizzazioni in sola lettura che consentono a Xitogent di raccogliere metriche sulle prestazioni senza modificare alcun dato.
    Questa integrazione influirà sulle prestazioni di MySQL?
    No. Xitogent utilizza query leggere e di sola lettura per raccogliere le metriche. Il carico di monitoraggio è trascurabile e non influirà sulle prestazioni del database.
    Posso monitorare la replica di MySQL?
    Sì. L'integrazione monitora il ritardo di replica, lo stato dello slave e gli errori di replica. Riceverai immediatamente un avviso se le tue repliche accumulano un ritardo.
    Funziona con MySQL su RDS o con i database cloud?
    L'integrazione è pensata per le istanze MySQL in proprio su cui è installato Xitogent. Per i database gestiti nel cloud, consulta le nostre funzionalità di monitoraggio tramite API.
    Quali versioni di MySQL sono supportate?
    Xitoring supporta MySQL 5.7 e versioni successive, compreso MySQL 8.x. MariaDB è supportato tramite un'integrazione separata.
    Con quale frequenza vengono raccolti i dati?
    Per impostazione predefinita, i dati vengono raccolti a intervalli di 1 minuto. È possibile modificare questa impostazione tramite la dashboard di Xitoring o la CLI.
    Qual è la differenza tra monitoraggio MySQL e MariaDB?
    Il vocabolario core dell'engine (`Threads_connected`, `Innodb_buffer_pool_*`, `Slow_queries` ecc.) è condiviso. MariaDB diverge in: (1) il monitoraggio dei cluster Galera usa il namespace `wsrep_*` (cluster size, flow control, stato donor/joiner) — del tutto assente in MySQL vanilla; (2) strumenti come MariaDB MaxScale e ClusterControl; (3) gli engine ColumnStore e Spider; (4) il formato GTID di replicazione differisce. Usi questa integrazione MySQL per MySQL/RDS/Aurora; usi l'integrazione MariaDB dedicata per MariaDB e cluster Galera.
    Questa integrazione influisce sulle prestazioni di MySQL?
    Nessun impatto misurabile. Xitogent usa query leggere e in sola lettura contro `performance_schema` e `SHOW GLOBAL STATUS` — lo stesso meccanismo usato dagli strumenti propri di MySQL. L'utente di monitoring è limitato a `MAX_USER_CONNECTIONS 5` così l'agent non può mai esaurire il connection pool. Il polling a intervalli di 60 secondi aggiunge un carico CPU trascurabile.
    Quali versioni di MySQL sono supportate?
    MySQL 5.7, MySQL 8.0 (tramonto in arrivo), MySQL 8.4 LTS (attuale) e l'innovation track 9.x. L'integrazione rileva automaticamente se chiamare `SHOW REPLICA STATUS` (8.0+) o `SHOW SLAVE STATUS` (legacy) e quali tabelle `performance_schema` sono presenti. Per MariaDB o cluster Galera usi invece l'integrazione MariaDB dedicata.

    Inizia a monitorare MySQL oggi

    Configurazione in meno di 60 secondi. Non è richiesta alcuna carta di credito. Statistiche complete fin dal primo giorno.

    Inizia la prova gratuita

    Continua a esplorare

    Correlati Integrazioni