O 10-Strike Network Monitor monitora bancos MS SQL, MySQL e ODBC na rede.

As verificações “MS SQL Server”, “MySQL” e “ODBC” acompanham o estado do SGBD correspondente e alertam quando detectam falhas. O algoritmo tenta conectar aos bancos, periodicamente, com os parâmetros de autenticação informados. Se o SGBD devolve conexão bem-sucedida, a verificação é aprovada.
Além disso, o programa executa consultas SQL arbitrárias, obtém os resultados e analisa os valores devolvidos.
A biblioteca cliente libmySQL.dll é necessária para a verificação “MySQL”. Uma versão dela vem com o programa. Pode ficar na pasta do Windows ou na pasta do programa.
Para a verificação “MS SQL Server”, o computador precisa da parte cliente desse SGBD. O programa aceita autenticação do Windows e autenticação própria, com login e senha.
Como configurar o monitoramento do banco (exemplo MySQL)
O monitoramento da saúde do banco mantém o desempenho e a disponibilidade. Inclui o controle de muitos parâmetros e métricas do SGBD, e a detecção de erros de operação.
Abaixo, algumas métricas básicas para avaliar o estado do banco, com o 10-Strike Network Monitor e o MySQL como exemplo.
1. Disponibilidade e uptime
A disponibilidade do banco é conferida com uma conexão a partir de hosts remotos. Um erro de conexão pode indicar que o serviço do banco parou, ou que a porta foi bloqueada por outro programa.
O parâmetro uptime revela reinícios rápidos do banco. Esses reinícios podem passar pela verificação de disponibilidade, então vale conferir há quanto tempo o banco roda sem falhas nem desligamentos. Por exemplo, o limite de alerta pode ser
uptime < 1800
em que 1800 é o uptime do banco, em segundos, desde a última execução.
2. Erros de conexão
Um problema possível é o erro de conexão de clientes novos. A métrica Number of Connection Errors mostra quando o banco gera esses erros com frequência demais. Ela inclui estas variáveis de estado do servidor MySQL (contadores):
- Connection_errors_accept
Número de erros nas chamadas accept() na porta de escuta. - Connection_errors_internal
Número de conexões recusadas por erros internos do servidor, como falha ao iniciar uma thread nova ou falta de memória. - Connection_errors_max_connections
Número de conexões recusadas porque o limite max_connections do servidor foi atingido. - Connection_errors_peer_address
Número de erros ao resolver os endereços IP dos clientes que conectam. - Connection_errors_select
Número de erros nas chamadas select() ou poll() na porta de escuta (a falha dessa operação não significa, necessariamente, que a conexão do cliente foi recusada). - Connection_errors_tcpwrap
Número de conexões recusadas pelo libwrap.
Se o parâmetro max_connections estiver mal configurado no servidor MySQL, o banco pode falhar com muitas conexões simultâneas, e o contador Connection_errors_max_connections sobe. Dá para evitar isso monitorando a relação entre as conexões atuais e o máximo possível. Use esta consulta:
SELECT ROUND(100 - (100 * Variable_value / [max_connections]), 0) as tc FROM sys.metrics where Variable_name = 'threads_connected'
no lugar de [max_connections], coloque o valor real do parâmetro max_connections (o padrão é 100). Ele sai com uma consulta na console do MySQL:
show variables like "max_connections";
Este comando devolve algo parecido com isto:
A variável tc da consulta mostra a porcentagem de conexões disponíveis, e o limite pode ser 30%.
3. Consultas lentas
O MySQL mantém um log de consultas lentas. A quantidade de entradas sai da métrica slow_queries. O valor vem de uma consulta SQL simples:
SELECT Variable_value FROM sys.metrics where Variable_name = 'slow_queries'
O programa pode reagir a mudanças nesse valor e avisar sobre entradas novas no log de consultas lentas, o que pode indicar problemas de desempenho.
4. Consultas com join
Com os contadores de execução de joins, as operações que consomem recursos demais geram aviso.
- Select_full_join
Número de joins que varrem a tabela porque não usam índices. Se o valor não for 0, confira os índices das tabelas com atenção. - Select_full_range_join
Número de joins que usaram busca por intervalo na tabela de consulta. - Select_range_check
Número de joins sem chaves que verificam o uso de chave depois de cada linha. Se não for 0, confira os índices das tabelas com atenção. - Select_scan
Número de joins que fizeram varredura completa na primeira tabela. - Select_range
Número de joins que usaram intervalos na primeira tabela. Em geral não é crítico, mesmo se o valor for alto.
5. Taxa de acerto do cache
O MySQL usa um cache em memória para otimizar leituras e gravações em disco. Uma Cache Hit Rate baixa afeta o desempenho do banco. Esta consulta calcula a taxa de acerto do cache de tabelas abertas:
SELECT ROUND((open_cache_hits / (open_cache_hits + open_cache_misses)), 2) * 100 OpenTableFactor FROM (SELECT variable_value open_cache_misses FROM sys.metrics WHERE variable_name = 'table_open_cache_misses') miss, (SELECT variable_value open_cache_hits FROM sys.metrics WHERE variable_name = 'table_open_cache_hits') hits;
Defina o limite de OpenTableFactor em 90%. Se o valor ficar abaixo, o programa avisa.
6. Tempo de execução da consulta
Outro indicador de queda de desempenho é o tempo de execução da consulta. Escreva uma consulta SQL de teste e meça o tempo em condições normais. Esse valor serve de limite para o teste. Um tempo alto por um período longo pode indicar que o banco está muito carregado, e os usuários esperam demais pela resposta.
O MySQL tem muitas métricas para avaliar a saúde do banco. A maior parte está nas tabelas de sistema INFORMATION_SCHEMA (sys). As tabelas e views desse esquema podem ser consultadas. O programa executa consultas arbitrárias, e com isso dá para montar uma faixa ampla de verificações de desempenho do banco.
Monitoramento de outros bancos
Ninguém sabe de antemão o efeito de uma falha de SGBD para a empresa. Mas ela acontece. Se o banco fica indisponível, quanto mais rápida a restauração, menores as perdas. Por isso é importante saber das falhas do banco e da natureza delas a tempo.
O monitoramento do banco SQL fica no 10-Strike Network Monitor. Inclua a verificação "MySQL", "MSSQL" ou "ODBC" e configure a conexão: endereço do servidor SQL, porta, login e senha. Escolha uma métrica ou informe uma consulta SQL que lê valores das tabelas.
O 10-Strike Network Monitor conecta ao banco na frequência definida e executa uma consulta SQL de teste, confirmando que o SGBD está funcionando.
Estes SGBDs são suportados:
• Microsoft SQL
• MySQL
• qualquer outro SGBD com conexão pela interface ODBC (MSAccess®, Oracle®, Sybase, Firebird e muitos outros).
Com consultas SQL ao servidor de banco, também dá para monitorar serviços de terceiros que gravam e atualizam os parâmetros nele. Se o valor do parâmetro sair da faixa, o programa avisa o administrador.
Monitoramento de processos de negócio
Também dá para monitorar os processos de negócio da empresa, processando valores e métricas do banco com consultas SQL: número de vendas, receita, custos etc. Verificações com SQL podem ser usadas uma a uma ou combinadas em uma fórmula, para calcular um valor mais complexo. Para isso, o programa traz a verificação Check Counted by Formula. Por exemplo, duas verificações em bancos diferentes, e os parâmetros resultantes entram em outra conta, pela fórmula informada.
Veja também: Monitoramento de servidor web HTTP(S) e do conteúdo da página, Monitoramento de servidor FTP
Requisitos: Windows XP/Vista/7/8.1/10/11, Server 2003/2008/2012/2016/2019/2022.





