Monitorando o Desempenho do MongoDB: Principais Comandos e Métricas Explicados

O gerenciamento eficaz de banco de dados depende de um monitoramento robusto. Para o MongoDB, um banco de dados NoSQL líder, entender as métricas de desempenho é crítico para manter alta disponibilidade e capacidade de resposta. Consultas lentas, consumo excessivo de recursos ou picos inesperados de conexão podem impactar severamente o desempenho da aplicação.

Quando o MongoDB fica lento, a primeira pergunta útil não é "o banco de dados está ruim?" É "o que o servidor está fazendo agora, e isso é diferente do normal?" Os comandos abaixo são os que eu uso para uma primeira análise antes de alterar índices, redimensionar hardware ou culpar a aplicação.

Comandos Essenciais de Monitoramento no Shell do MongoDB (mongosh)

A interface principal para executar esses comandos é o Shell do MongoDB (mongosh), ou o shell legado mongo. Todos os comandos mostrados aqui são executados dentro deste ambiente de shell.

1. Entendendo as Conexões Atuais: db.currentOp() e db.serverStatus()

Monitorar conexões ativas é vital para evitar a exaustão de conexões e identificar operações de longa duração que podem estar bloqueando recursos.

db.currentOp()

Este comando retorna informações sobre operações atualmente em execução no banco de dados. É indispensável para identificar consultas lentas ou bloqueadoras em tempo real.

Exemplo de Uso:

Para ver todas as operações em execução:

db.currentOp()

Para procurar especificamente operações executadas por mais tempo que um determinado limite (por exemplo, operações executadas por mais de 5 segundos):

db.currentOp({"secs_running": {$gt: 5}})

A saída inclui detalhes como op, ns (namespace), query e secs_running.

db.serverStatus()

Embora este comando forneça informações abrangentes de status, sua seção connections é crucial para monitorar o pooling e os limites de conexão.

Métricas Chave dentro de serverStatus (Seção Connections):

• current: O número de conexões ativas para o servidor.
• available: O número de conexões disponíveis que podem ser estabelecidas (com base no máximo configurado).

db.serverStatus().connections

2. Analisando o Desempenho de Consultas: db.getProfilingStatus() e db.setProfilingLevel()

O MongoDB fornece ferramentas de perfilagem integradas que registram os detalhes de execução das operações do banco de dados, tornando possível identificar consultas que consomem muitos recursos.

Níveis de Perfilagem

Os níveis de perfilagem determinam quais operações são registradas:

• 0 (Desligado): Nenhuma operação é perfilada.
• 1 (Operações Lentas): Apenas operações mais lentas que o limite configurado (slowms) são perfiladas.
• 2 (Todas as Operações): Todas as operações são perfiladas, o que gera uma carga de escrita significativa e deve ser usado apenas brevemente para solução de problemas direcionada.

Verificando o Status

Para ver o nível de perfilagem atual:

db.getProfilingStatus()

Configurando o Nível (Exemplo)

Para ativar a perfilagem apenas para operações lentas (operações que excedem 100 milissegundos):

// Define slowms para 100 milissegundos (o padrão geralmente é 100)
db.setProfilingLevel(1, { slowms: 100 })

Dica: Sempre retorne a perfilagem para o nível 0 depois de coletar as informações necessárias para evitar degradação de desempenho causada por registro excessivo.

Visualizando Consultas Lentas Perfiladas

As operações perfiladas são armazenadas na coleção system.profile dentro do banco de dados específico que está sendo monitorado. Para visualizar as 10 consultas mais lentas na última hora:

db.system.profile.find().sort({millis: -1}).limit(10).pretty()

3. Métricas de Utilização de Recursos

Entender como o MongoDB utiliza CPU, memória e recursos de E/S é essencial para decisões de escalabilidade.

Uso de Memória e Armazenamento: db.serverStatus()

As seções globalLock e storageEngine dentro de serverStatus fornecem insights profundos sobre o gerenciamento de recursos.

Indicadores de Memória:

• resident: Quantidade de memória física que o processo está usando.
• virtual: Memória virtual total alocada pelo processo.

db.serverStatus().globalLock

Monitoramento de Contenção de Bloqueio

O MongoDB usa mecanismos de bloqueio internos. Monitorar a aquisição de bloqueios e esperas ajuda a identificar gargalos de concorrência.

Métricas Chave em globalLock:

• currentQueue.readers: Número de leitores esperando por um bloqueio.
• currentQueue.writers: Número de escritores esperando por um bloqueio.
• totalTime: Tempo total gasto esperando por bloqueios em todas as operações.

Valores altos em currentQueue geralmente indicam que os índices estão faltando ou que as operações de escrita são excessivamente longas, fazendo com que leitores/escritores formem fila.

4. Uso e Saúde do Índice: db.collection.stats()

Índices mal utilizados ou ausentes são a causa mais comum de degradação de desempenho. O comando stats() ajuda a analisar a eficiência do índice.

