MongoDB Monitoramento: SolarWinds vs New Relic vs Datadog
Instalamos o SolarWinds, o Datadog e o New Relic em sistemas limpos executando o MongoDB 7.0 para testar. Analisamos o processo de configuração completo de cada ferramenta, documentando cada etapa e obstáculo.
MongoDB: resultados do benchmark de ferramentas de monitoramento de performance
Plataforma | Tempo de Configuração | Perfilamento de Consultas | Precisão das Métricas | RAM Uso | Melhor Para |
|---|---|---|---|---|---|
5 min | ✓ | 100% preciso | Médio (500MB) | Otimização de produção | |
New Relic | 15 min | ✕ | Baixo (23 a 800% taxas de erro) | Baixo (90MB) | Verificações básicas de integridade |
Datadog | 20+ min | ✕ | Indefinido | Médio (330MB) | Monitoramento multitecnologia |
MongoDB: resumo do desempenho de monitoramento
- SolarWinds concluiu a configuração em 5 minutos com detecção automática e forneceu perfilamento em nível de consulta que os outros não tinham.
- New Relic levou 15 minutos com etapas de verificação manual e relatou métricas imprecisas.
- Datadog exigiu 20+ minutos de edição de YAML e ofereceu apenas visibilidade básica.
Você também pode ver como essas plataformas monitoram o MySQL e nosso ambiente de teste e metodologia
1. Experiência de instalação e integração
1. SolarWinds
SolarWinds concluiu a integração com o MongoDB em menos de 5 minutos. O SolarWinds abre com um modal simples: “O que você deseja monitorar?” Ao selecionar desempenho de banco de dados, a plataforma exibe os bancos de dados suportados antecipadamente.
Após selecionar o MongoDB, o SolarWinds verifica se já existem agentes.
A plataforma detectou imediatamente nosso agente instalado anteriormente.
Um recurso se destacou: a interface exibe os detalhes do agente (sistema operacional, ID da instância na nuvem, versão) diretamente na tela de seleção. Sem necessidade de procurar em menus suspensos.
Agora o SolarWinds solicita as credenciais do MongoDB. Inserimos os detalhes da conexão: localhost, método de autenticação (baseado em senha), nome de usuário e senha. O nome de exibição foi auto-preenchido com as informações do nosso servidor, embora tenha usado o nome de host interno completo em vez do nome do agente que havíamos especificado anteriormente.
Uma estranheza: o menu suspenso “Captura de Consultas” apareceu sem explicação. Selecionamos “Log” e avançamos, sem saber o que as outras opções faziam.
A próxima tela apresentou três comandos de banco de dados para executar. Cada comando tinha um botão de copiar. Nós os executamos no MongoDB e clicamos em “Observar Banco de Dados”.
Foi aqui que o SolarWinds nos impressionou. Em vez de nos pedir para descobrir as permissões, ele forneceu comandos de copiar e colar:
- Criar um usuário de monitoramento com credenciais específicas
- Conceder os privilégios necessários (funções clusterMonitor e readAnyDatabase)
- Definir o nível de profiling
Uma tela de resumo apareceu mostrando nossa configuração. O status do plugin mostrava “O plugin está sendo implantado.”
Segundos depois, o status mudou para “Implantação do plugin bem-sucedida” com um link para visualizar o painel. Configuração concluída.
Descubra a observabilidade do SolarWinds com monitoramento profundo de MongoDB e perfilamento de consultas. Explore o SolarWinds.
Visite o site2. New Relic
O New Relic levou cerca de 15 minutos para configurar, mas o tempo não era o problema real. O atrito veio de responder a perguntas que a plataforma já deveria saber.
O New Relic começa na página Integrações e Agentes.
Pesquisamos por “mongo” e encontramos várias integrações relacionadas ao MongoDB.
Após selecionar o MongoDB, o New Relic nos pediu para escolher um método de instrumentação.
Escolhemos “Em um host” já que nosso agente já estava instalado. A próxima tela perguntou o sistema operacional. Selecionamos Linux. Isso pareceu desnecessário, já que o agente já estava em execução no servidor, mas continuamos.
A próxima tela solicitou os detalhes do host do MongoDB. O termo “SCRAM” apareceu sem explicação. A maioria das pessoas conhece isso como autenticação por nome de usuário/senha, mas o termo técnico adiciona confusão.
Após clicar em “continuar”, o New Relic perguntou em qual servidor instalar. Essa pergunta deveria ter vindo primeiro, não depois de já termos inserido os detalhes de configuração. O agente já estava instalado em “aimultiple-benchmark”, então o selecionamos e continuamos.
A próxima tela nos pediu para verificar a compatibilidade da versão do MongoDB. O New Relic queria que executássemos mongod --version e confirmássemos que a saída correspondia aos seus requisitos. Tivemos que copiar o comando, alternar para nosso terminal, executá-lo, verificar o número da versão e voltar para clicar em continuar.
O agente já está instalado no servidor. Ele poderia verificar isso automaticamente.
Após clicar em continuar, chegamos à etapa de criação de usuário. O New Relic forneceu um script do MongoDB para criar o usuário de monitoramento. Os comandos eram claros, com atribuições de função adequadas (clusterMonitor e readAnyDatabase). Também tivemos que executar um comando de teste de conexão para verificar se o usuário funcionava corretamente.
Essa abordagem foi melhor do que pedir acesso root, mas presumiu que descobriríamos onde executar esses comandos.
A próxima tela nos pediu para instalar o pacote de integração. Agora o New Relic quer que instalemos manualmente usando o yum. Mesmo com o agente já instalado no Ubuntu, a interface assume o Amazon Linux por padrão e fornece comandos de instalação do yum em vez do apt. Esperávamos que a plataforma detectasse automaticamente o sistema operacional correto a partir do agente instalado.
Executamos o comando apt correto para Ubuntu e depois avançamos para a próxima tela. O New Relic forneceu um arquivo de configuração YAML e nos disse exatamente onde colocá-lo: /etc/newrelic-infra/integrations.d/. Pelo menos o caminho do arquivo estava claro.
Criamos o arquivo, colamos a configuração e clicamos em Continuar. A tela final mostrou um botão “Testar conexão”. Clicamos nele e aguardamos.
O teste passou. Configuração concluída.
3. Datadog
O Datadog levou mais de 20 minutos para concluir. A integração funcionou eventualmente, mas chegar lá exigiu um esforço manual significativo.
Após fazer login, fomos para Integrações e pesquisamos por “mongo”. Clicamos em MongoDB e um modal apareceu.
A visão geral mostrou o que o monitoramento do MongoDB inclui, mas clicar em “Instalar Integração” apenas abriu outra tela com instruções densas.
Foi aqui que o Datadog nos sobrecarregou. A tela mostrou um guia de referência completo cobrindo todos os cenários possíveis do MongoDB: instâncias autônomas, conjuntos de réplicas, clusters fragmentados, métodos de autenticação, configuração SSL e mais.
Para alguém apenas tentando monitorar uma única instância do MongoDB, a parede de texto pareceu excessiva.
Percorremos a página procurando as etapas básicas:
- Criar um usuário de monitoramento no MongoDB
- Editar o arquivo de configuração YAML
- Reiniciar o agente do Datadog
O Datadog forneceu os comandos do MongoDB para criar o usuário, o que foi útil. Mas, quando se tratou do arquivo YAML, a documentação dizia para editar conf.yaml sem indicar claramente onde esse arquivo deveria ficar.
Sabíamos por experiência que ele pertence a /etc/datadog-agent/conf.d/mongo.d/, mas as instruções enterraram esse detalhe no fundo da documentação.
Criamos o usuário do MongoDB, escrevemos a configuração YAML, colocamos no diretório correto e reiniciamos o agente.
Depois voltamos para a interface do Datadog e clicamos em “Instalar Integração”.
O botão desapareceu. Nenhuma mensagem de confirmação, nenhuma notificação de sucesso, nenhum redirecionamento para um painel. Nada.
Esperamos um momento e depois navegamos manualmente até a seção Painéis e encontramos as métricas do MongoDB começando a aparecer.
2. Consumo de recursos do agente
Monitoramos quantos recursos cada agente consumia durante a execução. O teste durou aproximadamente 10 minutos com os três agentes coletando dados simultaneamente da mesma instância do MongoDB sob carga.
Estressamos o sistema inserindo 2 milhões de registros no MongoDB usando um script que gerava dados aleatórios. Isso simulou a atividade real de banco de dados enquanto medíamos o uso de recursos do agente.
Consumo de CPU
Todos os três agentes usaram recursos mínimos de CPU durante o teste.
- O New Relic apresentou o menor consumo médio de CPU, mas teve picos ocasionais que chegaram a 4%. Esses picos foram breves e não afetaram o desempenho do sistema.
- O SolarWinds manteve o uso de CPU mais consistente, permanecendo em torno de 3% sem variação significativa.
- O Datadog ficou no meio, com média pouco acima de 2% e desempenho estável durante todo o teste.
Uso de memória
O uso de memória mostrou diferenças mais significativas entre os agentes.
O New Relic consumiu cerca de 5 a 6x menos memória do que o SolarWinds. Em nosso servidor de teste de 16GB, isso se traduziu em:
- New Relic: ~90MB
- Datadog: ~330MB
- Solarwinds: ~500MB
Para a maioria dos servidores de produção, essas quantidades não farão diferença. Mas se você estiver executando agentes em sistemas com recursos limitados ou monitorando centenas de bancos de dados, a diferença se acumula.
O uso de memória permaneceu estável nos três agentes durante todo o teste. Não ocorreram vazamentos de memória nem crescimento inesperado.
I/O de disco
A atividade de disco variou consideravelmente entre os agentes.
O SolarWinds realizou significativamente mais leituras de disco do que os outros dois agentes, cerca de 40x mais do que o New Relic e 1.5x mais do que o Datadog. Isso sugere que o SolarWinds acessa dados armazenados localmente com mais frequência, possivelmente para seus recursos de perfilamento de consultas.
O Datadog gravou menos no disco, indicando que ele armazena menos dados localmente antes de enviá-los para a nuvem.
O New Relic apresentou o padrão de I/O mais equilibrado, com leituras e gravações moderadas.
Uso de rede
O tráfego de rede mostrou quantos dados cada agente enviou ao seu backend.
Todos os três agentes enviaram quantidades semelhantes de dados pela rede. O Datadog transmitiu um pouco menos, possivelmente devido a uma compactação mais agressiva ou a taxas de amostragem diferentes.
O tráfego bidirecional faz sentido, pois os agentes enviam métricas e recebem atualizações de configuração ou comandos da plataforma.
Resumo do impacto nos recursos
Nenhum desses agentes sobrecarregará seu sistema. Mesmo sob carga de banco de dados com os três rodando simultaneamente, o consumo total de recursos permaneceu bem abaixo de 10% para CPU e memória combinados.
O New Relic vence em eficiência de memória. O SolarWinds usa mais recursos, mas oferece análises mais detalhadas em nível de consulta. O Datadog fica no meio.
Para a maioria dos casos de uso, essas diferenças de recursos não influenciarão sua decisão. Escolha com base em recursos e usabilidade, não no consumo de recursos.
3. Painel e capacidades de monitoramento
Após concluir a configuração, precisávamos ver o que cada plataforma realmente mostra. Executamos a mesma carga de trabalho nas três: inserindo 2 milhões de registros em lotes de 5.000, seguidos por mais 5 milhões de registros.
O script usou Node.js com Faker para gerar dados aleatórios de usuários, nomes, e-mails, endereços e números de telefone. Isso nos deu um dataset realista para monitorar.
Enquanto as inserções eram executadas, monitoramos o consumo de recursos do agente em segundo plano.
A carga de trabalho colocou estresse real no MongoDB, o que nos permitiu ver como cada plataforma capturou e exibiu a atividade.
Painel do SolarWinds
Clicamos em “Bancos de Dados” no menu esquerdo e imediatamente vimos nossa instância do MongoDB. Um clique e um painel completo apareceu.
A parte superior da tela mostrou a saúde do MongoDB, o tempo médio de resposta, a taxa de transferência (consultas por segundo) e a contagem de erros. O gráfico de bolhas “Top 10 de Divisão de Serviços” exibiu os padrões de consulta mais usados com suas contagens e porcentagens.
Os números contaram uma história. A taxa de transferência mostrou 3 consultas por segundo em média. A divisão mostrou 1.400 operações de inserção. Por que 1.400 em vez de 7 milhões?
Inserimos 7 milhões de registros em lotes de 5.000. Isso equivale a 1.400 operações em lote. O SolarWinds rastreou cada lote sem perder nenhum.
A aba Profiler mostrou padrões de consulta com tempos médios de execução.
Nossas consultas de inserção levaram de 4 a 5 segundos cada, o que parece alto até você lembrar que cada consulta gravou 5.000 linhas.
A aba Health mostrou tudo funcionando sem problemas.
Paramos o serviço do MongoDB para ver com que rapidez o SolarWinds perceberia. Em 30-40 segundos, o status de saúde mudou para “Ruim”.
A aba Queries forneceu filtragem avançada. Você podia listar consultas que:
- Retornaram erros
- Executaram sem índices adequados
- Responderam lentamente
- Geraram avisos
Cada padrão de consulta mostrou quando apareceu pela primeira vez, quando foi executado pela última vez, quantas amostras foram capturadas e estatísticas de execução. Para solução de problemas, esse nível de detalhe é importante.
A aba Alerts nos permitiu criar alertas específicos do MongoDB. Já havíamos criado um alerta de memória para o host anteriormente, mas agora podíamos configurar notificações específicas do banco de dados.
A aba Resources mostrou métricas no nível do host juntamente com estatísticas do MongoDB, CPU, memória, disco e rede. Esse contexto ajuda a distinguir entre problemas de banco de dados e problemas de infraestrutura subjacente.
A aba Advisors ainda não tinha recomendações, mas as forneceu para o MySQL em nosso teste anterior. Esperamos que ela ofereça sugestões de otimização à medida que coleta mais dados do MongoDB.
Atualizações de IA: Em outubro de 2025, o SolarWinds lançou o IA Agent com o recurso IA Query Assist (atualmente em prévia técnica). O IA Query Assist analisa padrões de consulta de banco de dados e propõe reescritas otimizadas para melhorar o desempenho automaticamente. O Root Cause Assist (agora disponível de forma geral) gera análises claras de causa raiz com base em alertas e anomalias para reduzir o tempo de solução de problemas. A disponibilidade mais ampla do IA Agent em todo o portfólio da SolarWinds está prevista para 202612.
Painel do New Relic
Fomos para a seção Painéis, mas nenhum painel do MongoDB apareceu automaticamente.
Pesquisamos por “mongo” no catálogo de painéis e encontramos duas opções do MongoDB.
Selecionamos o painel regular do MongoDB e clicamos em “Configurar MongoDB”.
Ele nos redirecionou novamente para a configuração da integração do MongoDB. A plataforma já sabia que havíamos instalado o MongoDB, então por que nos enviar de volta para a instalação? Clicamos em “Concluído” e prosseguimos para o painel.
O painel abriu completamente vazio. “Nenhum valor relatado para a verificação de serviço mongodb.can_connect.”
Verificamos nossa configuração usando newrelic-infra agent configtest.
Quando executamos o comando newrelic-infra agent configtest para verificar problemas com nossa configuração, notamos que o integration_name estava definido como nri-prometheus. Durante a configuração do painel, o New Relic mostrou duas opções do MongoDB, uma das quais era a versão Prometheus. Nada na interface indicava que essa era uma integração diferente, então nunca me ocorreria que eu tivesse selecionado a do Prometheus. Isso não foi um erro do usuário; simplesmente não havia orientação ou distinção na interface.
Voltamos e instalamos o painel “MongoDB (Prometheus)”.
Desta vez, os dados apareceram.
Mas aqui está o problema: como um usuário normal descobriria isso? O processo de instalação foi confuso, e agora a seleção do painel adicionou outra camada de complexidade.
O layout do painel parecia estranho. O topo mostrava informações totais de servidores e bancos de dados que mudam uma vez por ano, mas ocupava um espaço nobre da tela.
Abaixo disso, “Saturação de Conexão” aparecia em destaque. Essa métrica só importa quando algo está errado. Por que colocá-la no topo?
A seção “Operações de Consulta” reportou 11.670 inserções. O número estava errado. Inserimos 7 milhões de registros em 1.400 operações em lote. O gráfico não correspondia à realidade.
A aba Databases mostrou o tamanho do banco de dados, contagens de objetos e tamanhos de índices. Esses números estavam corretos: 7 milhões de objetos. O New Relic obtém esses dados consultando o MongoDB diretamente (“Quantos documentos você tem?”). Mas a contagem de consultas em tempo real falhou.
A aba Collections incluiu gráficos úteis para métricas em nível de coleção: tamanho (com visualizações de tabela e gráfico), tamanho total com porcentagem de mudança, contagem de operações de leitura, latência de leitura, contagem de operações de gravação, latência de gravação, contagem de transações, latência de transações, operações de acesso a índices, contagens de execução de comandos, latência de comandos, frequência de comandos e duração de comandos.
Notavelmente ausentes: métricas do host. Não conseguíamos ver o uso de CPU, memória, disco ou rede do servidor que executava o MongoDB. O SolarWinds incluiu esse contexto, mas o Datadog, assim como o New Relic, não.
Mais importante ainda, não existia análise em nível de consulta em lugar nenhum. Sem padrões de consulta, sem profiling, sem identificação de consultas lentas, sem detecção de índices ausentes. Para solução de problemas de banco de dados, esses recursos são importantes.
Painel do Datadog
Clicamos em “Painéis” no menu esquerdo. Um painel “MongoDB – Visão Geral” apareceu automaticamente.
Nós o abrimos, mas estava vazio.
O problema levou tempo para diagnosticar. Durante a instalação, a configuração de autodiscovery do Datadog exigia especificar quais bancos de dados monitorar usando uma correspondência de padrão. O padrão não correspondia ao nome do nosso banco de dados. O Datadog nunca mencionou isso durante a configuração.
Alteramos todos os padrões para .* (corresponder a tudo) e reiniciamos o agente.
Mas por que o painel estava completamente vazio? Mesmo sem métricas específicas do banco de dados, tempo de atividade, contagens de conexão e estatísticas do servidor deveriam ter aparecido. Não apareceram.
Executamos datadog-agent check mongo para depurar. O arquivo de configuração tinha um erro de indentação. A exigência de formatação estrita do YAML nos pegou. Após corrigi-lo e executar novamente nosso teste de carga com 5 milhões de inserções, os dados finalmente apareceram.
Imediatamente encontramos problemas com o painel. A seção Logs exibiu “Não Acessível” mesmo tendo configurado a coleta de logs em nosso arquivo YAML. O processo de configuração do Datadog informou que tudo estava bem, mas os logs ainda não funcionavam.
O layout do painel fazia pouco sentido para nosso caso de uso. A seção superior focava em estatísticas de sharding. Não estávamos executando um cluster fragmentado. O meio mostrava métricas de conjuntos de réplicas. Não tínhamos conjuntos de réplicas. A parte inferior voltava ao sharding novamente. Cerca de 60% do painel exibia seções vazias para recursos que não estávamos usando.
As informações úteis ocupavam talvez 40% da tela: tempo de atividade, uso de memória, I/O de rede, consultas por segundo e latência de leitura/gravação. Sem análise de consultas, sem profiling, sem detecção de consultas lentas, sem recomendações de índices.
Não conseguíamos nem determinar quantas operações foram executadas a partir deste painel.
MongoDB ambiente e metodologia do teste de benchmark de monitoramento
Executamos as três ferramentas em configurações idênticas para garantir uma comparação justa. Cada teste usou:
- Banco de Dados: MongoDB 7.0 Community Edition
- Servidor: Instância AWS m6i.xlarge
- Ponto de partida: Instalação nova com o agente de monitoramento principal já instalado
Todos os três fornecedores exigem que você instale o agente base antes de adicionar integrações específicas, como o MongoDB. Concluímos essa etapa antecipadamente, então nosso teste se concentrou puramente na experiência de integração do MongoDB.
O que medimos:
- Complexidade da configuração: Número de etapas manuais, configuração automática versus manual, clareza das instruções e se a interface nos guiou ou nos deixou procurando as próximas etapas.
- Consumo de recursos do agente: Uso de CPU, memória, E/S de disco e rede durante ocioso e sob carga (inserindo 7 milhões de registros).
- Capacidades de monitoramento: Qualidade do painel, precisão das métricas, análise em nível de consulta e recursos de solução de problemas.
Considerações de segurança
Uma vulnerabilidade severa chamada “MongoBleed” foi divulgada, afetando as versões do MongoDB Server anteriores a 8.0.17, 7.0.28, 6.0.27 e anteriores. Essa vulnerabilidade de leitura fora dos limites sem autenticação pode permitir que invasores acessem dados confidenciais na memória. As organizações que executam o MongoDB devem atualizar imediatamente para as versões corrigidas: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 ou 4.4.3034. Ao selecionar ferramentas de monitoramento, garanta que elas suportem métodos seguros de autenticação e não introduzam riscos de segurança adicionais.
Abordamos cada ferramenta como um usuário comum faria, sem ler a documentação antecipadamente e sem treinamento prévio. Se algo não estivesse aparente na interface, anotávamos.
Adicionar como fonte preferencialMongoDB: veredito final do benchmark de monitoramento
Nós nos propusemos a responder a uma pergunta simples: qual plataforma de monitoramento torna a integração do MongoDB mais fácil para equipes não técnicas?
Depois de instalar as três, executar cargas de trabalho idênticas e avaliar os painéis, a resposta ficou clara. Nossa avaliação é baseada na integração básica do MongoDB do Datadog a partir de janeiro de 2025. O Datadog lançou desde então o Database Monitoring (DBM) para o MongoDB (dezembro de 2024), que oferece capacidades significativamente mais profundas, incluindo profiling de consultas, análise de operações lentas, planos de explicação e monitoramento de replicação. O produto DBM resolve muitas das limitações identificadas neste benchmark5.
SolarWinds: Feito para o monitoramento de banco de dados
O SolarWinds venceu essa comparação de forma decisiva. A plataforma detectou imediatamente nosso agente, nos guiou pela configuração de credenciais por meio de comandos de copiar e colar e implantou automaticamente a integração. A configuração levou 5 minutos.
O painel apareceu instantaneamente com informações relevantes. O profiling de consultas mostrou exatamente quais operações consumiam mais recursos. A plataforma capturou todas as 1.400 operações em lote sem perder nenhuma. Quando paramos o MongoDB, o SolarWinds detectou a falha em 40 segundos.
A aba Queries nos permite filtrar por erros, índices ausentes, respostas lentas e avisos, recursos que apoiam diretamente a otimização do banco de dados. Esperava-se que o recurso Advisors fornecesse recomendações (embora não tenhamos gerado dados suficientes para acionar nenhuma durante nosso teste).
O SolarWinds se concentrou no que os administradores de banco de dados realmente precisam: análise de consultas, profiling de desempenho e insights acionáveis.
New Relic: Perdido na configuração
O New Relic levou 15 minutos para configurar, mas o tempo não foi o problema principal. A plataforma fez perguntas na ordem errada, exigiu verificação manual de coisas que o agente poderia verificar automaticamente e nos forçou a instalar pacotes manualmente.
A confusão com o painel piorou as coisas. Instalamos o monitoramento do MongoDB, mas selecionar o painel padrão resultou em uma tela vazia. Somente depois de vasculhar os arquivos de configuração percebemos que havíamos selecionado o tipo de integração errado. Um usuário comum não descobriria isso.
Quando os dados finalmente apareceram, as métricas estavam erradas. O New Relic reportou 11.670 inserções depois que realizamos 1.400 operações em lote, totalizando 7 milhões de registros. A plataforma subestimou em uma ordem de magnitude.
Mais criticamente, o New Relic não forneceu análise em nível de consulta. Sem profiling, sem detecção de consultas lentas, sem identificação de índices ausentes. Para solução de problemas de banco de dados, essas omissões são importantes.
Datadog: Trabalho manual necessário
O Datadog exigiu 20+ minutos de configuração e a configuração mais manual. Editamos os arquivos YAML, determinamos onde colocá-los e reiniciamos os serviços a partir da linha de comando.
O painel apareceu automaticamente, mas não exibiu nada. A configuração de autodiscovery usou um padrão que não correspondia ao nosso banco de dados. Após corrigir o padrão e corrigir erros de indentação do YAML, os dados finalmente foram preenchidos.
O próprio painel se mostrou mal projetado para uma instância única do MongoDB. Sessenta por cento da tela estava vazia, com seções para sharding e conjuntos de réplicas, recursos que não estávamos usando. Os 40% restantes ofereciam métricas básicas: tempo de atividade, memória, I/O de rede, consultas por segundo e latência.
Sem análise de consultas. Sem profiling. Sem recomendações de otimização. Não conseguíamos determinar com precisão as contagens de operações no painel.
Sem análise de consultas. Sem profiling. Sem recomendações de otimização. Não conseguíamos determinar com precisão as contagens de operações no painel.
Atualização Crítica (Dezembro de 2024): Após a conclusão deste benchmark, o Datadog lançou o Database Monitoring (DBM) para o MongoDB, o que altera significativamente esta avaliação. O DBM para o MongoDB agora oferece:
- Análise de operações lentas com amostras detalhadas de consultas
- Planos de explicação para otimização de consultas
- Monitoramento do estado de replicação e visualização da saúde do cluster
- Insights em nível de operação e identificação de gargalos de desempenho
- Integração com monitoramento de desempenho de aplicativos para solução de problemas unificada
O DBM representa uma atualização substancial em relação à integração básica do MongoDB testada neste benchmark e inclui muitos dos recursos de análise em nível de consulta que estavam ausentes durante nossos testes56. As organizações que avaliam o Datadog para monitoramento do MongoDB devem avaliar especificamente o produto Database Monitoring em vez da integração básica testada aqui.
Qual ferramenta de monitoramento de banco de dados realmente funciona quando você não é um especialista em DevOps?
A experiência de configuração
SolarWinds abriu com um modal perguntando o que você deseja monitorar. Você escolhe “desempenho de banco de dados”, seleciona o MongoDB e a plataforma encontra imediatamente o agente que você já instalou, mostrando o sistema operacional, o ID da instância na nuvem e o número da versão ali mesmo na tela de seleção. Em seguida, ela fornece três comandos de copiar e colar para executar no MongoDB, cuida das credenciais e confirma a implantação. Cinco minutos, do início ao fim.
New Relic levou quinze minutos, e o tempo nem era o problema real. A interface continuava fazendo perguntas que o agente poderia ter respondido sozinho, como qual sistema operacional e qual versão do MongoDB, apesar de o agente já estar no servidor. Em um momento, ela usou como padrão comandos de instalação do Amazon Linux, embora estivéssemos claramente executando o Ubuntu. A etapa que finalmente quebrou a experiência: há duas opções de integração do MongoDB no catálogo de painéis, uma padrão e uma baseada no Prometheus, e nada na interface as distingue. Escolhemos a errada, obtivemos um painel vazio e só descobrimos isso vasculhando os arquivos de configuração.
Datadog exigiu mais de vinte minutos de edição de YAML, adivinhando caminhos de arquivos e reiniciando serviços a partir da linha de comando. A documentação oferecida durante a configuração não é um guia; é um manual de referência completo cobrindo instâncias autônomas, conjuntos de réplicas, clusters fragmentados e configuração SSL, tudo de uma vez, para alguém que só quer monitorar um banco de dados. Quando os dados finalmente apareceram, o painel começou com estatísticas de sharding e métricas de conjuntos de réplicas. Não tínhamos nenhum dos dois. Cerca de sessenta por cento da tela estava vazia.
Precisão das métricas sob carga
O SolarWinds contou 1.400. Exatamente correto. O New Relic reportou 11.670, errado por uma ordem de magnitude sem explicação óbvia, e perdeu completamente um pico de memória durante o teste. Quando paramos o serviço do MongoDB, o SolarWinds detectou a falha em trinta a quarenta segundos.
Sobre o consumo de recursos: o New Relic usou cerca de 90MB de RAM, o Datadog cerca de 330MB e o SolarWinds cerca de 500MB em nosso servidor de 16GB. O SolarWinds realizou cerca de quarenta vezes mais leituras de disco do que o New Relic, provavelmente devido ao trabalho local de profiling de consultas. Para a maioria dos ambientes, nada disso influenciará sua decisão.
O recurso que realmente os diferencia
Toda ferramenta de monitoramento dirá que algo está lento. A questão é se ela diz por quê.
O SolarWinds oferece profiling em nível de consulta. A aba Profiler mostrou exatamente quais padrões de consulta estavam em execução, quanto tempo cada um levou e quantas amostras foram capturadas. Você pode filtrar por consultas que foram executadas sem um índice, retornaram erros ou geraram avisos.
O New Relic e o Datadog mostraram apenas métricas agregadas de latência, contagens de conexão e totais de operações. Sem profiling, sem identificação de consultas lentas, sem detecção de índices ausentes. Para confirmar se um banco de dados está vivo, funciona. Para diagnosticar por que ele está com dificuldades, é um beco sem saída.
Observação: o Datadog lançou um produto Database Monitoring para o MongoDB em dezembro de 2024, após nossos testes, que adiciona análise de operações lentas, planos de explicação e visibilidade em nível de consulta. Testamos a integração padrão, que continua sendo o que a maioria dos usuários encontra primeiro.
SolarWinds: Se a otimização do banco de dados é sua preocupação real. Métricas precisas, configuração rápida e a única plataforma aqui que diz não apenas que uma consulta está lenta, mas o que fazer a respeito.
New Relic: Se você já o usa para APM e precisa de saúde básica do banco de dados no mesmo lugar. Rastrear uma solicitação lenta do navegador através do código até a chamada ao banco de dados é genuinamente útil. Não confie nele para contagens precisas de operações.
Datadog: Se você se sente confortável com configuração manual e deseja uma plataforma para uma pilha complexa. As mais de 600 integrações justificam o atrito da configuração para a equipe certa.
Cite este benchmark
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{dogan2026,
author = {Dogan, Sedat and Ermut, Sıla},
title = {{MongoDB Monitoramento: SolarWinds vs New Relic vs Datadog}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/mongodb-monitoring}},
note = {AIMultiple. Acessado em 16 setembro 2026}
}Resultados e carimbos de data/hora de 38 pontos de dados. Baixe os dados resumidos exibidos nos gráficos e tabelas deste artigo como um arquivo ZIP contendo 7 arquivos CSV.
Quer os dados granulares por trás disso? Assine o Premium
Registro de alterações
5 atualizaçõesSubstituída a seção "A Diferença Principal" por "Qual Ferramenta de Monitoramento de Banco de Dados Realmente Funciona Quando Você Não é um Especialista em DevOps?".
Adicionadas Atualizações de IA à seção SolarWinds.
Adicionadas Considerações de Segurança à metodologia.
Links de referência
- Tem 20 anos de experiência como hacker de chapéu branco e guru de desenvolvimento, com ampla experiência em linguagens de programação e arquiteturas de servidores.
- É conselheiro de administração em uma VC que investe em empresas de tecnologia em estágio inicial e na Ödeal, uma plataforma regional de pagamentos digitais que atende 125.000 comerciantes.
- Liderou a infraestrutura tecnológica e a cibersegurança de sete eleições nacionais e foi reconhecido no Hall da Fama da cibersegurança por líderes globais de tecnologia, incluindo o Twitter.
Ela trabalhou anteriormente como recrutadora em empresas de gerenciamento de projetos e consultoria. Sıla possui mestrado em Psicologia Social e bacharelado em Relações Internacionais.
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.