🥇Not New Relic só: unha ollada a Datadog e Atatus

No entorno dos enxeñeiros de SRE/DevOps, non sorprenderá a ninguén que algún día apareza un cliente (ou un sistema de monitorización) que informe de que “todo está perdido”: o sitio non funciona, os pagos non pasan, a vida decae. ... Non importa o que che gustaría axudar nunha situación así, pode ser moi difícil facelo sen unha ferramenta sinxela e comprensible. Moitas veces o problema está oculto no propio código da aplicación; só tes que localizalo.

E na tristeza e na alegría...

Aconteceu que nos namoramos moito e profundamente de New Relic. Foi e segue sendo unha excelente ferramenta para supervisar o rendemento das aplicacións, e ademais permite instrumentar a arquitectura de microservizos (usando o seu axente) e moito máis. E todo podería ser xenial se non fose por cambios na política de prezos do servizo: el custa do ano 2013 creceu máis de 3 veces. Ademais, desde o ano pasado, a obtención dunha conta de proba require a comunicación cun xestor persoal, o que dificulta a presentación do produto a un cliente potencial.

A situación habitual: New Relic non é necesaria de forma "permanente"; só a lembran no momento en que comezan os problemas. Pero aínda ten que pagar regularmente (140 USD por servidor ao mes) e nunha infraestrutura de nube de escala automática as sumas suman bastante grandes. Aínda que hai unha opción Pay-As-You-Go, habilitar New Relic requirirá que reinicie a aplicación, o que pode provocar a perda da situación problemática para a que se iniciou todo. Non hai moito tempo, New Relic presentou un novo plan tarifario: Essentials, - que a primeira vista parece unha alternativa razoable a Professional... pero tras un exame máis detallado resultou que faltan algunhas funcións importantes (en particular, non ten Transaccións clave, Rastrexo cruzado de aplicacións, Rastreo Distribuído).

Como resultado, comezamos a pensar en buscar unha alternativa máis barata e a nosa elección recaeu en dous servizos: Datadog e Atatus. Por que sobre eles?

Sobre os competidores

Déixeme dicir de inmediato que hai outras solucións no mercado. Incluso consideramos opcións de código aberto, pero non todos os clientes teñen capacidade libre para aloxar solucións autoaloxadas... - ademais, necesitarán mantemento adicional. A parella que eliximos resultou ser a máis próxima nosas necesidades:

soporte integrado e desenvolvido para aplicacións PHP (a pila dos nosos clientes é moi diversa, pero este é un claro líder no contexto da busca dunha alternativa a New Relic);
custo accesible (menos de 100 USD por mes por host);
instrumentación automática;
integración con Kubernetes;
A semellanza coa interface New Relic é unha vantaxe notable (porque os nosos enxeñeiros están afeitos).

Polo tanto, na fase de selección inicial, eliminamos outras solucións populares, e en particular:

Tideways, AppDynamics e Dynatrace - por custo;
Stackify está bloqueado na Federación Rusa e mostra moi poucos datos.

O resto do artigo estrutúrase de tal xeito que primeiro se presentarán brevemente as solucións en cuestión, despois de que falarei da nosa interacción típica con New Relic e da experiencia/impresións de realizar operacións similares noutros servizos.

Presentación dos competidores seleccionados

en New Relic, probablemente todos oíron? Este servizo comezou o seu desenvolvemento hai máis de 10 anos, en 2008. Usámolo activamente desde 2012 e non tivemos problemas para integrar un gran número de aplicacións en PHP, Ruby e Python, e tamén temos experiencia na integración con C# e Go. Os autores do servizo dispoñen de solucións para supervisar aplicacións, infraestruturas, rastrexar infraestruturas de microservizos, crear aplicacións convenientes para os dispositivos dos usuarios e moito máis.

Non obstante, o axente New Relic funciona con protocolos propietarios e non admite OpenTracing. A instrumentación avanzada require edicións específicas para New Relic. Finalmente, o soporte de Kubernetes aínda é experimental.

