Monitoramento: MongoDB vs New Relic vs Datadog
Instalamos o SolarWinds, o Datadog e o New Relic em sistemas limpos executando o MongoDB 7.0 para teste. Passamos pelo processo completo de configuração de cada ferramenta, documentando cada etapa e obstáculo encontrado.
MongoDB Resultados de benchmark das ferramentas de monitoramento de desempenho
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 de monitoramento MongoDB
- SolarWinds concluiu a configuração em 5 minutos com detecção automática e forneceu perfis em nível de consulta que os outros 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 integração com o Solarwinds foi concluída em menos de 5 minutos. O Solarwinds abre com uma janela modal simples: "O que você deseja monitorar?". Ao selecionar o desempenho do banco de dados , a plataforma exibe os bancos de dados compatíveis.
Após selecionar MongoDB, o Solarwinds verifica se já existem agentes.
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, SolarWinds solicita as credenciais de 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 apresentou três comandos de banco de dados para executar. Cada comando tinha um botão de copiar. Executamos os comandos em MongoDB e clicamos em “Observar Banco de Dados”.
Foi aqui que a Solarwinds nos impressionou. Em vez de nos pedir para resolvermos problemas de permissões, ela forneceu comandos prontos para 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 a observabilidade SolarWinds com monitoramento profundo MongoDB e criação de perfis de consultas. Explore 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 a MongoDB.
Após selecionar 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 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 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 (MongoDB) para criar o usuário de monitoramento. Os comandos eram claros, com atribuições de função adequadas (clusterMonitor e readAnyDatabase). Também foi necessário 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 para Integrações e pesquisamos por “mongo”. Clicamos em MongoDB e uma janela modal apareceu.
A visão geral mostrava o que o monitoramento MongoDB inclui, mas clicar em “Instalar integração” apenas abriu outra tela com instruções complexas.
Foi aqui que o Datadog nos surpreendeu. A tela exibia um guia de referência completo, abrangendo todos os cenários possíveis: 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 de MongoDB, a quantidade de texto pareceu excessiva.
Percorremos a página procurando os passos básicos:
- Criar um usuário de monitoramento em MongoDB
- Edite o arquivo YAML de configuração.
- Reinicie o agente Datadog.
O Datadog forneceu os comandos MongoDB para criar o usuário, o que foi útil. Mas, quando se tratava do arquivo YAML, a documentação dizia para editar conf.yaml sem especificar claramente onde esse arquivo deveria ser inserido.
Sabíamos por experiência que o arquivo deveria estar em /etc/datadog-agent/conf.d/mongo.d/ , mas as instruções esconderam esse detalhe em algum lugar na documentação.
Criamos o usuário 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 Painéis e encontramos MongoDB métricas começando a ser exibidas.
2. Consumo de Recursos do Agente
Monitoramos a quantidade de recursos que cada agente consumiu durante a execução. O teste durou aproximadamente 10 minutos, com os três agentes coletando dados simultaneamente da mesma instância MongoDB sob carga.
Submetemos o sistema a um teste de estresse, inserindo 2 milhões de registros em MongoDB usando 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 agente 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 devido aos seus recursos de criação de perfis de consulta.
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 MongoDB. Um clique e um painel completo apareceu.
A parte superior da tela mostrava o status de saúde do serviço (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 "Detalhamento dos 10 principais serviços" 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 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 MongoDB. Já havíamos 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 mostrava métricas em nível de host, juntamente com estatísticas de MongoDB, CPU, memória, disco e rede. Esse contexto ajuda a distinguir entre problemas de banco de dados e problemas de infraestrutura subjacentes.
A aba "Consultores" 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.
Atualizações de IA : Em outubro de 2025, a SolarWinds lançou o Agente de IA com o recurso Assistente de Consultas de IA (atualmente em versão prévia técnica). O Assistente de Consultas de IA analisa padrões de consultas ao banco de dados e propõe reescritas otimizadas para melhorar o desempenho automaticamente. O Assistente de Causa Raiz (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 Agente de IA em todo o portfólio da SolarWinds está planejada para 2026. 1 2 .
Painel do New Relic
Fomos à seção Painéis, mas nenhum painel MongoDB apareceu automaticamente.
Pesquisamos por “mongo” no catálogo do painel de controle e encontramos duas opções MongoDB.
Selecionamos o painel de controle padrão MongoDB e clicamos em “Configurar 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 o 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, o New Relic exibiu duas opções `MongoDB`, uma das quais era a versão do Prometheus. Nada na interface indicava que se tratava de uma integração diferente, então jamais me ocorreria que eu havia selecionado a do 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 “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 diretamente o banco de dados MongoDB (“Quantos documentos você tem?”). Mas a contagem da consulta 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 foi possível visualizar o uso de CPU, memória, disco ou rede do servidor que executava MongoDB. 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 comando datadog-agent check mongo para depurar o problema. O arquivo de configuração apresentava um erro de indentação. A exigência de formatação rigorosa do YAML nos pegou de surpresa. Após corrigir o erro e executar novamente o 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 Edição Comunitária
- 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 deles antes de adicionar integrações específicas, como MongoDB. Nós concluímos essa etapa previamente, então nosso teste se concentrou exclusivamente na experiência de integração com 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 servidor MongoDB 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 da 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 torna a integração do MongoDB mais fácil 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 para 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
SolarWinds venceu esta comparação de forma decisiva. A plataforma detectou imediatamente nosso agente, 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 a operação MongoDB, a operaçã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 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. 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 usando. 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 Monitoramento de Banco de Dados (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 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 As organizações que avaliam o Datadog para monitoramento de 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 processo SolarWinds abriu com uma janela modal perguntando o que você deseja monitorar. Você seleciona “desempenho do banco de dados”, escolhe 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, ela fornece três comandos para copiar e colar para executar em 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 do 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 serviço SolarWinds contabilizou 1.400. Exatamente. 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 uso de memória durante o teste. Quando interrompemos o serviço MongoDB, o serviç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 perfil 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ê .
A versão SolarWinds oferece perfilamento 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 do 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 a respeito.
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.