🥇No solo New Relic: una mirada a Datadog y Atatus

En el entorno de ingenieros SRE/DevOps, a nadie sorprenderá que un día aparezca un cliente (o un sistema de monitoreo) y reporte que “todo está perdido”: el sitio no funciona, los pagos no se realizan, la vida se está decayendo. ... No importa cuánto le gustaría ayudar en una situación así, puede resultar muy difícil hacerlo sin una herramienta sencilla y comprensible. A menudo el problema está oculto en el propio código de la aplicación; sólo hay que localizarlo.

Y en la tristeza y en la alegría...

Dio la casualidad de que nos hemos enamorado profundamente y desde hace mucho tiempo de New Relic. Fue y sigue siendo una excelente herramienta para monitorear el rendimiento de las aplicaciones y también le permite instrumentar la arquitectura de microservicio (usando su agente) y mucho, mucho más. Y todo podría haber sido genial si no fuera por los cambios en la política de precios del servicio: costo con años 2013 creció 3+ veces. Además, desde el año pasado, obtener una cuenta de prueba requiere comunicación con un gestor personal, lo que dificulta la presentación del producto a un cliente potencial.

La situación habitual: New Relic no es necesaria de forma “permanente”, la recuerdan sólo en el momento en que comienzan los problemas. Pero aun así hay que pagar regularmente (140 USD por servidor al mes), y en una infraestructura de nube que escala automáticamente las sumas suman bastante grandes. Aunque existe una opción de pago por uso, habilitar New Relic requerirá que reinicie la aplicación, lo que puede llevar a la pérdida de la situación problemática por la que se inició. No hace mucho, New Relic introdujo un nuevo plan de tarifas: Esenciales, - que a primera vista parece una alternativa razonable a Professional... pero tras un examen más detenido resultó que faltan algunas funciones importantes (en particular, no tiene Transacciones clave, Seguimiento de aplicaciones cruzadas, Seguimiento distribuido).

Entonces comenzamos a pensar en buscar una alternativa más económica y nuestra elección recayó en dos servicios: Datadog y Atatus. ¿Por qué en ellos?

Sobre la competencia

Permítanme decirles de inmediato que existen otras soluciones en el mercado. Incluso consideramos opciones de código abierto, pero no todos los clientes tienen capacidad libre para alojar soluciones autohospedadas... - además, requerirán mantenimiento adicional. La pareja que elegimos resultó ser la más cercana a nuestras necesidades:

soporte integrado y desarrollado para aplicaciones PHP (la pila de nuestros clientes es muy diversa, pero este es un claro líder en el contexto de la búsqueda de una alternativa a New Relic);
costo asequible (menos de 100 USD por mes por host);
instrumentación automática;
integración con Kubernetes;
La similitud con la interfaz de New Relic es una ventaja notable (porque nuestros ingenieros están acostumbrados a ella).

Por lo tanto, en la etapa de selección inicial, eliminamos varias otras soluciones populares y, en particular:

Tideways, AppDynamics y Dynatrace - por costo;
Stackify está bloqueado en la Federación Rusa y muestra muy pocos datos.

El resto del artículo está estructurado de tal manera que primero se presentarán brevemente las soluciones en cuestión, después de lo cual hablaré sobre nuestra interacción típica con New Relic y la experiencia/impresiones al realizar operaciones similares en otros servicios.

Presentación de los competidores seleccionados.

Про New Relic, ¿probablemente todo el mundo lo ha oído? Este servicio inició su desarrollo hace más de 10 años, en 2008. Lo hemos estado usando activamente desde 2012 y no hemos tenido problemas para integrar una gran cantidad de aplicaciones en PHP, Ruby y Python, y también hemos tenido experiencia en la integración con C# y Go. Los autores del servicio tienen soluciones para monitorear aplicaciones, infraestructura, rastrear infraestructuras de microservicios, crearon aplicaciones convenientes para los dispositivos de los usuarios y mucho más.

