Bases de dados
    Atualizado maio de 2026
    MySQL logo

    MySQL Monitorização

    Monitorize o desempenho das consultas MySQL, o estado da replicação, os conjuntos de ligações e as métricas de armazenamento em tempo real, sem necessidade de configuração.

    Por que monitorizar MySQL?

    O MySQL é a base de dados relacional de código aberto mais popular do mundo, estando na base de milhões de aplicações, desde startups até empresas da Fortune 500. A monitorização do MySQL é essencial para detetar consultas lentas, evitar o esgotamento do conjunto de ligações, acompanhar o atraso na replicação e otimizar a utilização do armazenamento. A integração do MySQL com o Xitoring proporciona uma visibilidade aprofundada do desempenho da sua base de dados.

    Deteção automática via Xitogent — sem configuração manual necessária
    Throughput de consultas em tempo real e métricas de desempenho
    Acompanhamento da utilização do pool de ligações e estados das threads
    Monitorização do lag de replicação e estado dos slaves
    Métricas do buffer pool InnoDB e do motor de armazenamento
    Deteção e monitorização de consultas lentas
    Funciona em servidores Linux e Windows
    Intervalos de recolha de métricas de 1 minuto
    O que é a monitorização do MySQL?

    Monitorização do MySQL, explicada

    A monitorização do MySQL deteta churn no buffer pool, consultas lentas, deriva de replicação e saturação de threads de ligação antes que abrandem cada leitura na sua aplicação ou se transformem numa tempestade de failover de réplica. Para WordPress, Laravel, Magento e qualquer carga assente em RDS/Aurora, a visibilidade por base de dados é o sinal mais útil entre a lentidão reportada pelos utilizadores e a causa raiz. O Xitoring deteta automaticamente o seu MySQL, consulta o performance_schema e as vistas de estado padrão e encaminha alertas para Slack, PagerDuty, Telegram ou o seu sistema on-call existente.

    Métricas

    O que monitorizamos

    Consultas por segundo

    Taxa de consultas SELECT, INSERT, UPDATE e DELETE.

    Ligações ativas

    Número de ligações atualmente ativas para o MySQL.

    Consultas lentas

    Contagem de consultas que excedem o limite de slow query.

    Lag de replicação

    Segundos de atraso face ao master na replicação.

    Buffer pool InnoDB

    Utilização do buffer pool e rácio de hit.

    Estados das threads

    Distribuição dos estados das threads (running, sleeping, locked).

    Locks de tabela

    Taxa de esperas e aquisições imediatas de locks de tabela.

    Tabelas temporárias

    Taxa de tabelas temporárias criadas em disco.

    Bytes enviados/recebidos

    Throughput de rede de e para MySQL.

    Ligações abortadas

    Tentativas de ligação falhadas e clientes abortados.

    Open_tables vs table_open_cache

    Handles de tabelas atualmente abertos vs tamanho da cache configurado. Quando Open_tables se aproxima do limite da cache, o MySQL evicta e reabre — com um custo mensurável de latência.

    Innodb_os_log_pending_fsyncs

    Fsyncs pendentes ao redo log do InnoDB. Valores sustentadamente não-zero significam que as suas definições `sync_binlog`/`innodb_flush_log_at_trx_commit` estão estranguladas no disco.

    Alerta e notificação

    Configurável condições de alerta

    Configure alertas personalizados no seu painel para ser notificado assim que as métricas dMySQL ultrapassarem os limites que definiu.

    MySQL painel de controlo da configuração dos gatilhos de monitorização

    Ligações ativas

    crítico

    Dispara quando as ligações ativas se aproximam de max_connections, arriscando recusa de novas ligações e erros aplicacionais.

    Lag de replicação

    crítico

    Dispara quando a replicação fica para trás, arriscando inconsistência de dados entre master e replicas.

    Consultas lentas

    aviso

    Alerta quando a contagem de consultas lentas excede o limite, indicando degradação de desempenho.

    Buffer pool InnoDB

    aviso

    Dispara quando o rácio de hit do buffer pool cai, indicando E/S de disco excessiva.

    Ligações abortadas

    aviso

    Dispara em picos de falhas de ligação, indicando problemas de autenticação ou de rede.

    Esperas de locks de tabela

    crítico

    Alerta quando a contenção de locks aumenta, degradando o desempenho das consultas.

    01

    Importância da monitorização do MySQL

    O MySQL lida com dados críticos para milhões de aplicações. Sem monitorização adequada, consultas lentas, drift de replicação e esgotamento de ligações podem levar a interrupções e inconsistência de dados.

    • Detete consultas lentas antes que afetem a experiência do utilizador
    • Evite o esgotamento do pool de ligações com alertas por limite
    • Monitorize a replicação para a consistência de dados entre replicas
    • Acompanhe o desempenho InnoDB para uma saúde ótima do motor de armazenamento
    • Identifique cedo a contenção de locks e estrangulamentos de consultas
    Dashboard de monitorização MySQL com métricas de consultas
    Cronologia de alertas de desempenho de base de dados
    02

    Porquê escolher Xitoring

    O Xitoring oferece monitorização MySQL de nível empresarial com configuração zero-config. O nosso agente leve deteta automaticamente as suas instâncias MySQL, começa a recolher métricas em menos de 60 segundos e integra-se com os seus canais de notificação existentes.

    • Instalação num único comando — sem YAML complexo nem ficheiros de configuração
    • Mais de 15 nós de monitorização globais para verificações de baixa latência
    • Dashboard unificado para servidores, bases de dados e uptime
    • Alertas flexíveis via Slack, PagerDuty, Telegram e outros
    • Retenção de dados históricos para planeamento de capacidade e auditorias
    Visão geral multi-base de dados do Xitoring
    Canais de notificação e configuração de alertas
    Casos de uso

    Cenários comuns de monitorização do MySQL

    Onde o MySQL normalmente é executado hoje — e o que pode correr mal se ninguém estiver a monitorizar.

    Base de dados cloud gerida (AWS, Azure, Google)

    Os fornecedores de cloud gerem os servidores, mas não lhe dizem quando as suas próprias consultas estão lentas, as suas conexões estão a esgotar-se, ou uma cópia de segurança está silenciosamente a ficar atrasada. Nós detetamos os problemas que o fornecedor deixa para si, para que um abrandamento não apanhe a equipa desprevenida.

    Base de dados principal com cópias de segurança em tempo real

    As bases de dados de produção normalmente executam um backup em tempo real pronto para assumir se o principal falhar. Quando esse backup fica silenciosamente atrasado, o que deveria ser uma transição suave torna-se uma interrupção real — por vezes com perda de dados. Nós monitorizamos cada cópia para que o backup esteja verdadeiramente pronto quando precisar dele.

    Base de dados a correr dentro do Kubernetes

    As bases de dados no Kubernetes são movidas, reiniciadas e atualizadas pela plataforma automaticamente. Na maioria das vezes é seguro — quando não é, normalmente descobre através de utilizadores frustrados. Nós detetamos os sinais de alerta precoce para que a equipa possa intervir antes que uma atualização de rotina se torne um incidente.

    Antes de começar

    Pré-requisitos para MySQL

    Certifique-se de que tem tudo isto pronto — depois disso, a maioria das instalações leva 60 segundos.

    • MySQL 5.7 ou 8.x em execução no servidor
    • performance_schema = ON (predefinido a partir de 5.7+; defina em [mysqld] se desativado)
    • Um utilizador de monitorização com PROCESS, REPLICATION CLIENT e SELECT em performance_schema
    Guia de configuração

    Comece a minutos

    1

    Instalar o Xitogent no seu servidor

    Se ainda não o fez, instale o leve agente de monitorização Xitogent no seu servidor.

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

    Criar um utilizador de monitorização no MySQL

    Crie um utilizador dedicado só de leitura para que o Xitogent recolha as métricas:

    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

    Ativar a integração do MySQL

    Use o painel do Xitoring ou a CLI para ativar a integração do MySQL com as credenciais de monitorização.

    sudo xitogent integrate
    4

    Configurar limiares de alerta (opcional)

    Defina limiares personalizados para métricas como atraso de replicação, queries lentas ou número de ligações para ser notificado quando algo merecer atenção.

    5

    Confirme que está a funcionar

    Execute este comando no servidor para confirmar que o Xitogent detetou a integração. Em cerca de 30 segundos começam a chegar novas métricas ao seu painel.

    sudo xitogent status

    Frequentemente perguntas feitas

    De que permissões necessita o utilizador responsável pela monitorização?
    O utilizador responsável pela monitorização necessita dos privilégios PROCESS, REPLICATION CLIENT e SELECT. Trata-se de permissões de leitura que permitem à Xitogent recolher métricas de desempenho sem alterar quaisquer dados.
    Esta integração afetará o desempenho do MySQL?
    Não. O Xitogent utiliza consultas leves e de leitura apenas para recolher métricas. A sobrecarga de monitorização é insignificante e não afetará o desempenho da sua base de dados.
    Posso monitorizar a replicação do MySQL?
    Sim. A integração monitoriza o atraso na replicação, o estado dos servidores escravos e os erros de replicação. Será alertado imediatamente caso as suas réplicas fiquem atrasadas.
    Isto funciona com o MySQL no RDS ou em bases de dados na nuvem?
    A integração foi concebida para instâncias MySQL auto-hospedadas nas quais o Xitogent está instalado. Para bases de dados geridas na nuvem, consulte as nossas funcionalidades de monitorização por API.
    Quais são as versões do MySQL suportadas?
    Xitoring é compatível com o MySQL 5.7 e versões posteriores, incluindo o MySQL 8.x. O MariaDB é suportado através de uma integração separada.
    Com que frequência são recolhidos os indicadores?
    Por predefinição, as métricas são recolhidas a intervalos de 1 minuto. Esta configuração pode ser ajustada através do painel de controlo do Xitoring ou da CLI.
    Qual a diferença entre a monitorização do MySQL e do MariaDB?
    O vocabulário central do motor (`Threads_connected`, `Innodb_buffer_pool_*`, `Slow_queries`, etc.) é partilhado. O MariaDB diverge em: (1) a monitorização do cluster Galera usa o namespace `wsrep_*` (tamanho do cluster, flow control, estado donor/joiner) — completamente ausente no MySQL puro; (2) ferramentas como MariaDB MaxScale e ClusterControl; (3) motores ColumnStore e Spider; (4) o formato de GTID na replicação difere. Use esta integração MySQL para MySQL/RDS/Aurora; use a integração dedicada do MariaDB para MariaDB e clusters Galera.
    Esta integração vai afetar o desempenho do MySQL?
    Sem impacto mensurável. O Xitogent usa consultas leves e só de leitura contra o `performance_schema` e `SHOW GLOBAL STATUS` — o mesmo mecanismo que as próprias ferramentas do MySQL usam. O utilizador de monitorização está limitado com `MAX_USER_CONNECTIONS 5` para que o agente nunca possa esgotar o pool de ligações. O polling em intervalos de 60 segundos acrescenta uma carga de CPU negligenciável.
    Que versões do MySQL são suportadas?
    MySQL 5.7, MySQL 8.0 (descontinuação a aproximar-se), MySQL 8.4 LTS (atual) e a linha de inovação 9.x. A integração deteta automaticamente se `SHOW REPLICA STATUS` (8.0+) ou `SHOW SLAVE STATUS` (legado) é a chamada correta e quais as tabelas do `performance_schema` presentes. Para MariaDB ou clusters Galera, use antes a integração dedicada do MariaDB.

    Comece a monitorizar MySQL hoje

    Configure em menos de 60 segundos. Não é necessário cartão de crédito. Estatísticas completas desde o primeiro dia.

    Iniciar período de avaliação gratuita

    Continue a explorar

    Relacionado Integrações