5 fuentes de datos que convierten los datos APM en análisis de rendimiento de aplicaciones

En un artículo anterior, escribimos cómo Splunk se puede usar para analizar el rendimiento de la aplicación . Hoy hablaremos sobre las principales fuentes de datos para el análisis del rendimiento de las aplicaciones, según Bill Emment, director de marketing de soluciones en Splunk.

Las aplicaciones son críticas para el éxito de cualquier organización. ¿Pero estás haciendo todo lo posible para optimizarlos? Aquí hay cinco fuentes de datos que pueden ayudarlo a mejorar el análisis del rendimiento de la aplicación en poco tiempo.

APM Tool Logs

Ejemplos: revistas de Dynatrace, New Relic, AppDynamics, Pulseway, LogicMonitor, Stackify, Boomerang.js, Jmeter, CA Technologies, Idera, Ipswitch

Si ya tiene herramientas APM, entonces de sus registros puede obtener excelente información sobre el monitoreo de las actividades de los usuarios finales, errores en las páginas, instrumentación de bytecode. Estos registros pueden mostrar problemas de infraestructura y cuellos de botella que no son visibles cuando cada sistema se examina por separado, por ejemplo, una resolución de DNS lenta, lo que conduce a una falla de una aplicación web compleja al intentar acceder a contenido y módulos en diferentes sistemas. Cuando realiza un seguimiento de estos registros, puede recibir advertencias tempranas sobre los problemas de la aplicación para que puedan repararse antes de que los usuarios los vean.

Aplicación de usuario y registros de depuración

Ejemplo: aplicaciones personalizadas

Para los desarrolladores, los registros de depuración y los registros de aplicaciones de usuario son a menudo las fuentes de datos más solicitadas porque proporcionan la información más pequeña sobre el estado, las variables y los errores de la aplicación. Un análisis de estos registros puede ayudar a identificar las causas de fallas en la aplicación, pérdidas de memoria, degradación del rendimiento y vulnerabilidades. En las aplicaciones de usuario, el tipo exacto de fuentes de datos varía según la aplicación.

CRM, ERP y otras aplicaciones comerciales

Ejemplos: SAP, SFDC, Oracle, Microsoft Exchange, Microsoft Dynamics

Muchas de las aplicaciones se integran con los sistemas CRM y ERP, por lo que obtener información sobre el uso y el rendimiento de estos sistemas puede darle una idea de cómo funcionan sus aplicaciones. CRM puede proporcionar información completa y registrar eventos que conducen a la escalada de clientes, y cuando se combina con otras fuentes de datos, CRM puede proporcionar indicadores de problemas más profundos. Al igual que otros registros de aplicaciones, los registros ERP son necesarios al depurar problemas de rendimiento y confiabilidad debido a interacciones complejas entre muchos sistemas. También son útiles para la planificación del ancho de banda.

Herramientas de automatización, configuración e implementación.

Ejemplos: Puppet Enterprise, Ansible Tower, Chef, SaltStack, Rundeck, datos de máquinas que llegan a través de API, servidores web o registros de inicio

Estas fuentes de datos son clave porque las herramientas de automatización lo ayudan a comprender la situación cuando se lanzan nuevas versiones. El monitoreo, análisis y administración de estos datos le brinda la oportunidad de comparar el rendimiento de la aplicación antes / después de la actualización, así como el uso y la disponibilidad de cada versión específica.

Herramientas de prueba

Ejemplos: análisis estático y registros de pruebas de módulos (SonarQube, Tox, PyTest, RubyGem MiniTest, Bacon, Go Testing), registros de creación de servidores e indicadores de rendimiento

El monitoreo de los datos de prueba puede ayudarlo a comprender:

• ¿Cuántas deudas técnicas y problemas se resuelven?
• ¿Qué tan listo está tu próximo lanzamiento?
• Cuántas pruebas se realizan por hora y qué pruebas se realizan

Si combina los datos de prueba con los datos del ensamblaje, puede comenzar a monitorear el rendimiento del ensamblaje y la versión, así como sacar las primeras conclusiones sobre la calidad de la versión. Puede comprender las tendencias del porcentaje de errores y decidir si el ensamblaje está listo para su lanzamiento. Comprender la calidad del código también puede ayudar al personal de soporte técnico a prepararse para cualquier volumen adicional de llamadas o para cualquier problema específico que pueda surgir. Por ejemplo, la CSAA utiliza datos de operaciones del mundo real para determinar qué solicitudes de los usuarios desean enviar para realizar pruebas más exhaustivas.

Puede encontrar más fuentes de datos que pueden ayudarlo a mejorar el análisis de rendimiento de su aplicación APM en la Guía esencial de datos de la máquina: datos de la máquina del usuario y de la aplicación.