Sin embargo, el agente New Relic se ejecuta en protocolos propietarios y no es compatible con OpenTracing. La instrumentación avanzada requiere ediciones específicas para New Relic. Finalmente, el soporte de Kubernetes aún es experimental.

Comenzó su desarrollo en 2010. Datadog Parece notablemente más interesante que New Relic precisamente en términos de uso en entornos Kubernetes. En particular, admite la integración con los protocolos NGINX Ingress, recopilación de registros, statsd y OpenTracing, lo que le permite rastrear una solicitud de usuario desde el momento en que se conecta hasta su finalización, así como encontrar registros para esta solicitud (tanto en el lado del servidor web). y en el del consumidor).

Al usar Datadog, nos encontramos con que a veces creaba el mapa de microservicios incorrectamente y con algunas deficiencias técnicas. Por ejemplo, identificó erróneamente el tipo de servicio (confundiendo Django con un servicio de almacenamiento en caché) y provocó 500 errores en una aplicación PHP que utilizaba la popular biblioteca Predis.

estado — el instrumento más joven; El servicio se lanzó en 2014. Su presupuesto de marketing es claramente inferior al de los competidores enumerados y las menciones son mucho menos frecuentes. Sin embargo, la herramienta en sí es muy similar a New Relic, no sólo en sus capacidades (APM, monitoreo del navegador, etc.), sino también en apariencia.

Un inconveniente importante es que sólo es compatible con Node.js y PHP. Por otro lado, se implementa notablemente mejor que Datadog. A diferencia de este último, Atatus no requiere que las aplicaciones realicen modificaciones o agreguen etiquetas adicionales al código.

Cómo trabajamos con New Relic

Ahora descubramos cómo usamos generalmente New Relic. Digamos que tenemos un problema que necesita una solución:

Es fácil de ver en el gráfico. incompleto - Analicémoslo. En New Relic, las transacciones web se seleccionan inmediatamente para una aplicación web, todos los componentes se indican en el gráfico de rendimiento, hay paneles de tasa de error, tasa de solicitudes... Lo más importante es que directamente desde estos paneles puedes moverte entre diferentes partes de la aplicación (por ejemplo, al hacer clic en MySQL se accederá a la sección de la base de datos).

Dado que en el ejemplo considerado vemos un aumento en la actividad PHP, haga clic en este gráfico y automáticamente vaya a Transacciones:

La lista de transacciones, que son esencialmente controladores del modelo MVC, ya está ordenada por Consume más tiempo, lo cual es muy conveniente: inmediatamente vemos lo que hace la aplicación. A continuación se muestran ejemplos de consultas largas que New Relic recopila automáticamente. Al cambiar de clasificación, es fácil encontrar:

el controlador de aplicaciones más cargado;
controlador más solicitado;
El más lento de los controladores.

Además, puedes expandir cada transacción y ver qué estaba haciendo la aplicación en el momento en que se ejecutó el código:

Finalmente, la aplicación almacena ejemplos de rastros de solicitudes largas (aquellas que tardan más de 2 segundos). Aquí está el panel para una transacción larga:

Se puede ver que dos métodos toman mucho tiempo y, al mismo tiempo, también se muestra la hora en que se ejecutó la solicitud, su URI y su dominio. Muy a menudo, esto ayuda a encontrar la solicitud en los registros. Ir a Detalles de seguimiento, puedes ver desde dónde se llaman estos métodos:

Y en Consultas de bases de datos — evaluar consultas a bases de datos que se ejecutaron mientras la aplicación se estaba ejecutando:

Armados con este conocimiento, podemos evaluar por qué la aplicación se está ralentizando y trabajar con el desarrollador para idear una estrategia para resolver el problema. En realidad, New Relic no siempre ofrece una imagen clara, pero ayuda a elegir el vector de investigación:

largo PDO::Construct nos llevó al extraño funcionamiento de pgpoll;
inestabilidad en el tiempo Memcache::Get sugirió que la máquina virtual estaba configurada incorrectamente;
un tiempo sospechosamente aumentado para el procesamiento de plantillas llevó a un bucle anidado que verificaba la presencia de 500 avatares en el almacenamiento de objetos;
y así sucesivamente ...

