O gerenciamento de operações de banco de dados consiste em 80% da leitura e interpretação de seus sistemas de monitoramento. Centenas de métricas podem ser interpretadas e combinadas de várias maneiras para fornecer insights profundos sobre seus sistemas de banco de dados e como otimizá-los. Ao executar vários sistemas de banco de dados, o monitoramento desses sistemas pode se tornar uma tarefa árdua. Se a interpretação e a combinação de métricas levam muito tempo, não seria ótimo se isso pudesse ser automatizado de alguma forma?
É por isso que criamos consultores de banco de dados no ClusterControl:pequenos scripts que podem interpretar e combinar métricas para você e dar conselhos quando aplicável. Para o MySQL, criamos uma extensa biblioteca das verificações de monitoramento do MySQL mais usadas. Mas também para o MongoDB temos uma ampla biblioteca de advisors à sua disposição. Para esta postagem do blog, selecionamos os nove mais importantes para você. Vamos descrever cada um deles em detalhes.
Os nove conselheiros do MongoDB que abordaremos nesta postagem do blog são:
- Verificação das opções de montagem em disco
- Verificação de número
- Porcentagem de bloqueio de coleção (MMAP)
- Atraso de replicação
- Janela de replicação
- Bancos de dados e coleções não fragmentados (somente cluster fragmentado)
- Verificação de autenticação ativada
- Verificação de integridade de autenticação/autorização
- Detecção de erros (novo orientador)
Consultor de opções de montagem em disco
É muito importante ter seus discos montados da maneira mais otimizada possível. Com o consultor de opções de montagem de disco ClusterControl, examinamos mais de perto seu disco de dados diariamente. Neste orientador, investigamos o sistema de arquivos usado, as opções de montagem e as configurações do agendador io do sistema operacional.
Verificamos se seus discos foram montados com noatime e nodiratime. Defini-los diminuirá o desempenho dos discos, pois em cada acesso a um arquivo ou diretório o tempo de acesso deve ser gravado no disco. Como isso acontece continuamente em bancos de dados, essa é uma boa configuração de desempenho e também aumenta a durabilidade de seus SSDs.
Para sistemas de arquivos, recomendamos usar sistemas de arquivos modernos como xfs, zfs, ext4 ou btrfs. Esses sistemas de arquivos são criados com o desempenho em mente. Recomenda-se que o agendador io esteja em noop ou prazo. Prazo tem sido o padrão para bancos de dados há anos, mas graças ao armazenamento mais rápido, como SSDs, o noop agendador está fazendo mais sentido hoje em dia.
Consultor de Verificação do Num
Para o MongoDB, habilitamos nosso NUMA consulte o conselheiro. Este consultor verificará se NUMA (Non-Uniform Access Memory) foi ativado em seu sistema e, se for o caso, desligá-lo.
Quando a Memória de Acesso Não Uniforme estiver habilitada, a CPU do servidor só poderá endereçar sua própria memória diretamente e não as outras CPUs da máquina. Desta forma, a CPU só é capaz de alocar memória de seu próprio espaço de memória, e alocar qualquer coisa em excesso resultará em uso de swap. Essa arquitetura tem um forte benefício de desempenho em aplicativos multiprocessados que alocam todas as CPUs, mas como o MongoDB não é um aplicativo multiprocessador, ele diminuirá bastante o desempenho e poderá levar a um grande uso de swap.
Porcentagem de bloqueio de coleção (MMAP)
Como MMAP é um sistema de armazenamento baseado em arquivo, ele não suporta o bloqueio de nível de documento como encontrado em WiredTiger e RocksDB. Em vez disso, o nível mais baixo de bloqueio para MMAP é os bloqueios de coleção. Isso significa que qualquer gravação em uma coleção (inserir, atualizar ou excluir) bloqueará toda a coleção. Se a porcentagem de bloqueios estiver ficando muito alta, isso indica que você tem problemas de contenção na coleção. Quando não tratado adequadamente, isso pode interromper a taxa de transferência de gravação. Portanto, ter um conselheiro avisando com antecedência é muito útil.
MongoDB Replication Lag Advisor
Se você estiver escalando o MongoDB para leituras por meio de secundários, é muito importante ficar de olho no atraso de replicação. Os drivers do cliente MongoDB usarão apenas secundários que não fiquem muito atrasados, caso contrário você corre o risco de fornecer dados obsoletos.
Dentro do MongoDB, o primário acompanhará o status de replicação de seus secundários. O orientador buscará as informações de replicação e protegerá o atraso de replicação. Se o atraso ficar muito alto, ele enviará um aviso ou mensagem de status crítico.
MongoDB Replication Window Advisor
Ao lado do atraso de replicação, a janela de replicação é uma métrica importante a ser observada. O oplog do MongoDB é uma coleção única, que foi limitada em um tamanho (predefinido). Quando o oplog chegar ao fim e uma nova transação precisar ser armazenada, ele despejará a transação mais antiga para liberar espaço para a nova transação. A janela de replicação reflete o número de segundos entre a transação mais antiga e a mais recente no oplog.
Essa métrica é muito importante, pois você precisa saber por quanto tempo pode tirar um secundário do replicaSet, antes que ele não consiga mais acompanhar o mestre devido a estar muito atrasado na replicação. Além disso, se um secundário começar a ficar para trás, seria bom saber quanto tempo podemos tolerar isso antes que o secundário não seja mais capaz de alcançá-lo.
No shell do MongoDB, uma função está disponível para calcular a janela de replicação. Este orientador no ClusterControl usa a função para fazer o mesmo cálculo. O benefício seria que agora você pode ser alertado em uma janela de replicação muito curta.
Vários noves Torne-se um DBA do MongoDB - Trazendo o MongoDB para a produçãoSaiba mais sobre o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o MongoDBBaixe gratuitamente
MongoDB Bancos de Dados Não Fragmentados e Consultor de Coleções
Em um cluster do MongoDB fragmentado, todos os bancos de dados e coleções não fragmentados são atribuídos a um fragmento primário padrão pelo roteador de fragmentos do MongoDB. Esse shard primário pode variar entre os bancos de dados e as coleções, mas, em geral, seria o shard com mais espaço em disco disponível.
Ter um banco de dados ou uma coleção não fragmentada não representa um risco imediato para seu cluster. No entanto, se um aplicativo ou usuário começar a gravar grandes volumes de dados em um deles, o estilhaço principal poderá ser preenchido rapidamente e criar uma interrupção nesse estilhaço. Como o banco de dados ou coleção não está fragmentado, ele não poderá usar outros fragmentos.
Por este motivo, criamos um consultor que impedirá que isso aconteça. O orientador verificará todos os bancos de dados e coleções e avisará se não tiver sido fragmentado.
Verificação de autenticação ativada
Sem habilitar a autenticação no MongoDB, qualquer usuário que fizer login será tratado como administrador. Este é um risco sério, pois normalmente as tarefas administrativas, como criar usuários ou fazer backups, agora estão disponíveis para qualquer pessoa. Isso combinado com os servidores MongoDB expostos, resultou nos recentes hacks de resgate do MongoDB, enquanto uma simples habilitação de autenticação teria evitado a maioria desses casos.
Implementamos um consultor que verifica se seus servidores MongoDB possuem autenticação habilitada. Isso pode ser feito explicitamente definindo isso na configuração ou implicitamente ativando o arquivo-chave de replicação. Se este orientador não detectar que a autenticação foi ativada, você deve agir imediatamente, pois seu servidor está vulnerável a ser comprometido.
Verificação de integridade de autenticação/autorização
Ao lado do orientador habilitado para autenticação, também construímos um orientador que realiza uma verificação de integridade para autenticação e autorização no MongoDB.
No MongoDB a autenticação e autorização não são colocadas em um local central, mas são realizadas e armazenadas no nível do banco de dados. Normalmente, os usuários se conectarão ao banco de dados, autenticando-se no banco de dados que pretendem usar. No entanto, com as concessões corretas, também é possível autenticar em outros bancos de dados (não relacionados) e ainda fazer uso de outro banco de dados. Normalmente, isso está perfeitamente bem, a menos que um usuário tenha direitos excessivos (como a função de administrador) sobre outro banco de dados.
Neste consultor, verificamos se essas funções excessivas estão presentes e se podem representar uma ameaça. Também verificamos ao mesmo tempo se há senhas fracas e fáceis de adivinhar.
Detecção de erro (novo Consultor)
No MongoDB, qualquer erro encontrado será contado ou registrado. Dentro do MongoDB existe uma grande variedade de erros possíveis:declarações do usuário, declarações regulares, avisos e até exceções internas do servidor. Se houver tendências nesses erros, é provável que haja uma configuração incorreta ou um problema de aplicativo.
Este orientador examinará as estatísticas de erros do MongoDB (asserts) e entenderá isso. Interpretamos as tendências encontradas e aconselhamos como diminuir erros em seu ambiente MongoDB!
