🔣 📅 👩🏻‍🍳 Not New Relic's One: Um olhar sobre Datadog e Atatus 🥂 🚶🏽 ⌛️

No ambiente dos engenheiros do SRE- / DevOps, você não ficará surpreso que um dia um cliente (ou sistema de monitoramento) apareça e diga que “tudo está perdido”: o site não funciona, os pagamentos não passam, a vida é decadente ... Não importa como eu gostaria de ajudar nessa situação Pode ser muito difícil fazer isso sem uma ferramenta simples e compreensível. Muitas vezes, o problema está oculto no código do próprio aplicativo - você só precisa localizá-lo.

E na dor e na alegria ...

Aconteceu que nós gostamos muito da New Relic. Ele tem sido e continua sendo uma excelente ferramenta para monitorar o desempenho do aplicativo e também permite instrumentar a arquitetura de microsserviço (usando seu agente) e muito, muito mais. E tudo poderia ser maravilhoso, se não fosse pelas mudanças na política de preços do serviço: seu custo aumentou mais de 3 vezes desde 2013 . Além disso, desde o ano passado, a obtenção de uma conta de teste requer comunicação com um gerente pessoal, o que dificulta a apresentação do produto a um cliente em potencial.

A situação usual: a New Relic não é necessária “de forma contínua”, é lembrada apenas no momento em que os problemas começaram. Mas você ainda precisa pagar regularmente (140 USD por servidor por mês) e, na infraestrutura de nuvem escalável automaticamente, os valores são bastante grandes. Embora exista a possibilidade de "pagamento conforme o uso", mas para ativar o New Relic, você precisará reiniciar o aplicativo, o que pode levar à perda da situação do problema para o qual tudo foi iniciado. Há pouco tempo, a New Relic introduziu um novo plano tarifário - o Essentials , que à primeira vista parece uma alternativa razoável ao Professional ... mas, após uma análise mais aprofundada, constatou que algumas das funções importantes estão ausentes (em particular, ele não possui transações principais , rastreamento de aplicativos cruzados , rastreamento distribuído ) .

Como resultado, pensamos em encontrar uma alternativa mais barata e nossa escolha recaiu nos dois serviços Datadog e Atatus. Por que exatamente neles?

Sobre concorrentes

Devo dizer imediatamente que existem outras soluções no mercado. Nós até consideramos as opções de código aberto, mas nem todo cliente tem capacidade livre para hospedar soluções auto-hospedadas ... - além disso, elas exigirão manutenção adicional. O casal que selecionamos acabou sendo o mais próximo de nossas necessidades :

suporte interno e desenvolvido para aplicativos PHP (a pilha de nossos clientes é muito diversificada, mas é um líder claro no contexto de encontrar uma alternativa para a New Relic);
custo acessível (menos de 100 USD por mês por host);
instrumentação automática;
Integração com Kubernetes
A semelhança com a interface New Relic é uma vantagem notável (porque nossos engenheiros estão acostumados a isso).

Portanto, na fase da seleção inicial, eliminamos várias outras soluções populares e, em particular:

Tideways, AppDynamics e Dynatrace - pelo preço;
Stackify - está bloqueado na Federação Russa e mostra poucos dados.

O artigo subseqüente está estruturado de tal maneira que as soluções em consideração serão apresentadas brevemente, após o que falarei sobre nossa interação típica com a New Relic e a experiência / impressões de realizar operações semelhantes em outros serviços.

Apresentação de concorrentes selecionados

Provavelmente todo mundo já ouviu falar sobre a New Relic ? Este serviço iniciou seu desenvolvimento há mais de 10 anos, em 2008. Nós o usamos ativamente desde 2012 e não tivemos problemas de integração com um número realmente grande de aplicativos em PHP, Ruby e Python, e também tivemos experiência na integração com C # e Go. Os autores do serviço têm soluções para monitorar o aplicativo, infraestrutura, rastreamento de infraestruturas de microsserviço, aplicativos convenientes para dispositivos do usuário foram criados e muito mais.

No entanto, o agente New Relic trabalha em protocolos proprietários, não possui suporte ao OpenTracing. A instrumentação avançada requer edições específicas para a New Relic. Finalmente, o suporte ao Kubernetes tem status experimental até o momento.

O Datadog , que iniciou seu desenvolvimento em 2010, parece visivelmente mais interessante que o New Relic em termos de uso em ambientes Kubernetes. Em particular, ele suporta a integração com os protocolos NGINX Ingress, coleção de logs, statsd e OpenTracing, que permitem rastrear uma solicitação do usuário a partir do momento em que ela é conectada ao final do trabalho, além de encontrar registros para essa solicitação (no lado do servidor da Web e no lado consumidor).

Ao usar o Datadog, fomos confrontados com o fato de que às vezes ele criava incorretamente um mapa de microsserviço e algumas falhas técnicas. Por exemplo, ele determinou incorretamente o tipo de serviço (ele levou o Django para o serviço de cache) e causou os 500º erros em um aplicativo PHP usando a popular biblioteca Predis.

Atatus é o instrumento mais jovem; serviço lançado em 2014. Seu orçamento de marketing é claramente inferior aos concorrentes listados, as menções são muito menos comuns. No entanto, a ferramenta em si é muito semelhante à New Relic, e não apenas em recursos (APM, monitoramento de navegador, etc.), mas também na aparência.

Uma desvantagem significativa é apenas o suporte ao Node.js e PHP. Por outro lado, é implementado muito melhor que o Datadog. Diferentemente do último, o Atatus não requer que os aplicativos modifiquem ou definam tags adicionais no código.

Como trabalhamos com a New Relic

Agora vamos descobrir como geralmente usamos a New Relic. Suponha que tenhamos um problema que precisa ser resolvido:

É fácil notar um aumento no gráfico - nós o analisamos. Na New Relic, as transações da Web são imediatamente selecionadas para o aplicativo da Web, todos os componentes são indicados no gráfico de desempenho, existem painéis com taxa de erro e taxa de solicitação ... Mais importante, diretamente desses painéis, você pode mover-se entre diferentes partes do aplicativo (por exemplo, clicar em MySQL na seção do banco de dados).

Como neste exemplo vemos um aumento na atividade do PHP , clique neste gráfico e vá automaticamente para Transações :

A lista de transações, que são essencialmente controladoras do modelo MVC, já está classificada por Mais demorado , o que é muito conveniente: vemos imediatamente o que o aplicativo faz. Aqui estão exemplos de consultas longas que são coletadas automaticamente pela New Relic. É fácil encontrar a classificação de alternância:

o controlador de aplicativo mais carregado;
O controlador solicitado com mais frequência
o mais lento dos controladores.

Além disso, você pode expandir cada transação e ver o que o aplicativo estava fazendo no momento da execução do código:

Por fim, exemplos de rastreamentos longos de consulta (que funcionam por mais de 2 segundos) são salvos no aplicativo. Aqui está o painel para uma transação longa:

Pode-se observar que dois métodos levam muito tempo e, quando o pedido é executado, seu URI e domínio também são mostrados. Muitas vezes, isso ajuda a encontrar a consulta nos logs. Indo para os detalhes do Rastreio , você pode ver de onde esses métodos são chamados:

E em consultas ao banco de dados - avalie as consultas ao banco de dados que foram executadas no momento do aplicativo:

Armado com esse conhecimento, podemos avaliar a causa da desaceleração do aplicativo e, juntamente com o desenvolvedor, desenvolver uma estratégia para resolver o problema. Na realidade, a New Relic nem sempre fornece uma imagem clara, mas ajuda a escolher o vetor da investigação:

o longo PDO::Construct nos levou ao estranho funcionamento do pgpoll;
instabilidade no tempo Memcache::Get configuração incorreta da máquina virtual;
o tempo suspeito de aumentar o processamento do modelo levou a um loop aninhado com uma verificação da presença de 500 avatares no armazenamento de objetos;
e assim por diante ...

Também acontece que, em vez de executar o código na tela principal, algo relacionado ao armazenamento externo de dados cresce - e não importa o que seja: Redis ou PostgreSQL - todos eles estão ocultos na guia Bancos de dados .

Você pode selecionar uma base específica para a pesquisa e classificar as consultas - semelhante à maneira como isso é feito nas transações. E, indo para a guia request, você pode ver o quanto essa solicitação é encontrada em cada um dos controladores de aplicativos, bem como avaliar com que frequência é chamada. Isso é muito conveniente:

A guia Serviços Externos contém dados semelhantes, que ocultam solicitações de serviços HTTP externos, como acessar o armazenamento de objetos, enviar eventos para sentinela ou algo semelhante. Por seu conteúdo, a guia é completamente semelhante a Bancos de dados:

Concorrentes: oportunidades e impressões

Agora, o mais interessante é comparar os recursos da New Relic com o que os concorrentes oferecem. Infelizmente, não conseguimos testar as três ferramentas na mesma versão de um aplicativo em execução na produção. No entanto, tentamos comparar as situações / configurações mais idênticas.

1. Datadog

O Datadog nos recebe com um painel com uma parede de serviços:

Ele está tentando dividir aplicativos em componentes / microsserviços, portanto, no aplicativo Django de exemplo, vemos duas conexões com o PostgreSQL ( defaultdb e postgres ), além do Celery, Redis. Trabalhar com o Datadog exige que você tenha um conhecimento mínimo dos princípios do MVC: você precisa entender de onde vêm as solicitações do usuário. Geralmente, um mapa de serviço ajuda com isso:

A propósito, há algo semelhante em New Relic:

... além disso, o mapa deles, na minha opinião, é mais simples e compreensível: não exibe os componentes de um aplicativo (o que o tornaria desnecessariamente detalhado, como no caso do Datadog), mas apenas serviços ou microsserviços específicos.

De volta ao Datadog: fica claro no mapa de serviço que as solicitações dos usuários chegam ao Django. Vamos para o serviço Django e, finalmente, ver o que esperávamos:

Infelizmente, por padrão, não existe um gráfico de tempo de transação na Web semelhante ao que vemos no painel principal da New Relic. No entanto, ele pode ser configurado no lugar do gráfico % de tempo gasto . Basta alterá-lo para Tempo médio por solicitação do Tipo ... e agora o gráfico familiar olha para nós!

Por que o Datadog optou por uma programação diferente é um mistério para nós. Também foi frustrante que o sistema não se lembre da escolha do usuário (diferente dos dois concorrentes) e, portanto, apenas a criação de painéis personalizados economiza.

Mas fiquei satisfeito com a oportunidade no Datadog de alternar desses gráficos para as métricas de servidores relacionados, ler os logs e avaliar a carga dos manipuladores de servidores da Web (Gunicorn). Tudo é quase o mesmo que na New Relic ... e até mais alguns (logs)!

Abaixo dos gráficos, há transações completamente semelhantes à New Relic:

No Datadog, as transações são chamadas de recursos . Você pode classificar os controladores pelo número de solicitações, pelo tempo médio de resposta, pelo tempo decorrido máximo por um período selecionado.

Você pode expandir o recurso e ver tudo o que já observamos na New Relic:

Existem estatísticas sobre o recurso, uma lista generalizada de chamadas internas e exemplos de solicitações que podem ser classificadas pelo código de resposta ... Aliás, nossos engenheiros realmente gostaram dessa classificação.

Qualquer recurso de exemplo no Datadog pode ser expandido e explorado:

Os parâmetros de consulta, um diagrama resumido do tempo decorrido para cada um dos componentes e um diagrama em cascata, no qual a sequência de chamadas é visível, são apresentados. Além disso, a mudança para a visualização em árvore do diagrama em cascata também está disponível:

E o mais interessante é visualizar a carga do host no qual a solicitação foi executada e visualizar os logs de solicitação.

Ótima integração!

Você pode se perguntar onde estão as guias Bancos de dados e Serviços externos , como na New Relic. Eles não estão aqui: como o Datadog analisa o aplicativo em componentes, o PostgreSQL será considerado um serviço separado e, em vez de Serviços Externos, vale a pena procurar um aws.storage (será o mesmo para todos os outros serviços externos que o aplicativo possa acessar).

E aqui está um exemplo com o postgres :

De fato, há tudo o que queríamos:

Pode-se ver de qual "serviço" a solicitação veio.

Não será supérfluo lembrar que o Datadog se integra perfeitamente ao NGINX Ingress e permite o rastreamento de ponta a ponta a partir do momento em que uma solicitação chega no cluster, além de permitir a aceitação de métricas de estatísticas, coletar logs e métricas de host.

Uma grande vantagem do Datadog é que seu preço consiste em monitorar a infraestrutura, o APM, o gerenciamento de logs e os testes sintéticos, ou seja, Você pode escolher um plano com flexibilidade.

2. Atatus

A equipe da Atatus afirma que seu serviço é "o mesmo que a New Relic, mas melhor". Vamos ver se é realmente assim.

A barra de título realmente parece a mesma, mas não foi possível determinar os Redis e o memcached usados no aplicativo.

O APM seleciona todas as transações por padrão, embora normalmente apenas a Web seja necessária. Como no Datadog, não há como acessar o serviço desejado no painel principal. Além disso, as transações são listadas após erros, o que para o APM não parece muito lógico.

Nas transações da Atatus, tudo é o mais semelhante possível à New Relic. Menos - você não pode ver imediatamente a dinâmica de cada um dos controladores. Você deve procurá-lo na tabela do controlador, classificando por Mais consumido :

A lista usual de controladores está disponível na guia Explorar :

De certa forma, essa tabela se parece com o Datadog e é mais parecida com a da New Relic.

Cada transação pode ser implantada e ver o que o aplicativo fez:

O painel também se parece mais com o Datadog: há uma série de solicitações, uma visão geral das chamadas. O painel superior fornece uma guia com erros de falhas de HTTP e exemplos de solicitações lentas de rastreamentos de sessão :

Se você entrar em uma transação, poderá ver um exemplo de rastreamento, obter uma lista de consultas no banco de dados e ver os cabeçalhos da solicitação. Tudo é semelhante ao New Relic:

Em geral, a Atatus se satisfaz com traços detalhados - sem a colagem típica de chamadas da New Relic em um bloco de lembrete:

No entanto, não há filtro suficiente que (como na New Relic) interrompa solicitações ultra-rápidas (<5ms). Por outro lado, exibir a resposta final da transação (bem-sucedida ou erro) foi agradável.

O painel Bancos de dados o ajudará a examinar as solicitações de bancos de dados externos que o aplicativo faz. Deixe-me lembrá-lo de que a Atatus encontrou apenas o PostgreSQL e o MySQL, embora Redis e memcached também estejam envolvidos no projeto.

As solicitações são classificadas de acordo com os critérios usuais: frequência de resposta, tempo médio de resposta e assim por diante. Também gostaria de observar a guia com as consultas mais lentas - isso é muito conveniente. Além disso, os dados nesta guia do PostgreSQL coincidiram com os da extensão pg_stat_statements - um excelente resultado!

A guia Solicitações Externas é idêntica aos Bancos de Dados.

Conclusões

Ambas as ferramentas apresentadas tiveram um bom desempenho no papel de APM. Qualquer um deles pode oferecer o mínimo necessário. Resuma brevemente nossas impressões da seguinte maneira:

Datadog

Prós:

tabela tarifária conveniente (APM custa 31 USD por host);
executou bem com Python;
capacidade de integração com o OpenTracing
Integração com Kubernetes
Integração com o NGINX Ingress.

Contras:

O único APM que causou inacessibilidade do aplicativo devido a um erro do módulo (predis)
auto-ferramentas PHP fracas;
definição parcialmente estranha de serviços e sua finalidade.

Atatus