También sucede que en lugar de ejecutar código, algo relacionado con el almacenamiento de datos externo crece en la pantalla principal, y no importa lo que sea: Redis o PostgreSQL, todos están ocultos en la pestaña. Bases de datos.

Puede seleccionar una base específica para investigar y ordenar consultas, de forma similar a como se hace en Transacciones. Y al ir a la pestaña de solicitud, puede ver cuántas veces ocurre esta solicitud en cada uno de los controladores de la aplicación y también estimar con qué frecuencia se llama. Es muy cómodo:

La pestaña contiene datos similares. Servicios externos, que oculta solicitudes a servicios HTTP externos, como acceder al almacenamiento de objetos, enviar eventos a Sentry o similares. El contenido de la pestaña es completamente similar al de Bases de Datos:

Competidores: oportunidades e impresiones.

Ahora lo más interesante es comparar las capacidades de New Relic con lo que ofrecen los competidores. Desafortunadamente, no pudimos probar las tres herramientas en una versión de una aplicación que se ejecuta en producción. Sin embargo, intentamos comparar situaciones/configuraciones que fueran lo más idénticas posible.

1. Perro de datos

Datadog nos recibe con un panel con un muro de servicios:

Intenta dividir las aplicaciones en componentes/microservicios, por lo que en la aplicación Django de ejemplo veremos 2 conexiones a PostgreSQL (defaultdb и postgres), así como apio, Redis. Trabajar con Datadog requiere que tenga un conocimiento mínimo de los principios de MVC: debe comprender de dónde provienen generalmente las solicitudes de los usuarios. Esto suele ayudar mapa de servicios:

Por cierto, hay algo similar en New Relic:

... y su mapa, en mi opinión, es más simple y claro: no muestra los componentes de una aplicación (lo que la haría demasiado detallada, como en el caso de Datadog), sino solo servicios o microservicios específicos.

Volvamos a Datadog: en el mapa de servicios podemos ver que las solicitudes de los usuarios llegan a Django. Vayamos al servicio Django y finalmente veamos lo que esperábamos:

Desafortunadamente, aquí no hay ningún gráfico por defecto. tiempo de transacción web, similar a lo que vemos en el panel principal de New Relic. Sin embargo, se puede configurar en lugar del horario. % de tiempo invertido. Basta con cambiarlo a Tiempo promedio por solicitud por tipo... ¡y ahora el conocido gráfico nos está mirando!

Por qué Datadog eligió un gráfico diferente es un misterio para nosotros. Otra cosa frustrante es que el sistema no recuerda la elección del usuario (a diferencia de ambos competidores) y, por lo tanto, la única solución es crear paneles personalizados.

Pero me complació la capacidad de Datadog de cambiar de estos gráficos a las métricas de servidores relacionados, leer los registros y evaluar la carga en los controladores del servidor web (Gunicorn). Todo es casi igual que en New Relic... ¡y hasta un poquito más (logs)!

Debajo de los gráficos se muestran transacciones completamente similares a New Relic:

En Datadog, las transacciones se llaman Los recursos. Puede ordenar los controladores por la cantidad de solicitudes, por el tiempo promedio de respuesta y por el tiempo máximo empleado durante un período de tiempo seleccionado.

Puedes ampliar el recurso y ver todo lo que ya hemos observado en New Relic:

Hay estadísticas sobre el recurso, una lista generalizada de llamadas internas y ejemplos de solicitudes que se pueden ordenar por código de respuesta... Por cierto, a nuestros ingenieros les gustó mucho esta clasificación.

Se puede abrir y estudiar cualquier recurso de ejemplo en Datadog:

Se presentan los parámetros de solicitud, un cuadro resumen del tiempo dedicado a cada componente y un gráfico en cascada que muestra la secuencia de llamadas. También puedes cambiar a una vista de árbol del gráfico en cascada:

Y lo más interesante es ver la carga del host en el que se ejecutó la solicitud y ver los registros de solicitudes.

¡Gran integración!

