É por meio de um monitoramento consistente de banco de dados que a disponibilidade e o desempenho de aplicativos são garantidos, assegurando a continuidade dos negócios.
MySQL, Oracle, IBM DB2, Microsoft SQL Server, PostgreSQL, MariaDB – não importa qual banco de dados você use, ele deve ser monitorado.
Cada banco de dados (SQL ou NoSQL) fornece um certo nível de telemetria. A telemetria fornecida é o que permite criar regras e métricas para monitorar seu banco de dados.
A telemetria de monitoramento de banco de dados pode ser implícita ou explícita. A telemetria explícita está facilmente disponível; tipicamente, são tabelas e/ou variáveis de estado acessíveis por meio de comandos simples, procedimentos, funções ou consultas. A telemetria implícita, por outro lado, requer interpretação e é geralmente obtida cruzando informações de várias fontes.
Cada banco de dados tem itens de monitoramento comuns e específicos. O objetivo deste artigo é listar os principais itens comuns que devem ser monitorados com precisão.
Afinal, o que devo monitorar no meu banco de dados? O que cada item pode me dizer?
Métrica: Consumo de CPU
Monitore o consumo constante de processador e as cargas. Não se preocupe com picos. Qualquer pico com menos de 5 minutos pode representar apenas um consumo momentâneo elevado. O consumo elevado de processador e/ou cargas elevadas de processador podem indicar um número excessivo de consultas simultâneas, consultas consumindo recursos excessivos, consultas com estratégias ruins (plano de execução de consulta) e até mesmo consultas fazendo “full table scan”.
Métrica: E/S de Disco
Monitore o número de leituras e gravações por segundo, bem como quantos bytes são gravados e lidos por segundo. Acompanhar o número de leitura/gravação e a quantidade de bytes lidos/gravados por segundo ajuda a entender se o banco de dados está dentro da capacidade dos discos e/ou controladores. Configurar as necessidades de E/S do banco de dados em contraste com as capacidades do ambiente ajuda a avaliar se o ambiente está ultrapassando os limites. Operações de fila (I/O Waits) podem indicar exaustão de capacidade do ambiente (hardware) ou os mesmos problemas apontados nas métricas de Consumo de CPU.
Métrica: E/S de Ethernet
Monitore o número de bytes enviados e recebidos por segundo, e o número de portas abertas. Assim como os controladores de disco e os discos em si, é necessário conhecer a capacidade de entrada e saída dos controladores de rede. Certifique-se de que o ambiente de rede tenha capacidade suficiente para trafegar todos os bytes enviados e recebidos pelo banco de dados. O esgotamento de portas, embora raro, pode ocorrer. Além disso, muitas portas abertas no sistema operacional em comparação com o servidor de banco de dados podem indicar erros de configuração, bibliotecas defeituosas e/ou incompatíveis, e até mesmo erros de aplicativo. Monitore se seus controladores estão aceitando conexões com o banco de dados.
Métrica: Processos em Execução no Servidor
Monitore tudo o que é executado no servidor de banco de dados. Nada deve consumir mais recursos do que o próprio banco de dados.
Servidores de banco de dados devem ser executados em hosts dedicados (ou máquinas virtuais). No entanto, algum processo ou agente pode aparecer consumindo recursos extras, seja por engano ou por outros problemas. É importante monitorar processos estranhos em execução na mesma máquina hospedeira, evitando-os e impedindo que roubem recursos.
Métrica: SWAP
Monitore o comportamento e o consumo do SWAP.
Este é um assunto controverso, mas não será abordado neste breve artigo. De qualquer forma, é importante monitorar o consumo e o comportamento do SWAP. O SWAP é uma daquelas coisas boas de se ter, mas é melhor se nunca for usado. O consumo de SWAP pode indicar uma configuração inadequada do banco de dados, que está colocando pressão na memória RAM, usando mais recursos de memória do que os disponíveis. Também pode indicar que consultas complexas (ou mal escritas) estão consumindo muita memória RAM, forçando o servidor a usar o SWAP.
Métrica: Espaço em Disco e seu Estado
Monitore o uso do disco e seu estado (aceitando gravações).
Todo mundo sabe disso porque é bastante básico, mas, por ser simples e óbvio, normalmente é esquecido. Portanto, monitore se seus discos têm espaço para dados, metadados, índices, logs, etc. O banco de dados é um consumidor intensivo de disco. Em todos os momentos, deve haver espaço em disco para gravações, incluindo várias manutenções distintas (movimentação de objetos, criação e alocação de espaço para novos objetos, reduções, etc.).
Problemas com os próprios discos (mídias), controladores, sistemas de arquivos, entre outros, podem colocar seus discos em condição de “somente leitura”. Então, além de não gravar logs, não haverá gravação de dados. Alguns bancos de dados podem congelar, paralisando suas aplicações.
Métrica: Consultas Ineficientes
Monitore consultas que estão consumindo um nível elevado de recursos ou demorando muito para serem concluídas.
Uma boa ferramenta de monitoramento deve procurar consultas ineficientes e catalogá-las com base em limiares inteligentes. Uma consulta é considerada ineficiente quando consome muitos recursos (CPU e/ou Memória), manipula mais linhas do que o necessário para um conjunto de resultados dado. Uma consulta ineficiente também pode gerar falhas, esgotar recursos de tal maneira a tornar todo o banco de dados lento, instável e até mesmo derrubá-lo. Monitorar e encontrar essas consultas problemáticas e tomar medidas imediatas é a chave para manter seu banco de dados saudável.
Métrica: Bloqueios e Deadlocks
Bloqueios e deadlocks ocorrem silenciosamente na maioria das vezes. Essa é a razão pela qual devem ser considerados perigosos. Uma transação bloqueia várias outras por milissegundos inocentes. Quando esses milissegundos ocorrem várias vezes ao dia, pode-se perceber quanto tempo de processamento está sendo roubado de aplicações, pessoas e empresas. Isso deve ser abordado.
Monitorar e entender as causas de bloqueios e deadlocks é obrigatório para evitar desempenho ruim e aplicativos defeituosos. Identificar e abordar esses problemas trará melhor desempenho nas operações OLTP e OLAP, relatórios e painéis que lidam com grandes massas de dados.
Normalmente, bloqueios e deadlocks são causados pelo uso inadequado de índices, concorrência excessiva, concepção equivocada de transações, uso incorreto de motores de armazenamento e até mesmo modelagem de dados inadequada.
Métrica: Buffers e Caches
Mesmo com o surgimento de SSDs poderosos projetados para bancos de dados, a memória RAM ainda é um meio mais eficiente. Portanto, manter o máximo de dados possível na RAM tornará o banco de dados mais rápido. Monitore o uso de buffers e caches em relação ao número total de páginas, páginas em uso, quais dados estão em memória, flashes, commits e se os dados armazenados lá fazem sentido.
Uma boa configuração de buffers e caches significa que os dados mais acessados estão sempre na memória, reduzindo a E/S de disco e aumentando o desempenho. O objetivo do monitoramento de Buffers e Caches é disponibilizar o máximo de dados relevantes possível na memória, com o mínimo esforço para trazer dados do disco para a memória.
Métrica: Índices
Índices fazem parte do sucesso de aplicativos e bancos de dados. A falta de índices tornará as consultas simples mais lentas, e as complexas terão dificuldade em serem concluídas. Índices mal construídos consumirão mais recursos do que o necessário. Muitos índices tornarão as gravações lentas. Poucos índices são ruins; por outro lado, muitos índices também são ruins. Um equilíbrio deve ser alcançado.
Monitore as atividades de índices. Identifique índices de baixo desempenho, os mais usados e aqueles que nunca são usados.
Métrica: Conexões ou Sessões
Monitore as sessões conectadas ao banco de dados, catalogando-as como conexões ativas, conexões inativas e conexões com alto consumo de recursos.
Por exemplo, cada sessão incorre em um custo para o banco de dados. Portanto, se houver um grande número de conexões ativas ou não, isso pode ser uma fonte de problemas para a máquina hospedeira. Conexões inativas excessivas podem indicar problemas no lado da aplicação ou da rede.
Essas são métricas comuns à maioria dos bancos de dados que devem ser monitoradas. No entanto, existem pelo menos outras 50 métricas comuns, além daquelas específicas de cada fabricante de banco de dados.
Além das métricas, outro fator de grande importância é o Limiar. Limites operacionais (mínimos e máximos) que definem um arco imaginário de normalidade. Limites inadequados podem fazer com que alertas não sejam emitidos corretamente. Este assunto será abordado em um próximo artigo.
Saiba mais sobre o Flightdeck, nossa plataforma de monitoramento de banco de dados. Visite o blog do nosso DBA Sênior ou veja sua contribuição na Oracle Community.
Está faltando algo em nossa plataforma de monitoramento? Converse conosco e ficaremos felizes em desenvolvê-lo.
