En el entorno de ingenieros SRE/DevOps, no sorprende que de vez en cuando aparezca un cliente (o un sistema de monitoreo) y comunique que "todo se ha perdido": el sitio web no funciona, los pagos no pasan, la vida es un sinsentido... Aunque muchos quisiéramos ayudar en tal situación, hacerlo sin una herramienta simple y clara puede ser muy complicado. A menudo, el problema está oculto en el código de la propia aplicación, solo hay que localizarlo.
En la tristeza y en la alegría...
Ha sido así que, desde hace bastante tiempo, hemos llegado a amar mucho New Relic. Ha sido y sigue siendo una excelente herramienta para monitorear el rendimiento de la aplicación, además de permitir la instrumentación de arquitecturas de microservicios (a través de su agente) y mucho más. Y todo podría ser maravilloso, si no fuera por los cambios en la política de precios del servicio: su costo ha aumentado más de 3 veces. Además, desde el año pasado, para obtener una cuenta de prueba se requiere comunicación con un gerente personal, lo que dificulta la presentación del producto a un cliente potencial.
Situación típica: New Relic no es necesario de manera "permanente", solo se recuerda en el momento en que surgen problemas. Pero se sigue teniendo que pagar regularmente (140 USD por servidor al mes), y en una infraestructura en la nube que se escala automáticamente, las cifras se acumulan rápidamente. Aunque existe la opción de "Pago por uso", activarla requiere reiniciar la aplicación, lo que puede llevar a perder la situación problemática por la que se estaba comenzando todo. No hace mucho, New Relic introdujo un nuevo plan tarifario — , — que a primera vista parece una alternativa razonable a Profesional... pero al examinarlo en detalle, resultó que faltan algunas funciones importantes (en particular, no incluye Transacciones Clave, Trazado de Aplicaciones Cruzadas, Trazado Distribuido).
Como resultado, comenzamos a considerar la búsqueda de una alternativa más económica, y nuestra elección recayó en dos servicios, Datadog y Atatus. ¿Por qué precisamente en ellos?
Sobre los competidores
De inmediato aclaro que en el mercado hay otras soluciones. Incluso consideramos opciones de código abierto, pero no todos los clientes tienen capacidad libre para alojar soluciones de categoría self-hosted... además, requerirán mantenimiento adicional. La pareja que elegimos resultó ser la más cercana a nuestras necesidades:
- soporte incorporado y avanzado para aplicaciones PHP (el stack de nuestros clientes es muy diverso, pero este es un claro líder en la búsqueda de alternativas a New Relic);
- costo asequible (menos de 100 USD al mes por hosting);
- instrumentación automática;
- integración con Kubernetes;
- semejanza con la interfaz de New Relic — una ventaja notable (porque nuestros ingenieros están acostumbrados a ella).
Por lo tanto, en la etapa de selección inicial desechamos varias otras soluciones populares, en particular:
- Tideways, AppDynamics y Dynatrace — por su costo;
- Stackify — bloqueado en Rusia y muestra muy pocos datos.
El siguiente artículo está estruturado de tal manera que primero se presentarán brevemente las soluciones consideradas, después de lo cual hablaré sobre nuestra interacción típica con New Relic y nuestras experiencias/impresiones al realizar operaciones similares en otros servicios.
Presentación de los competidores seleccionados
Sobre , ¿probablemente lo hayas escuchado? Este servicio comenzó su desarrollo hace más de 10 años, en 2008. Lo hemos utilizado activamente desde 2012 y no hemos tenido problemas con la integración de un número realmente grande de aplicaciones en PHP, Ruby y Python, así como hemos tenido experiencia integrando con C# y Go. Los autores del servicio tienen soluciones para la monitorización de aplicaciones, infraestructura, trazado de infraestructuras de microservicios, han creado aplicaciones convenientes para dispositivos de usuario y mucho más.
Sin embargo, el agente de New Relic funciona con protocolos propietarios, no tiene soporte para OpenTracing. Para la instrumentación avanzada, se requiere hacer modificaciones específicamente para New Relic. Finalmente, el soporte de Kubernetes aún tiene un estado experimental.
Desarrollado en 2010, se presenta notablemente más interesante que New Relic en términos de uso en entornos Kubernetes. En particular, admite la integración con NGINX Ingress, recolección de logs, protocolos statsd y OpenTracing, lo que permite rastrear la solicitud del usuario desde el momento de su conexión hasta la finalización de su trabajo, así como encontrar los logs relacionados con esa solicitud (tanto del lado del servidor web como del lado de los consumidores).
Al usar Datadog, encontramos que a veces construía incorrectamente el mapa de microservicios, así como algunos inconvenientes técnicos. Por ejemplo, identificaba incorrectamente el tipo de servicio (confundió Django con un servicio de caché) y provocaba errores 500 en la aplicación PHP que utilizaba la popular biblioteca Predis.
es la herramienta más joven; el servicio se lanzó en 2014. Su presupuesto de marketing claramente es inferior al de los competidores mencionados, y las menciones son significativamente menos frecuentes. Sin embargo, la herramienta en sí es muy similar a New Relic, tanto en funcionalidades (APM, monitoreo de navegador, etc.) como en apariencia.
Una desventaja significativa es que solo soporta Node.js y PHP. Por otro lado, su implementación es notablemente mejor que la de Datadog. A diferencia de este último, Atatus no requiere modificaciones en las aplicaciones ni etiquetas adicionales en el código.
Cómo trabajamos con New Relic
Ahora vamos a analizar cómo normalmente utilizamos New Relic. Supongamos que tenemos un problema que necesita solución:
En el gráfico, es fácil notar un pico — lo analizaremos. En New Relic, para la aplicación web se seleccionaron inmediatamente las transacciones web, en el gráfico de rendimiento se indican todos los componentes, hay paneles de tasa de errores, tasa de solicitudes... Lo más importante es que, directamente desde estos paneles, se puede navegar entre las diferentes partes de la aplicación (por ejemplo, hacer clic en MySQL te llevará a la sección de bases de datos).
Dado que en el ejemplo que estamos considerando vemos un aumento en la actividad PHP, haremos clic en este gráfico y automáticamente iremos a Transacciones:
La lista de transacciones, que en esencia son controladores del modelo MVC, ya está ordenada por Más que consume tiempo, lo que es muy conveniente: vemos de inmediato en qué está trabajando la aplicación. También se presentan ejemplos de solicitudes largas que New Relic recopila automáticamente. Al cambiar la clasificación, es fácil encontrar:
- el controlador más cargado de la aplicación;
- el controlador más solicitado;
- el más lento de los controladores.
Además, se puede desplegar cada transacción y ver qué estaba haciendo la aplicación en el momento de la ejecución del código:
Finalmente, la aplicación guarda ejemplos de trazas de solicitudes largas (que tardan más de 2 segundos). Aquí está el panel para una transacción larga:
Se puede ver que dos métodos consumen mucho tiempo y además se muestra el tiempo en que se ejecutó la solicitud, su URI y dominio. Esto ayuda con frecuencia a localizar solicitudes en los registros. Al ir a Detalles de trazas, se puede ver desde dónde se llaman estos métodos:
Y en Consultas a la base de datos — evaluar las consultas a las bases de datos que se ejecutaron en el momento de la operación de la aplicación:
Armados con este conocimiento, podemos evaluar la causa de la lentitud de la aplicación y trabajar con el desarrollador en una estrategia para resolver el problema. En la realidad, New Relic no siempre ofrece una imagen clara, sin embargo, ayuda a seleccionar una dirección para la investigación:
- largo
PDO::Constructnos llevó a un funcionamiento extraño de pgpoll; - inestabilidad en el tiempo
Memcache::Getsugirió una configuración incorrecta de la máquina virtual; - un tiempo de procesamiento de plantilla sospechosamente alto llevó a un ciclo anidado que verificaba la existencia de 500 avatares en el almacenamiento de objetos;
- y así sucesivamente…
También puede ocurrir que, en lugar de ejecutar el código en la pantalla principal, algo relacionado con el almacenamiento externo crezca; y no importa si es Redis o PostgreSQL, todos se esconden en la pestaña Bases de datos.
Se puede elegir una base de datos específica para investigar y clasificar las consultas, de manera similar a como se hace en Transactions. Al pasar a la pestaña de consultas, se puede ver cuántas veces aparece esta consulta en cada uno de los controladores de la aplicación, así como evaluar con qué frecuencia se llama. Es muy conveniente:
Datos similares se encuentran en la pestaña External Services, que oculta las solicitudes a servicios HTTP externos, como la llamada al almacenamiento de objetos, el envío de eventos a Sentry o algo similar. En términos de contenido, esta pestaña es completamente análoga a Databases:
Competidores: capacidades e impresiones
Ahora lo más interesante: comparemos las capacidades de New Relic con lo que ofrecen los competidores. Desafortunadamente, no pudimos probar las tres herramientas en una versión idéntica de una aplicación en producción. Sin embargo, hemos intentado comparar situaciones/configuraciones lo más idénticas posibles.
1. Datadog
Datadog nos recibe con un panel que tiene una pared de servicios:
Intenta descomponer las aplicaciones en componentes/microservicios, así que en el ejemplo de la aplicación Django que se presenta, veremos 2 conexiones a PostgreSQL (defaultdb y postgres), así como Celery y Redis. Trabajar con Datadog requiere de su parte conocimientos mínimos de los principios MVC: es necesario entender hacia dónde van las solicitudes de los usuarios. Normalmente, esto se ayuda con la mapa de servicios:
Por cierto, algo similar también existe en New Relic:
… además, su mapa, en mi opinión, está hecho de manera más simple y comprensible: representa no los componentes de una sola aplicación (lo que lo haría excesivamente detallado, como en el caso de Datadog), sino solo servicios específicos o microservicios.
Volvamos a Datadog: del mapa de servicios se puede ver que las solicitudes de los usuarios llegan a Django. Vamos al servicio de Django y finalmente veremos lo que esperábamos:
Desafortunadamente, por defecto aquí no hay un gráfico Tiempo de transacción web, similar a lo que vemos en el panel principal de New Relic. Sin embargo, se puede configurar en el lugar del gráfico % del tiempo gastado. Solo es necesario cambiarlo a Tiempo promedio por solicitud por tipo… ¡y ya tenemos el gráfico familiar frente a nosotros!
Por qué en Datadog se prefirió un gráfico diferente — es un misterio para nosotros. También nos decepcionó que el sistema no guarda la selección del usuario (a diferencia de ambos competidores), por lo que la única solución es crear paneles personalizados.
Sin embargo, nos alegró la posibilidad en Datadog de pasar de estos gráficos a las métricas de los servidores relacionados, leer los registros y evaluar la carga de los manejadores del servidor web (Gunicorn). Es casi como en New Relic… e incluso un poco más (¡registros!).
Debajo de los gráficos se encuentran las transacciones, completamente análogas a New Relic:
En Datadog, las transacciones se llaman recursos. Se pueden ordenar los controladores por número de solicitudes, por tiempo promedio de respuesta, por el tiempo máximo gastado durante el período seleccionado.
Se puede expandir el recurso y ver todo lo que ya hemos observado en New Relic:
Hay estadísticas sobre el recurso, y una lista resumida de llamadas internas, y ejemplos de solicitudes que se pueden ordenar por código de respuesta… A propósito, a nuestros ingenieros les gustó mucho esta ordenación.
Cualquier ejemplo de recurso en Datadog se puede expandir y estudiar:
Se presentan los parámetros de la solicitud, un diagrama resumen sobre el tiempo gastado en cada uno de los componentes y un diagrama de cascada que muestra la secuencia de llamadas. También está disponible la alternancia a una vista en árbol del diagrama de cascada:
Y lo más interesante — la visualización de la carga del host en el que se ejecutó la solicitud, y la visualización de los registros de la solicitud.
¡Excelente integración!
Puede surgir la pregunta de dónde están las pestañas Bases de datos y External Services, como en New Relic. Aquí no hay: dado que Datadog descompone la aplicación en componentes, PostgreSQL se considerará un servicio separado, y en lugar de Servicios Externos se debe buscar aws.storage (será lo mismo para cada otro servicio externo al que la aplicación pueda acceder).
Aquí hay un ejemplo de postgres:
En esencia, tenemos todo lo que queríamos:
Es evidente de qué 'servicio' provino la solicitud.
No está de más recordar que Datadog se integra muy bien con NGINX Ingress y permite realizar un seguimiento completo desde el momento en que llega la solicitud al clúster, así como aceptar métricas statsd, recopilar logs y métricas de hosts.
Una gran ventaja de Datadog es que su precio se compone de la monitorización de infraestructura, APM, gestión de logs y pruebas sintéticas, es decir, se puede elegir un plan de manera flexible.
2. Atatus
El equipo de Atatus afirma que su servicio es 'igual que New Relic, pero mejor'. Veamos si realmente es así.
La interfaz principal se parece efectivamente, pero no logramos identificar las instancias de Redis y memcached utilizadas en la aplicación.
APM selecciona todas las transacciones por defecto, aunque generalmente solo se necesitan las Web. Al igual que en Datadog, no hay forma de acceder al servicio deseado desde la interfaz principal. Además, las transacciones aparecen en la lista después de los errores, lo cual no es muy lógico para APM.
En las transacciones de Atatus, todo es muy similar a New Relic. Desventaja: no se ve de inmediato la dinámica para cada controlador. Hay que buscarla en la tabla de controladores, ordenando por Most Time Consumed:
La lista familiar de controladores está disponible en la pestaña Explorar:
En cierto modo, esta tabla recuerda a Datadog y resulta más agradable que la correspondiente en New Relic.
Se puede desplegar cada transacción y ver en qué estaba ocupada la aplicación:
El panel también recuerda más a Datadog: hay cantidad de solicitudes y una visión general de las llamadas. La parte superior presenta una pestaña con errores HTTP Failures y ejemplos de solicitudes lentas Session Traces:
Si se accede a la transacción, se ve un ejemplo de traza, se puede obtener una lista de solicitudes a la base de datos y ver los encabezados de la solicitud. Todo es similar a New Relic:
En general, Atatus sorprende con trazas detalladas, sin las típicas uniones de llamadas en el bloque de recordatorio de New Relic:
Sin embargo, aquí falta un filtro que (como en New Relic) descarte las solicitudes extremadamente rápidas (<5ms). Por otro lado, me gustó la visualización de la respuesta final de la transacción (éxito o error).
Panel Bases de datos ayudará a examinar las solicitudes a bases de datos externas que hace la aplicación. Recuerden, Atatus solo encontró PostgreSQL y MySQL, aunque en el proyecto también se utilizan Redis y memcached.
Las consultas se organizan según criterios familiares: frecuencia de activación, tiempo promedio de respuesta, y así sucesivamente. También quiero destacar la pestaña con las consultas más lentas, que es muy útil. Además, los datos en esta pestaña para PostgreSQL coincidieron con los datos de la extensión. ¡un excelente resultado!
Pestaña Solicitudes Externas es completamente idéntica a Databases.
Conclusiones
Ambas herramientas presentadas han mostrado un buen rendimiento como APM. Cualquiera de ellas puede ofrecer lo mínimo necesario. En resumen, nuestras impresiones se pueden resumir así:
Datadog
Pros:
- una cuadrícula tarifaria conveniente (APM cuesta 31 USD por host);
- se desempeñó muy bien con Python;
- posibilidad de integración con OpenTracing
- integración con Kubernetes;
- integración con NGINX Ingress.
Desventajas:
- el único APM que causó la inaccesibilidad de la aplicación debido a un error en el módulo (predis);
- débil auto-instrumentación de PHP;
- una definición algo extraña de los servicios y sus propósitos.
Atatus
Pros:
- instrumentación profunda de PHP;
- interfaz de usuario similar a New Relic.
Desventajas:
- no funciona en sistemas operativos antiguos (Ubuntu 12.05, CentOS 5);
- débil auto-instrumentación;
- soporte para solo dos lenguajes de programación (Node.js y PHP);
- interfaz de trabajo lenta.
Dado el precio de Atatus de 69 USD al mes por servidor, preferiríamos usar Datadog, que se integra muy bien a nuestras necesidades (aplicaciones web en K8s) y cuenta con varias funciones útiles.
P.D.
También puedes leer en nuestro blog:
- «»;
- «»;
- «».
Fuente: habr.com