Quizás te preguntes dónde están las pestañas Bases de datos и Servicios externos, como en Nueva Reliquia. Aquí no hay ninguno: dado que Datadog descompone la aplicación en componentes, se considerará PostgreSQL un servicio separado, y en lugar de servicios externos vale la pena buscar aws.storage (Será similar para cualquier otro servicio externo al que pueda acceder la aplicación).

He aquí un ejemplo con postgres:

Básicamente, hay todo lo que queríamos:

Puede ver de qué “servicio” proviene la solicitud.

No estaría de más recordarle que Datadog se integra perfectamente con NGINX Ingress y le permite realizar un seguimiento de un extremo a otro desde el momento en que llega una solicitud al clúster, y también le permite recibir métricas estadísticas, recopilar registros y alojar métricas. .

Una gran ventaja de Datadog es que su precio se está perfilando desde monitoreo de infraestructura, APM, gestión de registros y pruebas sintéticas, es decir. Puedes elegir tu plan de forma flexible.

2.Estado

El equipo de Atatus afirma que su servicio es "igual que New Relic, pero mejor". Veamos si esto es realmente así.

El panel principal tiene un aspecto similar, pero no fue posible determinar el Redis y el Memcached utilizados en la aplicación.

APM selecciona todas las transacciones de forma predeterminada, aunque normalmente sólo se necesitan transacciones web. Al igual que Datadog, no hay forma de navegar hasta el servicio deseado desde el panel principal. Además, las transacciones se enumeran después de los errores, lo que no parece muy lógico para APM.

En las transacciones de Atatus, todo es lo más parecido posible a New Relic. La desventaja es que la dinámica de cada controlador no es visible de inmediato. Tienes que buscarlo en la tabla del controlador, ordenando por Más tiempo consumido:

La lista habitual de controladores está disponible en la pestaña Explorar:

En cierto modo, esta tabla recuerda a Datadog y me gusta más que la similar de New Relic.

Puede expandir cada transacción y ver qué estaba haciendo la aplicación:

El panel también recuerda más a Datadog: hay una serie de solicitudes, una imagen general de las llamadas. El panel superior proporciona una pestaña de error. Fallos HTTP y ejemplos de consultas lentas Seguimientos de sesión:

Si va a una transacción, puede ver un ejemplo de seguimiento, puede obtener una lista de solicitudes a la base de datos y mirar los encabezados de las solicitudes. Todo es similar a New Relic:

En general, Atatus está satisfecho con los seguimientos detallados, sin el típico pegado de llamadas de New Relic en un bloque de recordatorio:

Sin embargo, carece de un filtro que (como New Relic) corte las solicitudes ultrarrápidas (<5 ms). Por otro lado, me gustó la visualización de la respuesta final de la transacción (éxito o error).

Panel Bases de datos Te ayudará a estudiar las solicitudes a bases de datos externas que realiza la aplicación. Permítanme recordarles que Atatus solo encontró PostgreSQL y MySQL, aunque Redis y Memcached también participan en el proyecto.

Las solicitudes se clasifican según los criterios habituales: frecuencia de respuesta, tiempo medio de respuesta, etc. También me gustaría mencionar la pestaña con las consultas más lentas: es muy conveniente. Además, los datos de esta pestaña para PostgreSQL coincidieron con los datos de la extensión. pg_stat_declaraciones - ¡excelente resultado!

Pestaña Solicitudes externas Completamente idéntico a las bases de datos.

Hallazgos

Ambas herramientas presentadas funcionaron bien en el papel de APM. Cualquiera de ellos puede ofrecer el mínimo requerido. Nuestras impresiones se pueden resumir brevemente en lo siguiente:

Datadog

Pros:

lista de tarifas conveniente (APM cuesta 31 USD por host);
funcionó bien con Python;
Posibilidad de integración con OpenTracing
integración con Kubernetes;
integración con NGINX Ingress.

Contras:

el único APM que provocó que la aplicación no estuviera disponible debido a un error del módulo (predis);
autoinstrumentación PHP débil;
Definición en parte extraña de los servicios y su finalidad.

estado