Comezou o seu desenvolvemento en 2010 Datos de datos parece notablemente máis interesante que New Relic precisamente en termos de uso en ambientes Kubernetes. En particular, admite a integración con NGINX Ingress, recollida de rexistros, statsd e protocolos OpenTracing, o que lle permite rastrexar unha solicitude de usuario desde o momento en que está conectada ata a súa finalización, así como atopar rexistros para esta solicitude (ambos no lado do servidor web). e do consumidor).

Ao usar Datadog, atopamos que ás veces construíu o mapa de microservizos de forma incorrecta e algunhas deficiencias técnicas. Por exemplo, identificou erróneamente o tipo de servizo (confundindo Django cun servizo de caché) e provocou 500 erros nunha aplicación PHP usando a popular biblioteca Predis.

Atatus - o instrumento máis novo; o servizo púxose en marcha en 2014. O seu orzamento de mercadotecnia é claramente inferior ao dos competidores listados, as mencións son moito menos comúns. Non obstante, a ferramenta en si é moi similar a New Relic, non só nas súas capacidades (APM, seguimento do navegador, etc.), senón tamén no aspecto.

Un inconveniente importante é que só admite Node.js e PHP. Por outra banda, está implementado notablemente mellor que Datadog. A diferenza deste último, Atatus non require que as aplicacións fagan modificacións nin engadan etiquetas adicionais ao código.

Como traballamos con New Relic

Agora imos descubrir como usamos xeralmente New Relic. Digamos que temos un problema que necesita unha solución:

É doado de ver no gráfico salpicar - Analizámolo. En New Relic, as transaccións web son inmediatamente seleccionadas para unha aplicación web, todos os compoñentes indícanse no gráfico de rendemento, hai paneis de taxa de erro, de solicitudes... O máis importante é que directamente desde estes paneis podes moverte entre diferentes partes da aplicación (por exemplo, facer clic en MySQL levará á sección de base de datos).

Xa que no exemplo en consideración vemos un aumento da actividade PHP, fai clic neste gráfico e vai automaticamente a Transaccións:

A lista de transaccións, que son esencialmente controladores do modelo MVC, xa está ordenada por A maior cantidade de tempo, que é moi cómodo: vemos inmediatamente o que fai a aplicación. Aquí tes exemplos de consultas longas que New Relic recolle automaticamente. Ao cambiar a clasificación, é fácil atopar:

o controlador de aplicacións máis cargado;
controlador máis solicitado;
o máis lento dos controladores.

Ademais, podes ampliar cada transacción e ver o que facía a aplicación no momento en que se executou o código:

Finalmente, a aplicación almacena exemplos de trazos de solicitudes longas (aquelas que tardan máis de 2 segundos). Aquí está o panel para unha transacción longa:

Pódese ver que dous métodos levan moito tempo e, ao mesmo tempo, o momento no que se executou a solicitude, tamén se mostra o seu URI e dominio. Moitas veces isto axuda a atopar a solicitude nos rexistros. Indo a Rastrear detalles, podes ver de onde se chaman estes métodos:

E en Consultas de bases de datos — avaliar consultas a bases de datos que se executaron mentres a aplicación estaba en execución:

Armados con este coñecemento, podemos avaliar por que a aplicación está a desacelerarse e traballar co programador para elaborar unha estratexia para resolver o problema. En realidade, New Relic non sempre dá unha imaxe clara, pero axuda a escoller o vector de investigación:

longo PDO::Construct levounos ao estraño funcionamento de pgpoll;
inestabilidade ao longo do tempo Memcache::Get suxeriu que a máquina virtual estaba configurada incorrectamente;
un tempo sospeitosamente aumentado para o procesamento de modelos levou a un bucle anidado que verificaba a presenza de 500 avatares no almacenamento de obxectos;
etcétera…

