Monitoramento do MongoDB: SolarWinds vs New Relic vs Datadog
Instalamos o SolarWinds, o Datadog e o New Relic em sistemas limpos com MongoDB 7.0 para testes. Passamos por todo o processo de configuração de cada ferramenta, documentando cada etapa e cada obstáculo encontrado.
Resultados do Benchmark de Ferramentas de Monitoramento de Desempenho do MongoDB
Plataforma | Tempo de configuração | Perfil de consultas | Precisão métrica | Utilização de RAM | Ideal para |
|---|---|---|---|---|---|
5 minutos | ✅ | ✅ 100% preciso | Médio (500 MB) | Otimização da produção | |
Nova Relíquia | 15 minutos | ❌ | ❌ Baixas taxas de erro (de 23 a 800%) | Baixo (90 MB) | Exames básicos de saúde |
Datadog | 20+ min | ❌ | ⚠️ Não está claro | Médio (330 MB) | Monitoramento multitecnológico |
Resumo do desempenho do monitoramento do MongoDB
- A SolarWinds concluiu a configuração em 5 minutos com detecção automática e forneceu perfis em nível de consulta, algo que as outras soluções não ofereciam.
- O New Relic levou 15 minutos com etapas de verificação manual e apresentou métricas imprecisas.
- O Datadog exigiu mais de 20 minutos de edição de YAML e ofereceu apenas visibilidade básica.
Você também pode ver como essas plataformas monitoram o MySQL , nosso ambiente de teste e nossa metodologia.
1. Experiência de Instalação e Integração
1. Solarwinds
A SolarWinds concluiu a integração com o MongoDB em menos de 5 minutos. A SolarWinds inicia com um modal simples: “O que você deseja monitorar?” Ao selecionar o desempenho do banco de dados , a plataforma exibe os bancos de dados compatíveis de forma clara.
Após selecionar o MongoDB, o Solarwinds verifica se já existem agentes disponíveis.
A plataforma detectou imediatamente o agente que tínhamos instalado anteriormente.
Uma funcionalidade 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 preenchido automaticamente 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 peculiaridade: o menu suspenso "Captura de Consulta" apareceu sem explicação. Selecionamos "Registrar" e prosseguimos, sem entender a função das outras opções.
A tela seguinte apresentava três comandos de banco de dados para executar. Cada comando tinha um botão de copiar. Executamos os comandos no MongoDB e clicamos em “Observar Banco de Dados”.
Foi aqui que a Solarwinds nos impressionou. Em vez de nos pedir para descobrir as permissões, ela forneceu comandos de copiar e colar:
- Crie um usuário de monitoramento com credenciais específicas.
- Conceda os privilégios necessários (funções clusterMonitor e readAnyDatabase).
- Defina o nível de perfilamento.
Apareceu uma tela de resumo mostrando nossa configuração. O status do plugin indicava "O plugin está sendo implantado".
Segundos depois, o status mudou para “Implantação do plugin concluída com sucesso”, com um link para visualizar o painel de controle. Configuração concluída.
Descubra o SolarWinds Observability com monitoramento profundo do MongoDB e criação de perfis de consultas. Explore o SolarWinds.
Visite o site2. Nova Relíquia
A configuração do New Relic levou cerca de 15 minutos, mas o tempo não era o verdadeiro problema. A dificuldade surgiu ao responder perguntas que a plataforma já deveria saber fazer.
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 selecionarmos o MongoDB, a New Relic nos pediu para escolher um método de instrumentação.
Selecionamos "Em um host", já que nosso agente já estava instalado. A tela seguinte solicitou o sistema operacional. Selecionamos Linux. Isso pareceu desnecessário, pois o agente já estava em execução no servidor, mas prosseguimos.
A tela seguinte solicitava 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 gera confusão.
Após clicar em continuar, o New Relic perguntou em qual servidor instalar. Essa pergunta deveria ter vindo primeiro, e 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 tela seguinte pedia que verificássemos a compatibilidade da versão do MongoDB. A New Relic queria que executássemos o comando mongod --version e confirmássemos se a saída correspondia aos requisitos. Tínhamos que copiar o comando, alternar para o 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 do usuário. A 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 era melhor do que pedir acesso root, mas pressupunha que descobriríamos onde executar esses comandos.
A tela seguinte solicitou a instalação do pacote de integração. Agora, a New Relic exige que a instalação seja feita manualmente usando o yum. Embora o agente já esteja instalado no Ubuntu, a interface usa 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, em seguida, passamos para a próxima tela. A New Relic forneceu um arquivo de configuração YAML e nos indicou 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 foi aprovado. Configuração concluída.
3. Datadog
A integração com o Datadog levou mais de 20 minutos para ser concluída. Ela acabou funcionando, mas exigiu um esforço manual considerável.
Após fazer login, fomos em Integrações e pesquisamos por “mongo”. Clicamos em MongoDB e uma janela modal foi exibida.
A visão geral mostrava o que o monitoramento do MongoDB incluía, mas clicar em “Instalar integração” apenas abria outra tela com instruções complexas.
Foi aí que o Datadog nos surpreendeu. A tela exibia um guia de referência completo, abrangendo todos os cenários possíveis do MongoDB: instâncias independentes, conjuntos de réplicas, clusters fragmentados, métodos de autenticação, configuração SSL e muito mais.
Para alguém que está apenas tentando monitorar uma única instância do MongoDB, a quantidade de texto pareceu excessiva.
Percorremos a página procurando os passos básicos:
- Criar um usuário de monitoramento no MongoDB
- Edite o arquivo YAML de configuração.
- Reinicie o agente Datadog.
O Datadog forneceu os comandos do MongoDB para criar o usuário, o que foi útil. Mas, quando se tratava do arquivo YAML, a documentação dizia para editar o arquivo conf.yaml sem especificar claramente onde esse arquivo deveria ser inserido.
Sabíamos por experiência que pertencia a /etc/datadog-agent/conf.d/mongo.d/, mas as instruções esconderam esse detalhe em algum lugar profundo da documentação.
Criamos o usuário do MongoDB, escrevemos a configuração YAML, colocamos no diretório correto e reiniciamos o agente.
Em seguida, voltamos à 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 de controle. Nada.
Aguardamos um momento, depois navegamos manualmente até a seção Dashboards e encontramos as métricas do MongoDB começando a ser exibidas.
2. Consumo de Recursos do Agente
Monitoramos o consumo de recursos de cada agente 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.
Submetemos o sistema a um teste de estresse, inserindo 2 milhões de registros no MongoDB por meio de um script que gerava dados aleatórios. Isso simulou a atividade real de um banco de dados enquanto medíamos o uso de recursos do agente.
Consumo de CPU
Os três agentes utilizaram 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ções significativas.
- O Datadog ficou em uma posição intermediária, com uma média de pouco mais de 2% e desempenho estável ao longo do teste.
Uso de memória
O uso da memória apresentou diferenças mais significativas entre os agentes.
O New Relic consumiu aproximadamente 5 a 6 vezes menos memória que o Solarwinds. Em nosso servidor de teste de 16 GB, isso se traduziu em:
- New Relic: ~90 MB
- Datadog: ~330 MB
- Solarwinds: ~500MB
Para a maioria dos servidores de produção, esses valores 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 torna significativa.
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.
E/S de disco
A atividade do disco variou consideravelmente entre os agentes.
O SolarWinds realizou um número significativamente maior de leituras de disco do que os outros dois agentes, cerca de 40 vezes mais do que o New Relic e 1,5 vezes mais do que o Datadog. Isso sugere que o SolarWinds acessa dados armazenados localmente com mais frequência, possivelmente para seus recursos de criação de perfil de consultas.
O Datadog gravou menos dados em disco, indicando que armazena menos dados localmente antes de enviá-los para a nuvem.
A New Relic apresentou o padrão de E/S mais equilibrado, com leituras e gravações moderadas.
Utilização da rede
O tráfego de rede mostrou a quantidade de dados que cada agente enviou para seu servidor.
Os três agentes enviaram quantidades semelhantes de dados pela rede. O Datadog transmitiu um pouco menos, possivelmente devido a uma compressão mais agressiva ou a taxas de amostragem diferentes.
O tráfego bidirecional faz sentido, já que 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 em execução simultaneamente, o consumo total de recursos permaneceu bem abaixo de 10% para CPU e memória combinadas.
O New Relic se destaca 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 em uma posição intermediária.
Na maioria dos casos de uso, essas diferenças de recursos não influenciarão sua decisão. Escolha com base em funcionalidades e usabilidade, não no consumo de recursos.
3. Recursos de painel de controle e monitoramento
Após concluirmos a configuração, precisávamos ver o que cada plataforma realmente exibia. Executamos a mesma carga de trabalho nas três: inserimos 2 milhões de registros em lotes de 5.000, seguidos por outros 5 milhões de registros.
O script utilizou Node.js com Faker para gerar dados aleatórios de usuários, incluindo nomes, e-mails, endereços e números de telefone. Isso nos forneceu um conjunto de dados realista para monitoramento.
Enquanto as inserções eram executadas, monitorávamos o consumo de recursos do agente em segundo plano.
A carga de trabalho exerceu uma pressão real sobre o MongoDB, o que nos permitiu ver como cada plataforma capturou e exibiu a atividade.
Painel de controle do Solarwinds
Clicamos em “Bancos de dados” no menu à esquerda e imediatamente vimos nossa instância do MongoDB. Um clique e um painel completo apareceu.
A parte superior da tela mostrava a integridade 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 Service Breakdown" exibia os padrões de consulta mais frequentes, com suas respectivas contagens e porcentagens.
Os números contavam uma história. A taxa de transferência mostrou uma média de 3 consultas por segundo. O detalhamento revelou 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 corresponde a 1.400 operações em lote. O Solarwinds rastreou cada lote sem perder nenhum.
A aba Profiler exibia 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 muito tempo até você lembrar que cada consulta gerou 5.000 linhas.
A aba Saúde mostrava que tudo estava funcionando perfeitamente.
Interrompemos o serviço do MongoDB para ver com que rapidez o Solarwinds perceberia. Em 30 a 40 segundos, o status de integridade mudou para "Ruim".
A guia Consultas fornecia filtros avançados. Você podia listar consultas que:
- Erros retornados
- Executado sem índices adequados
- Respondeu lentamente
- Avisos gerados
Cada padrão de consulta mostrava quando apareceu pela primeira vez, quando foi executado pela última vez, quantas amostras foram capturadas e as estatísticas de execução. Para a resolução de problemas, esse nível de detalhe é importante.
A aba Alertas nos permitiu criar alertas específicos para o MongoDB. Já tínhamos criado um alerta de memória para o host anteriormente, mas agora podíamos configurar notificações específicas para o banco de dados.
A aba Recursos exibia métricas do host juntamente com estatísticas do MongoDB, CPU, memória, disco e rede. Esse contexto ajuda a distinguir entre problemas no banco de dados e problemas na infraestrutura subjacente.
A aba "Conselheiros" 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 coletar mais dados do MongoDB.
Atualizações de IA : Em outubro de 2025, a SolarWinds lançou o AI Agent com o recurso AI Query Assist (atualmente em versão prévia técnica). O AI Query Assist analisa padrões de consultas de banco de dados e propõe reescritas otimizadas para melhorar o desempenho automaticamente. O Root Cause Assist (agora disponível para todos) 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 AI Agent em todo o portfólio da SolarWinds está prevista para 2026. 1 2 .
Painel do New Relic
Fomos até a seção Dashboards, mas nenhum dashboard do MongoDB apareceu automaticamente.
Pesquisamos por “mongo” no catálogo do painel de controle e encontramos duas opções de MongoDB.
Selecionamos o painel de controle padrão do MongoDB e clicamos em “Configurar o MongoDB”.
Fomos redirecionados novamente para a configuração de integração do MongoDB. A plataforma já sabia que tínhamos instalado o MongoDB, então por que nos enviar de volta para a instalação? Clicamos em "Concluído" e prosseguimos para o painel de controle.
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.
Ao executarmos o comando `newrelic-infra agent configtest` para verificar problemas na nossa configuração, notamos que o `integration_name` estava definido como `nri-prometheus`. Durante a configuração do painel de controle, o New Relic exibiu duas opções de MongoDB, uma das quais era a versão Prometheus. Nada na interface indicava que se tratava de uma integração diferente, então jamais me ocorreria que eu havia selecionado a versão Prometheus. Não foi um erro do usuário; simplesmente não havia nenhuma orientação ou distinção na interface.
Voltamos e instalamos o painel de controle “MongoDB (Prometheus)”.
Desta vez, os dados apareceram.
Mas eis o problema: como um usuário comum descobriria isso? O processo de instalação foi confuso, e agora a seleção do painel adicionou mais uma camada de complexidade.
O layout do painel parecia estranho. A parte superior mostrava o total de servidores e informações de bancos de dados, que mudam apenas uma vez por ano, e mesmo assim ocupava um espaço privilegiado na tela.
Abaixo disso, a “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 Bancos de Dados mostrava o tamanho do banco de dados, a contagem de objetos e os tamanhos dos í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 Coleções incluía gráficos úteis para métricas em nível de coleção: tamanho (com visualizações em tabela e gráfico), tamanho total com variação percentual, 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ção, operações de acesso ao índice, contagem de execuções de comandos, latência de comandos, frequência de comandos e duração de comandos.
Ausência notável: métricas do host. Não conseguimos visualizar o uso de CPU, memória, disco ou rede do servidor que executa o MongoDB. O SolarWinds incluía esse contexto, mas o Datadog, assim como o New Relic, não.
Mais importante ainda, não existia nenhuma análise em nível de consulta em lugar nenhum. Nenhum padrão de consulta, nenhum perfilamento, nenhuma identificação de consultas lentas, nenhuma detecção de índices ausentes. Para a resolução de problemas em bancos de dados, esses recursos são essenciais.
Painel de controle do Datadog
Clicamos em “Painéis” no menu à esquerda. Um painel “MongoDB – Visão geral” apareceu automaticamente.
Abrimos, mas estava vazio.
O problema levou tempo para ser diagnosticado. Durante a instalação, a configuração de descoberta automática do Datadog exigia a especificação de quais bancos de dados monitorar usando uma correspondência de padrão. O padrã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, o tempo de atividade, a contagem de conexões e as estatísticas do servidor deveriam ter aparecido. Mas não apareceram.
Executamos o teste datadog-agent check mongo para depurar. O arquivo de configuração tinha um erro de indentação. A exigência de formatação rigorosa do YAML nos pegou de surpresa. Depois de corrigir o problema e executar novamente nosso teste de carga com 5 milhões de inserções, os dados finalmente apareceram.
Imediatamente nos deparamos com problemas no painel de controle. A seção de Logs exibia "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 correto, mas os logs continuavam sem funcionar.
O layout do painel não fazia muito sentido para o nosso caso de uso. A seção superior focava em estatísticas de fragmentação. Não estávamos executando um cluster fragmentado. A seção do meio mostrava métricas de conjuntos de réplicas. Não tínhamos conjuntos de réplicas. A seção inferior voltava a mostrar fragmentação. Aproximadamente 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, E/S de rede, consultas por segundo e latência de leitura/gravação. Nenhuma análise de consultas, nenhum perfilamento, nenhuma detecção de consultas lentas, nenhuma recomendação de índice.
Não conseguimos nem determinar quantas operações foram executadas a partir desse painel.
Ambiente e metodologia de teste
Executamos as três ferramentas em configurações idênticas para garantir uma comparação justa. Cada teste utilizou:
- 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.
Os três fornecedores exigem que você instale o agente base deles antes de adicionar integrações específicas, como o MongoDB. Nós concluímos essa etapa previamente, então nosso teste se concentrou exclusivamente na experiência de integração com o 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 buscando as próximas etapas.
- Consumo de recursos do agente: uso de CPU, memória, E/S de disco e rede durante o estado ocioso e sob carga (inserção de 7 milhões de registros).
- Funcionalidades de monitoramento: Qualidade do painel de controle, 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 grave denominada “MongoBleed” foi divulgada, afetando versões do MongoDB Server anteriores a 8.0.17, 7.0.28, 6.0.27 e anteriores a essa. Essa vulnerabilidade de leitura fora dos limites sem autenticação pode permitir que invasores acessem dados confidenciais na memória. Organizações que utilizam 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.30. 3 4 Ao selecionar ferramentas de monitoramento, certifique-se de que elas suportem métodos de autenticação seguros e não introduzam riscos de segurança adicionais.
Abordamos cada ferramenta como um usuário comum faria, sem ler a documentação previamente e sem nenhum treinamento anterior. Se algo não fosse óbvio na interface, anotávamos.
Veredicto final
Nosso objetivo era responder a uma pergunta simples: qual plataforma de monitoramento facilita a integração com o MongoDB para equipes não técnicas?
Após instalar as três soluções, executar cargas de trabalho idênticas e avaliar os painéis, a resposta ficou clara. Nossa avaliação se baseia na integração básica do Datadog com o MongoDB em janeiro de 2025. Desde então, o Datadog lançou o Database Monitoring (DBM) para MongoDB (dezembro de 2024), que oferece recursos significativamente mais abrangentes, incluindo criação de perfis de consultas, análise de operações lentas, planos de execução e monitoramento de replicação. O produto DBM resolve muitas das limitações identificadas neste benchmark. 5 .
Solarwinds: desenvolvido para monitoramento de banco de dados
A SolarWinds venceu essa comparação de forma decisiva. A plataforma detectou nosso agente imediatamente, nos guiou na configuração das credenciais por meio de comandos de copiar e colar e implantou a integração automaticamente. A configuração levou 5 minutos.
O painel de controle apareceu instantaneamente com informações relevantes. O perfil de consultas mostrou exatamente quais operações consumiram mais recursos. A plataforma capturou todas as 1.400 operações em lote sem perder nenhuma. Quando interrompemos o MongoDB, o SolarWinds detectou a falha em 40 segundos.
A aba Consultas permite filtrar por erros, índices ausentes, respostas lentas e avisos, recursos que auxiliam diretamente na otimização do banco de dados. Esperava-se que o recurso Consultores fornecesse recomendações (embora não tenhamos gerado dados suficientes para acioná-las durante nosso teste).
A Solarwinds se concentrou no que os administradores de banco de dados realmente precisam: análise de consultas, criação de perfis de desempenho e insights acionáveis.
New Relic: Perdido na Configuração
A configuração do New Relic levou 15 minutos, mas o tempo não era o principal problema. A plataforma fazia perguntas na ordem errada, exigia verificação manual de itens que o agente podia verificar automaticamente e nos obrigava a instalar pacotes manualmente.
A confusão com o painel de controle piorou as coisas. Instalamos o monitoramento do MongoDB, mas selecionar o painel padrão resultou em uma tela em branco. Só depois de vasculhar os arquivos de configuração é que percebemos que tínhamos selecionado o tipo de integração errado. Um usuário comum não conseguiria descobrir isso.
Quando os dados finalmente apareceram, as métricas estavam erradas. O New Relic reportou 11.670 inserções após termos realizado 1.400 operações em lote, totalizando 7 milhões de registros. A plataforma subestimou o número em uma ordem de magnitude.
Mais importante ainda, o New Relic não forneceu nenhuma análise em nível de consulta. Sem criação de perfis, sem detecção de consultas lentas, sem identificação de índices ausentes. Para a resolução de problemas em bancos de dados, essas omissões são cruciais.
Datadog: Trabalho manual necessário
O Datadog exigiu mais de 20 minutos de configuração e a maior parte da configuração foi manual. Editamos os arquivos YAML, definimos onde colocá-los e reiniciamos os serviços pela linha de comando.
O painel de controle apareceu automaticamente, mas não exibia nada. A configuração de descoberta automática usava um padrão que não correspondia ao nosso banco de dados. Depois de corrigir o padrão e os erros de indentação do YAML, os dados foram finalmente preenchidos.
O próprio painel de controle mostrou-se mal projetado para uma instância única do MongoDB. Sessenta por cento da tela estava vazia, com seções para recursos de fragmentação e conjuntos de réplicas que não estávamos utilizando. Os 40% restantes ofereciam métricas básicas: tempo de atividade, memória, E/S de rede, consultas por segundo e latência.
Sem análise de consultas. Sem criação de perfis. Sem recomendações de otimização. Não conseguimos determinar com precisão a quantidade de operações no painel de controle.
Sem análise de consultas. Sem criação de perfis. Sem recomendações de otimização. Não conseguimos determinar com precisão a quantidade de operações no painel de controle.
Atualização Crítica (Dezembro de 2024) : Após a conclusão deste benchmark, a Datadog lançou o Database Monitoring (DBM) para MongoDB, o que altera significativamente esta avaliação. O DBM para MongoDB agora oferece:
- Análise de operações lentas com exemplos de consultas detalhadas
- Explique os planos para otimização de consultas.
- Monitoramento do estado de replicação e visualização da integridade do cluster
- Análises a nível operacional 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 com o MongoDB testada neste benchmark e inclui muitos dos recursos de análise em nível de consulta que estavam ausentes durante nossos testes. 6 7 Organizações que avaliam o Datadog para monitoramento do MongoDB devem avaliar especificamente o produto de Monitoramento de Banco de Dados, 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
O SolarWinds abriu com uma janela modal perguntando o que você deseja monitorar. Você escolhe "desempenho do banco de dados", seleciona 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 diretamente na tela de seleção. Em seguida, fornece três comandos para copiar e colar no MongoDB, gerencia as credenciais e confirma a implantação. Cinco minutos, do início ao fim.
O New Relic levou quinze minutos para configurar, e o tempo nem era o problema real. A interface ficava 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 instalado no servidor. Em um dado momento, ele sugeriu comandos de instalação do Amazon Linux, mesmo estando claramente usando Ubuntu. O passo que finalmente arruinou a experiência: existem duas opções de integração com o MongoDB no catálogo do painel, uma padrão e outra baseada em Prometheus, e nada na interface do usuário as diferencia. Selecionamos a errada, o painel ficou vazio e só descobrimos o problema depois de vasculhar os arquivos de configuração.
O Datadog exigiu mais de vinte minutos de edição de YAML, adivinhação de caminhos de arquivos e reinicialização de serviços pela linha de comando. A documentação oferecida durante a configuração não é um guia; é um manual de referência completo que abrange instâncias independentes, 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 exibia estatísticas de fragmentação e métricas de conjuntos de réplicas. Não tínhamos nenhuma das duas. Cerca de sessenta por cento da tela estava vazia.
Precisão métrica sob carga
O SolarWinds contabilizou 1.400. Exatamente correto. O New Relic reportou 11.670, um valor errado por uma ordem de magnitude, sem explicação aparente, e não detectou um pico de memória durante o teste. Quando interrompemos o serviço do MongoDB, o SolarWinds detectou a falha em trinta a quarenta segundos.
Em relação ao consumo de recursos: o New Relic utilizou cerca de 90 MB de RAM, o Datadog cerca de 330 MB e o SolarWinds cerca de 500 MB em nosso servidor de 16 GB. O SolarWinds realizou aproximadamente quarenta vezes mais leituras de disco do que o New Relic, provavelmente devido ao trabalho de criação de perfis de consultas locais. Para a maioria dos ambientes, nada disso influenciará sua decisão.
A característica que realmente os diferencia
Toda ferramenta de monitoramento vai te dizer que algo está lento. A questão é se ela te diz o porquê .
O SolarWinds oferece criação de perfis em nível de consulta. A guia Profiler mostra exatamente quais padrões de consulta foram executados, 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, contagem de conexões e total de operações. Sem criação de perfis, sem identificação de consultas lentas, sem detecção de índices ausentes. Para confirmar se um banco de dados está ativo e funcionando, é um beco sem saída. Para diagnosticar por que ele está com problemas, é um beco sem saída.
Observação: Após nossos testes, a Datadog lançou um produto de monitoramento de banco de dados para MongoDB em dezembro de 2024, que adiciona análise de operações lentas , planos de execução e visibilidade em nível de consulta. Testamos a integração padrão, que continua sendo a primeira que a maioria dos usuários encontra.
SolarWinds : Se a otimização de banco de dados é sua principal preocupação, esta plataforma oferece métricas precisas, configuração rápida e é a única que não apenas informa se uma consulta está lenta, mas também o que fazer para resolvê-la.
New Relic : Se você já o utiliza para APM e precisa de informações básicas sobre a saúde do banco de dados no mesmo lugar, rastrear uma requisição lenta desde o navegador, passando pelo código, até a chamada ao banco de dados é realmente útil. Não confie apenas nele para obter contagens precisas de operações.
Datadog : Se você se sente confortável com a configuração manual e deseja uma plataforma única para uma infraestrutura complexa, as mais de 600 integrações justificam a complexidade da configuração inicial para a equipe certa.
Links de referência
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios.