🥇Não é apenas New Relic: uma olhada em Datadog e Atatus

No ambiente dos engenheiros de SRE/DevOps, não será surpresa para ninguém que um dia apareça um cliente (ou um sistema de monitoramento) e relate que “está tudo perdido”: o site não funciona, os pagamentos não são efetuados, a vida está decaindo ... Não importa o quanto você gostaria de ajudar em tal situação, pode ser muito difícil fazer isso sem uma ferramenta simples e compreensível. Muitas vezes o problema está oculto no próprio código do aplicativo; você só precisa localizá-lo.

E na tristeza e na alegria…

Acontece que há muito que nos apaixonamos profundamente pela New Relic. Foi e continua sendo uma excelente ferramenta para monitorar o desempenho de aplicações, e também permite instrumentar a arquitetura de microsserviços (usando seu agente) e muito, muito mais. E tudo poderia ter sido ótimo se não fossem as mudanças na política de preços do serviço: custar com anos 2013 cresceu mais de 3 vezes. Além disso, desde o ano passado, a obtenção de uma conta experimental requer comunicação com um gestor pessoal, o que dificulta a apresentação do produto a um potencial cliente.

A situação usual: a New Relic não é necessária “permanentemente”; eles se lembram dela apenas no momento em que os problemas começam. Mas você ainda precisa pagar regularmente (140 USD por servidor por mês) e, em uma infraestrutura em nuvem com escalabilidade automática, as somas são bastante grandes. Embora exista uma opção pré-paga, a ativação do New Relic exigirá que você reinicie o aplicativo, o que pode levar à perda da situação problemática para a qual tudo foi iniciado. Não muito tempo atrás, a New Relic introduziu um novo plano tarifário - Essenciais, - que à primeira vista parece uma alternativa razoável ao Profissional... mas após um exame mais detalhado descobriu-se que faltam algumas funções importantes (em particular, não tem Principais transações, Rastreamento entre aplicativos, Rastreamento distribuído).

Com isso, começamos a pensar em buscar uma alternativa mais barata, e nossa escolha recaiu sobre dois serviços: Datadog e Atatus. Por que neles?

Sobre concorrentes

Deixe-me dizer desde já que existem outras soluções no mercado. Até consideramos opções Open Source, mas nem todo cliente tem capacidade livre para hospedar soluções auto-hospedadas... - além disso, exigirão manutenção adicional. O casal que escolhemos acabou sendo o mais próximo nossas necessidades:

suporte integrado e desenvolvido para aplicações PHP (a pilha de nossos clientes é muito diversificada, mas é um claro líder no contexto de busca por uma alternativa ao 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 do New Relic é uma vantagem notável (porque nossos engenheiros estão acostumados com isso).

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

Tideways, AppDynamics e Dynatrace – por custo;
Stackify está bloqueado na Federação Russa e mostra poucos dados.

O resto do artigo está estruturado de tal forma que as soluções em questão serão primeiro apresentadas brevemente, após o que falarei sobre a nossa típica interação com a New Relic e a experiência/impressões da realização de operações semelhantes em outros serviços.

Apresentação dos concorrentes selecionados

Про New Relic, provavelmente todo mundo já ouviu falar? Este serviço iniciou o seu desenvolvimento há mais de 10 anos, em 2008. Temos usado ativamente desde 2012 e não tivemos problemas na integração de um grande número de aplicações em PHP, Ruby e Python, e também tivemos experiência na integração com C# e Go. Os autores do serviço possuem soluções para monitorar aplicativos, infraestrutura, rastrear infraestruturas de microsserviços, criar aplicativos convenientes para dispositivos de usuários e muito mais.

No entanto, o agente New Relic é executado em protocolos proprietários e não oferece suporte a OpenTracing. A instrumentação avançada requer edições específicas para New Relic. Finalmente, o suporte ao Kubernetes ainda é experimental.

Iniciou seu desenvolvimento em 2010 Datadog parece visivelmente mais interessante que o New Relic precisamente em termos de uso em ambientes Kubernetes. Em particular, ele suporta integração com protocolos NGINX Ingress, coleta de log, statsd e OpenTracing, que permite rastrear uma solicitação do usuário desde o momento em que ela é conectada até a conclusão, bem como encontrar logs para essa solicitação (ambos no lado do servidor web e no consumidor).

Ao usar o Datadog, descobrimos que às vezes ele construía o mapa de microsserviço incorretamente e algumas deficiências técnicas. Por exemplo, ele identificou incorretamente o tipo de serviço (confundindo Django com um serviço de cache) e causou 500 erros em um aplicativo PHP usando a popular biblioteca Predis.

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

Uma desvantagem significativa é que ele suporta apenas Node.js e PHP. Por outro lado, é implementado visivelmente melhor que o Datadog. Ao contrário deste último, o Atatus não exige que os aplicativos façam modificações ou adicionem rótulos adicionais ao código.

Como trabalhamos com a New Relic

Agora vamos descobrir como geralmente usamos o New Relic. Digamos que temos um problema que precisa de solução:

É fácil ver no gráfico pico - Vamos analisar. No New Relic, as transações web são imediatamente selecionadas para uma aplicação web, todos os componentes são indicados no gráfico de desempenho, existem painéis de taxa de erro, taxa de solicitação... O mais importante é que diretamente desses painéis você pode mover-se entre diferentes partes do aplicativo (por exemplo, clicar em MySQL levará à seção de banco de dados).

Como no exemplo em consideração vemos um aumento na atividade PHP, clique neste gráfico e vá automaticamente para Transações:

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

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

Além disso, você pode expandir cada transação e ver o que a aplicação estava fazendo no momento em que o código foi executado:

Por fim, a aplicação armazena exemplos de rastreamentos de solicitações longas (aquelas que demoram mais de 2 segundos). Aqui está o painel para uma transação longa:

Percebe-se que dois métodos demoram muito e, ao mesmo tempo, também são mostrados o horário em que a solicitação foi executada, seu URI e domínio. Muitas vezes isso ajuda a encontrar a solicitação nos logs. Vou Detalhes do rastreamento, você pode ver de onde esses métodos são chamados:

E em Consultas de banco de dados — avalia consultas a bancos de dados que foram executadas enquanto o aplicativo estava em execução:

Munidos desse conhecimento, podemos avaliar por que o aplicativo está ficando lento e trabalhar com o desenvolvedor para encontrar uma estratégia para resolver o problema. Na realidade, a New Relic nem sempre dá uma imagem clara, mas ajuda a escolher o vetor de investigação:

longo PDO::Construct nos levou ao estranho funcionamento do pgpoll;
instabilidade ao longo do tempo Memcache::Get sugeriu que a máquina virtual estava configurada incorretamente;
um aumento suspeito no tempo de processamento do modelo levou a um loop aninhado que verificava a presença de 500 avatares no armazenamento de objetos;
etc ...

Acontece também que ao invés de executar código, algo relacionado ao armazenamento externo de dados cresce na tela principal - e não importa o que seja: Redis ou PostgreSQL - ficam todos escondidos na aba Bases de dados.

Você pode selecionar uma base específica para pesquisa e ordenar consultas - semelhante a como é feito em Transações. E acessando a aba de solicitações, você pode ver quantas vezes essa solicitação ocorre em cada um dos controladores da aplicação, e também estimar com que frequência ela é chamada. É muito confortável:

A guia contém dados semelhantes Serviços externos, que oculta solicitações para serviços HTTP externos, como acesso ao armazenamento de objetos, envio de eventos para sentinela ou similares. O conteúdo da aba é completamente semelhante ao de Bancos de dados:

Concorrentes: oportunidades e impressões

Agora o mais interessante é comparar as capacidades da New Relic com o que os concorrentes oferecem. Infelizmente, não foi possível testar todas as três ferramentas em uma versão de um aplicativo em execução em produção. No entanto, procurámos comparar situações/configurações o mais idênticas possível.

1. Cão de dados

Datadog nos cumprimenta com um painel com parede de serviços:

Ele tenta dividir aplicativos em componentes/microsserviços, então no exemplo do aplicativo Django veremos 2 conexões com PostgreSQL (defaultdb и postgres), bem como aipo, Redis. Trabalhar com o Datadog exige que você tenha um conhecimento mínimo dos princípios MVC: você precisa entender de onde geralmente vêm as solicitações dos usuários. Isso geralmente ajuda mapa de serviços:

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

... e o mapa deles, na minha opinião, fica mais simples e claro: não exibe os componentes de uma aplicação (o que o tornaria excessivamente detalhado, como no caso do Datadog), mas apenas serviços ou microsserviços específicos.

Voltemos ao Datadog: no mapa de serviço podemos ver que as solicitações dos usuários chegam ao Django. Vamos ao serviço Django e finalmente ver o que esperávamos:

Infelizmente, não há gráfico aqui por padrão Tempo de transação na web, semelhante ao que vemos no painel principal do New Relic. No entanto, pode ser configurado no lugar da programação % de tempo gasto. Basta mudar para Tempo médio por solicitação por tipo... e agora o gráfico familiar está olhando para nós!

Por que o Datadog escolheu um gráfico diferente é um mistério para nós. Outra coisa frustrante é que o sistema não lembra a escolha do usuário (ao contrário de ambos os concorrentes) e, portanto, a única solução é criar painéis personalizados.

Mas fiquei satisfeito com a capacidade do Datadog de passar desses gráficos para as métricas de servidores relacionados, ler os logs e avaliar a carga nos manipuladores do servidor web (Gunicorn). Tudo é quase igual ao New Relic... e até um pouco mais (logs)!

Abaixo dos gráficos estão transações completamente semelhantes à New Relic:

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

Você pode ampliar o recurso e ver tudo o que já observamos no New Relic:

Existem estatísticas sobre o recurso, uma lista generalizada de chamadas internas e exemplos de solicitações que podem ser classificadas por código de resposta... A propósito, nossos engenheiros gostaram muito dessa classificação.

Qualquer exemplo de recurso no Datadog pode ser aberto e estudado:

São apresentados parâmetros de solicitação, um gráfico resumo do tempo gasto em cada componente e um gráfico em cascata mostrando a sequência de chamadas. Você também pode alternar para uma visualização em árvore do gráfico em cascata:

E o mais interessante é visualizar a carga do host em que a requisição foi executada e visualizar os logs da requisição.

Ótima integração!

Você pode se perguntar onde estão as guias Bases de dados и Serviços externos, como em Nova Relíquia. Não há nenhum aqui: como o Datadog decompõe a aplicação em componentes, o PostgreSQL será considerado um serviço separado, e em vez de Serviços Externos vale a pena procurar aws.storage (será semelhante para todos os outros serviços externos que o aplicativo pode acessar).

Aqui está um exemplo com postgres:

Essencialmente, há tudo o que queríamos:

Você pode ver de qual “serviço” veio a solicitação.

Não seria errado lembrar que o Datadog se integra perfeitamente ao NGINX Ingress e permite realizar rastreamento ponta a ponta a partir do momento em que uma solicitação chega ao cluster, além de permitir receber métricas de statsd, coletar logs e hospedar métricas .

Uma grande vantagem do Datadog é que seu preço está dando forma desde monitoramento de infraestrutura, APM, gerenciamento de log e teste sintético, ou seja, Você pode escolher seu plano com flexibilidade.

2.Atatus

A equipe da Atatus afirma que seu serviço é “igual ao New Relic, mas melhor”. Vamos ver se isso é realmente assim.

O painel principal é semelhante, mas não foi possível determinar o Redis e o memcached usados na aplicação.

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

Nas transações da Atatus, tudo é o mais parecido possível com o New Relic. A desvantagem é que a dinâmica de cada controlador não é imediatamente visível. Você tem que procurá-lo na tabela do controlador, classificando por Mais tempo consumido:

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

De certa forma, esta tabela lembra o Datadog e gosto mais dela do que da semelhante no New Relic.

Você pode expandir cada transação e ver o que o aplicativo estava fazendo:

O painel também lembra mais o Datadog: há uma série de solicitações, um quadro geral de ligações. O painel superior fornece uma guia de erro Falhas HTTP e exemplos de consultas lentas Rastreamentos de sessão:

Se você for para uma transação, poderá ver um exemplo de rastreamento, poderá obter uma lista de solicitações ao banco de dados e observar os cabeçalhos das solicitações. Tudo é semelhante ao New Relic:

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

No entanto, falta um filtro que (como o New Relic) cortaria solicitações ultrarrápidas (<5ms). Por outro lado, gostei da exibição da resposta final da transação (sucesso ou erro).

Painel Bases de dados irá ajudá-lo a estudar as solicitações a bancos de dados externos que a aplicação faz. Deixe-me lembrá-lo de que a Atatus encontrou apenas PostgreSQL e 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 mencionar a aba com as consultas mais lentas - é muito conveniente. Além disso, os dados nesta aba do PostgreSQL coincidiram com os dados da extensão pg_stat_statements - excelente resultado!

Inserção Solicitações Externas completamente idêntico aos bancos de dados.

Descobertas

Ambas as ferramentas apresentadas tiveram um bom desempenho na função de APM. Qualquer um deles pode oferecer o mínimo exigido. Nossas impressões podem ser brevemente resumidas da seguinte forma:

Datadog

Prós:

programação tarifária conveniente (APM custa 31 USD por host);
funcionou bem com Python;
Possibilidade de integração com OpenTracing
integração com Kubernetes;
integração com NGINX Ingress.

Contras:

o único APM que fez com que a aplicação ficasse indisponível por erro de módulo (predis);
instrumentação automática de PHP fraca;
definição parcialmente estranha de serviços e sua finalidade.

Atato