Tamén ocorre que en lugar de executar código, algo relacionado co almacenamento de datos externo crece na pantalla principal -e non importa o que será: Redis ou PostgreSQL- están todos ocultos na pestana Bases de datos.

Podes seleccionar unha base específica para investigar e ordenar as consultas, de xeito similar a como se fai en Transaccións. E ao acceder á pestana de solicitudes, podes ver cantas veces se produce esta solicitude en cada un dos controladores de aplicacións e tamén estimar a frecuencia con que se chama. É moi cómodo:

A pestana contén datos similares Servizos Externos, que oculta solicitudes a servizos HTTP externos, como acceder ao almacenamento de obxectos, enviar eventos a centinela ou similares. O contido da pestana é completamente semellante ao de Bases de datos:

Competidores: oportunidades e impresións

Agora o máis interesante é comparar as capacidades de New Relic co que ofrecen os competidores. Desafortunadamente, non puidemos probar as tres ferramentas nunha única versión dunha aplicación que se executa en produción. Non obstante, tentamos comparar situacións/configuracións o máis idénticas posible.

1.Datadog

Datadog recíbenos cun panel cun muro de servizos:

Tenta dividir as aplicacións en compoñentes/microservizos, polo que no exemplo da aplicación Django veremos 2 conexións a PostgreSQL (defaultdb и postgres), así como apio, Redis. Traballar con Datadog require que teñas un coñecemento mínimo dos principios de MVC: debes comprender de onde veñen xeralmente as solicitudes dos usuarios. Isto xeralmente axuda mapa de servizos:

Por certo, hai algo semellante en New Relic:

... e o seu mapa, na miña opinión, faise máis sinxelo e claro: non mostra os compoñentes dunha aplicación (o que o faría demasiado detallado, como no caso de Datadog), senón só servizos ou microservizos específicos.

Volvamos a Datadog: dende o mapa de servizos podemos ver que as solicitudes dos usuarios chegan a Django. Imos ao servizo Django e por fin vexamos o que esperabamos:

Desafortunadamente, non hai ningún gráfico aquí por defecto Tempo de transacción web, semellante ao que vemos no panel principal New Relic. Non obstante, pódese configurar no lugar da programación % do tempo empregado. É suficiente con cambialo Tempo medio por solicitude por tipo... e agora o gráfico familiar está mirando para nós!

Por que Datadog escolleu un gráfico diferente é un misterio para nós. Outra cousa frustrante é que o sistema non lembra a elección do usuario (a diferenza dos dous competidores) e, polo tanto, a única solución é crear paneis personalizados.

Pero quedei satisfeito coa capacidade de Datadog para cambiar destes gráficos ás métricas dos servidores relacionados, ler os rexistros e avaliar a carga dos controladores do servidor web (Gunicorn). Todo é case o mesmo que en New Relic... e incluso un pouco máis (rexistros)!

Debaixo dos gráficos hai transaccións completamente similares a New Relic:

En Datadog, as transaccións son chamadas recursos. Pode ordenar os controladores polo número de solicitudes, polo tempo medio de resposta e polo tempo máximo empregado durante un período de tempo seleccionado.

Podes ampliar o recurso e ver todo o que xa observamos en New Relic:

Hai estatísticas sobre o recurso, unha lista xeralizada de chamadas internas e exemplos de solicitudes que se poden ordenar por código de resposta... Por certo, aos nosos enxeñeiros gustoulles moito esta clasificación.

Calquera recurso de exemplo en Datadog pódese abrir e estudar:

Preséntanse os parámetros de solicitude, un gráfico resumo do tempo dedicado a cada compoñente e un gráfico en cascada que mostra a secuencia de chamadas. Tamén pode cambiar a unha vista en árbore do gráfico de fervenza:

E o máis interesante é ver a carga do host no que se executou a solicitude e ver os rexistros de solicitudes.

Gran integración!

Podes preguntar onde están as pestanas Bases de datos и Servizos Externos, como en New Relic. Non hai ningún aquí: xa que Datadog descompón a aplicación en compoñentes, terase en conta PostgreSQL un servizo separado, e en lugar de Servizos Externos paga a pena buscalo aws.storage (será similar para todos os outros servizos externos aos que poida acceder a aplicación).

Aquí tes un exemplo con postgres:

En esencia, hai todo o que queriamos:

Podes ver de que "servizo" procede a solicitude.

Non estaría mal lembrar que Datadog se integra perfectamente con NGINX Ingress e permite realizar un rastrexo de extremo a extremo desde o momento en que chega unha solicitude ao clúster, ademais de recibir métricas estatísticas, recoller rexistros e métricas de host. .

Unha gran vantaxe de Datadog é que o seu prezo desenvólvese desde a vixilancia de infraestruturas, APM, Xestión de rexistros e proba de sintéticos, é dicir. Podes escoller o teu plan de forma flexible.

2.Atatus

O equipo de Atatus afirma que o seu servizo é "o mesmo que New Relic, pero mellor". A ver se isto é realmente así.

O panel principal parece semellante, pero non foi posible determinar o Redis e o memcached utilizados na aplicación.

APM selecciona todas as transaccións por defecto, aínda que normalmente só se necesitan transaccións web. Do mesmo xeito que Datadog, non hai forma de navegar ata o servizo desexado desde o panel principal. Ademais, as transaccións están listadas despois dos erros, o que non parece moi lóxico para APM.

Nas transaccións de Atatus, todo é o máis parecido posible a New Relic. A desvantaxe é que as dinámicas de cada controlador non son inmediatamente visibles. Tes que buscalo na táboa do controlador, ordenando por Máis tempo consumido:

A lista habitual de controladores está dispoñible na pestana explotar:

En certo sentido, esta táboa lembra a Datadog e gústame máis que a similar de New Relic.

Podes ampliar cada transacción e ver o que estaba facendo a aplicación:

O panel tamén lembra máis a Datadog: hai unha serie de solicitudes, unha imaxe xeral das chamadas. O panel superior ofrece unha pestana de erro Fallos HTTP e exemplos de consultas lentas Rastros da sesión:

Se vai a unha transacción, pode ver un exemplo de rastro, pode obter unha lista de solicitudes á base de datos e mirar as cabeceiras da solicitude. Todo é semellante a New Relic:

En xeral, Atatus está satisfeito con trazos detallados, sen o típico pegado de chamadas New Relic nun bloque de recordatorios:

Non obstante, carece dun filtro que (como New Relic) cortaría as solicitudes ultrarrápidas (<5 ms). Por outra banda, gustoume a visualización da resposta final da transacción (éxito ou erro).

Panel Bases de datos axudarache a estudar as solicitudes a bases de datos externas que fai a aplicación. Permítanme lembrar que Atatus só atopou PostgreSQL e MySQL, aínda que Redis e memcached tamén están implicados no proxecto.

As solicitudes ordénanse segundo os criterios habituais: frecuencia de resposta, tempo medio de resposta, etc. Tamén me gustaría mencionar a pestana coas consultas máis lentas: é moi cómodo. Ademais, os datos desta pestana para PostgreSQL coincidiron cos datos da extensión pg_stat_statements - excelente resultado!

Pestana Solicitudes externas completamente idénticos ás bases de datos.

Descubrimentos

Ambas ferramentas presentadas funcionaron ben no papel de APM. Calquera deles pode ofrecer o mínimo esixido. As nosas impresións pódense resumir brevemente do seguinte xeito:

Datos de datos

Pros:

horario de tarifas conveniente (APM custa 31 USD por host);
funcionou ben con Python;
Posibilidade de integración con OpenTracing
integración con Kubernetes;
integración con NGINX Ingress.

Contras:

o único APM que fixo que a aplicación non estea dispoñible debido a un erro de módulo (predis);
autoinstrumentación PHP débil;
definición en parte estraña dos servizos e da súa finalidade.

Atatus