Quando executado em uma coleção específica (por exemplo, users):

db.users.stats()

Métricas Chave para Verificar:

• totalIndexSize: O espaço total em disco consumido por todos os índices nessa coleção.
• indexSizes: Uma discriminação do uso de espaço por índice.
• Se um índice está presente, mas nunca é usado para leituras, é uma sobrecarga que deve ser considerada para remoção.

5. E/S de Disco e Taxa de Transferência: db.serverStatus() (Rede e Operações)

Monitorar a atividade de rede e a taxa de operações fornece uma visão da taxa de transferência do banco de dados.

Taxa de Operações (de opcounters):

opcounters rastreia o número total de operações executadas desde a última reinicialização do servidor, categorizadas por tipo:

• insert, query, update, delete, getmore, command.

Ao rastrear as alterações nesses contadores ao longo do tempo (por exemplo, comparando duas chamadas consecutivas de serverStatus), você pode calcular a taxa de transferência operacional (operações por segundo).

Exemplo de Comparação:

1. Execute db.serverStatus().opcounters no tempo T1.
2. Execute db.serverStatus().opcounters no tempo T2.
3. Subtraia os valores de T1 dos valores de T2 para obter o total de operações executadas nesse intervalo.

Melhores Práticas para Monitoramento Proativo

• Automação é Chave: Depender apenas de comandos manuais do shell é ineficiente. Integre o monitoramento usando ferramentas como MongoDB Cloud Manager/Ops Manager ou soluções de monitoramento de terceiros que consultam esses endpoints automaticamente.
• Estabeleça Linhas de Base: Execute comandos quando o sistema estiver saudável para estabelecer uma linha de base de desempenho. Qualquer desvio desta linha de base justifica uma investigação imediata.
• Foco na Latência: Embora as contagens de operações sejam úteis, priorize métricas de latência (como o tempo relatado pelos logs de perfilagem) em vez da taxa de transferência bruta ao diagnosticar problemas de experiência do usuário final.
• Verifique Conexões com Frequência: Em aplicações de alto tráfego, os limites de conexão são frequentemente atingidos primeiro. Monitore db.serverStatus().connections.current em relação ao máximo configurado.

Uma Lista de Verificação Prática para Primeira Análise

Quando alguém diz "o MongoDB está lento", evite pular direto para alterações de índice. Comece com uma pequena lista de verificação e anote o que você vê.

Verifique se o servidor está sobrecarregado com operações ativas:

db.currentOp({
  active: true,
  secs_running: { $gt: 2 }
});

Algumas operações de longa duração podem ser normais para trabalhos de análise. Uma grande pilha de gravações, varreduras de coleção ou operações bloqueadas é diferente. Procure o namespace em ns, o tipo de operação em op e a forma da consulta. Se muitas operações estão esperando atrás de uma atualização ou construção de índice, a correção não é a mesma que um índice ausente em uma consulta de leitura.

Em seguida, verifique as conexões:

db.serverStatus().connections;

current subindo rapidamente pode significar que um pool de conexões da aplicação foi mal configurado, uma implantação criou muitos workers, ou os clientes estão expirando e reconectando. available perto de zero é um sinal urgente porque novos clientes podem falhar ao conectar. A resposta correta pode ser o ajuste do pool no aplicativo, não aumentar o limite do servidor.

Em seguida, verifique os contadores de operação duas vezes, com um curto intervalo entre elas:

const a = db.serverStatus().opcounters;
sleep(5000);
const b = db.serverStatus().opcounters;
printjson({
  insertPer5s: b.insert - a.insert,
  queryPer5s: b.query - a.query,
  updatePer5s: b.update - a.update,
  deletePer5s: b.delete - a.delete,
  commandPer5s: b.command - a.command
});

Os contadores desde a inicialização são úteis para contexto de longo prazo, mas as diferenças em um intervalo conhecido informam o que está acontecendo agora. Se o tráfego de comandos é alto, mas as consultas são baixas, você pode estar olhando para verificações de metadados, ruído de monitoramento ou comportamento do driver, em vez de leituras normais.

Usando explain() Antes de Culpar o Hardware

A coleção de perfil pode informar quais operações são lentas. explain() ajuda você a entender por que uma consulta é lenta antes de adicionar CPU ou memória.

db.users.find({ email: "[email protected]" }).explain("executionStats");

Na saída, compare totalDocsExamined com nReturned. Se o MongoDB examina um grande número de documentos para retornar um usuário, a consulta provavelmente precisa de um índice melhor ou de um filtro diferente. Se totalKeysExamined é alto, um índice existe, mas pode não ser seletivo o suficiente para o padrão da consulta.

Para uma consulta composta, a ordem do índice é importante:

db.orders.find({
  accountId: "acct_123",
  status: "open",
  createdAt: { $gte: ISODate("2025-11-01T00:00:00Z") }
}).sort({ createdAt: -1 });

Um índice útil pode ser:

db.orders.createIndex({ accountId: 1, status: 1, createdAt: -1 });

Isso não é uma regra universal. O melhor índice depende da cardinalidade, ordem de classificação e do conjunto completo de consultas que atingem a coleção. O objetivo é fazer o banco de dados mostrar o plano de execução em vez de adivinhar.

Lendo Dados de Perfil sem Reagir Exageradamente

O nível de perfilagem 2 registra todas as operações e pode adicionar sobrecarga em sistemas ocupados. Use-o apenas por uma janela curta e direcionada. O nível 1 com um limite slowms razoável é mais seguro para encontrar operações lentas.

db.setProfilingLevel(1, { slowms: 200 });

Após coletar dados, inspecione as entradas mais lentas:

db.system.profile.find(
  {},
  {
    ns: 1,
    op: 1,
    millis: 1,
    command: 1,
    keysExamined: 1,
    docsExamined: 1,
    nreturned: 1
  }
).sort({ millis: -1 }).limit(20).pretty();

Uma consulta lenta nem sempre significa um incidente de produção. Um relatório agendado, um cache frio após reinicialização ou uma tarefa de manutenção rara podem aparecer perto do topo. Padrões são mais importantes do que uma única amostra. Se a mesma forma de consulta aparece repetidamente e examina muito mais documentos do que retorna, você tem um candidato real para ajuste.

Monitorando Conjuntos de Réplicas e Pressão de Armazenamento

Para conjuntos de réplicas, o desempenho não é apenas sobre o primário. Um secundário que fica para trás pode afetar a confiança no failover e as cargas de trabalho de leitura se os clientes usarem leituras secundárias.

rs.status();

Procure por membros que não estão saudáveis, mudanças de estado inesperadas ou lag de replicação que não se recupera. O lag aceitável exato depende da aplicação. Uma carga de trabalho do tipo fila pode tolerar um pequeno atraso. Um painel que promete leituras quase em tempo real pode não tolerar.

A pressão de armazenamento precisa do mesmo contexto. db.serverStatus() pode mostrar métricas do mecanismo de armazenamento e WiredTiger, mas as ferramentas de nível de disco ainda são importantes. Se o MongoDB está esperando em discos lentos, os comandos do shell dentro do banco de dados mostrarão sintomas, em vez da causa raiz. Correlacione com métricas do host, como latência de disco, uso do sistema de arquivos, CPU steal e pressão de memória.

Transformando Verificações Manuais em Alertas

Comandos manuais são melhores durante a investigação. Para operações normais, converta os sinais úteis em verificações automatizadas: uso de conexão, saúde da replicação, taxa de consultas lentas, uso de disco, falhas de página ou pressão de cache quando disponível, e latência de operação. Alerte sobre mau comportamento sustentado, não sobre cada pico de um minuto.

Bons alertas incluem contexto. "Consultas lentas do MongoDB altas" é menos útil do que um alerta que inclui o banco de dados, coleção, forma da consulta, taxa atual e um link para amostras de perfil recentes ou painéis de dashboard. O objetivo é encurtar os primeiros dez minutos do incidente.

O Que Não Fazer Durante uma Lentidão

Evite fazer várias alterações ao mesmo tempo. Adicionar um índice, aumentar os limites de conexão, reiniciar a aplicação e alterar os tamanhos do pool no mesmo incidente pode eliminar o sintoma, mas deixa você sem ideia de qual ação ajudou. Faça uma alteração, observe a métrica que deve melhorar e mantenha anotações.

Tenha cuidado com killOp. Pode ser útil quando uma operação é claramente prejudicial, mas matar operações aleatórias de longa duração pode piorar o comportamento da aplicação. Se a operação pertence a uma migração, backup, construção de índice ou trabalho de relatório, identifique o proprietário antes de pará-la, a menos que o banco de dados já esteja em sérios apuros.

Não trate serverStatus() como uma única pontuação mágica de saúde. É uma coleção de contadores e instantâneos. Um valor alto pode ser normal em um sistema grande e ocupado, e um valor baixo pode ser ruim em um sistema pequeno e sensível à latência. A pergunta útil é se o valor mudou de uma forma que corresponde ao problema voltado para o usuário.

Também separe os sintomas do banco de dados dos sintomas da implantação. Uma nova versão que altera a forma da consulta, abre pools de conexão maiores ou inicia uma migração em segundo plano pode fazer o MongoDB parecer a causa raiz. Compare o tempo das operações lentas com implantações, agendamentos de trabalhos, backups e mudanças de tráfego antes de fazer uma correção apenas no banco de dados.

O monitoramento do MongoDB funciona melhor quando você compara o comportamento atual com uma linha de base conhecida. db.currentOp(), db.serverStatus(), perfilagem, explain() e verificações de conjunto de réplicas fornecem evidências suficientes para decidir se o problema é uma consulta, um índice, comportamento de conexão do cliente, replicação ou o host subjacente ao banco de dados.