En los campos de la tecnología de la información y la gestión de sistemas , la gestión del rendimiento de aplicaciones ( APM ) es la supervisión y la gestión del rendimiento y la disponibilidad de las aplicaciones de software . APM se esfuerza por detectar y diagnosticar problemas complejos de rendimiento de las aplicaciones para mantener un nivel de servicio esperado . APM es "la traducción de las métricas de TI en significado empresarial ([es decir] valor)". [1]
Se controlan de cerca dos conjuntos de métricas de rendimiento . El primer conjunto de métricas de rendimiento define el rendimiento que experimentan los usuarios finales de la aplicación. Un ejemplo de rendimiento son los tiempos de respuesta promedio en condiciones de carga máxima. Los componentes del conjunto incluyen los tiempos de carga y respuesta:
El segundo conjunto de métricas de rendimiento mide los recursos computacionales utilizados por la aplicación para la carga, indicando si hay capacidad adecuada para soportar la carga, así como las posibles ubicaciones de un cuello de botella en el rendimiento. La medición de estas cantidades establece una línea base de rendimiento empírica para la aplicación. La línea base se puede utilizar para detectar cambios en el rendimiento. Los cambios en el rendimiento se pueden correlacionar con eventos externos y, posteriormente, se pueden utilizar para predecir cambios futuros en el rendimiento de la aplicación. [3]
El uso de APM es común en aplicaciones web, lo que se presta mejor a las técnicas de monitoreo más detalladas. [4] Además de medir el tiempo de respuesta de un usuario, también se pueden monitorear los tiempos de respuesta de los componentes de una aplicación web para ayudar a identificar las causas de los retrasos. También existen dispositivos HTTP que pueden decodificar los tiempos de respuesta específicos de las transacciones en la capa del servidor web de la aplicación.
En su Marco Conceptual APM , Gartner Research describe cinco dimensiones de APM: [5] [6] [7] [8]
En 2016, Gartner Research actualizó su definición en tres dimensiones funcionales principales: [9]
Desde la primera mitad de 2013, APM ha entrado en un período de intensa competencia en tecnología y estrategia con una multiplicidad de proveedores y puntos de vista. [10] Esto ha causado una conmoción en el mercado con proveedores de antecedentes no relacionados (incluidos monitoreo de red, [11] administración de sistemas, instrumentación de aplicaciones y monitoreo de rendimiento web ) que adoptan mensajes en torno a APM [ ¿cuál? ] . Como resultado, el término APM se ha diluido y ha evolucionado en un concepto para administrar el rendimiento de las aplicaciones en muchas plataformas informáticas diversas, en lugar de un mercado único. [ aclaración necesaria ] [12] Con tantos proveedores para elegir, seleccionar uno puede ser un desafío. Es importante evaluar cada uno cuidadosamente para asegurarse de que sus capacidades satisfagan sus necesidades. [13]
Dos desafíos para la implementación de APM son (1) puede ser difícil instrumentar una aplicación para monitorear el rendimiento de la aplicación, especialmente entre los componentes de una aplicación, y (2) las aplicaciones pueden virtualizarse , lo que aumenta la variabilidad de las mediciones. [14] [15] Para aliviar el primer problema, la gestión de servicios de aplicaciones (ASM) proporciona un enfoque centrado en la aplicación, donde la visibilidad del rendimiento del servicio comercial es un objetivo clave. El segundo aspecto presente en aplicaciones distribuidas, virtuales y basadas en la nube plantea un desafío único para el monitoreo del rendimiento de las aplicaciones porque la mayoría de los componentes clave del sistema ya no están alojados en una sola máquina. Es probable que ahora cada función haya sido diseñada como un servicio de Internet que se ejecuta en múltiples sistemas virtualizados. Es muy probable que las aplicaciones mismas se muevan de un sistema a otro para cumplir con los objetivos de nivel de servicio y lidiar con interrupciones momentáneas. [16]
Las aplicaciones en sí mismas se están volviendo cada vez más difíciles de gestionar a medida que avanzan hacia construcciones altamente distribuidas, de múltiples niveles y múltiples elementos que en muchos casos dependen de marcos de desarrollo de aplicaciones como .NET o Java. [17] El Marco Conceptual APM fue diseñado para ayudar a priorizar un enfoque sobre qué enfocar primero para una implementación rápida y una comprensión general del modelo APM de cinco dimensiones. La diapositiva del marco describe tres áreas de enfoque para cada dimensión y describe sus beneficios potenciales. Estas áreas se denominan " Principales " a continuación, y las dimensiones de menor prioridad se denominan " Secundarias " . [18]
Medir el tránsito del tráfico desde la solicitud del usuario hasta los datos y viceversa es parte de la captura de la experiencia del usuario final (EUE). [19] El resultado de esta medición se conoce como monitoreo de aplicaciones en tiempo real (también conocido como monitoreo de arriba hacia abajo), que tiene dos componentes, pasivo y activo. El monitoreo pasivo suele ser un dispositivo sin agente implementado mediante duplicación de puertos de red . Una característica clave a considerar es la capacidad de soportar análisis de múltiples componentes (por ejemplo, base de datos, cliente/navegador). El monitoreo activo , por otro lado, consiste en sondas sintéticas y robots web predefinidos para informar sobre la disponibilidad del sistema y las transacciones comerciales. El monitoreo activo es un buen complemento para el monitoreo pasivo; juntos, estos dos componentes ayudan a proporcionar visibilidad sobre el estado de la aplicación durante las horas de menor actividad cuando el volumen de transacciones es bajo.
La gestión de la experiencia del usuario (UEM) es una subcategoría que surgió de la dimensión EUE para monitorear el contexto de comportamiento del usuario. La UEM, tal como se practica hoy en día, va más allá de la disponibilidad para capturar latencias e inconsistencias a medida que los seres humanos interactúan con aplicaciones y otros servicios. [20] La UEM generalmente se basa en agentes y puede incluir la inyección de JavaScript para monitorear el dispositivo del usuario final. La UEM se considera otra faceta del monitoreo de aplicaciones en tiempo real.
Las ofertas de descubrimiento de aplicaciones y mapeo de dependencias (ADDM) existen para automatizar el proceso de mapeo de transacciones y aplicaciones a los componentes de infraestructura subyacentes. [21] Al prepararse para implementar una arquitectura de aplicación en tiempo de ejecución, es necesario garantizar que exista un monitoreo ascendente/descendente para todos los nodos y servidores dentro del entorno (también conocido como monitoreo ascendente). Esto ayuda a sentar las bases para la correlación de eventos y proporciona la base para una comprensión general de cómo las topologías de red interactúan con las arquitecturas de aplicaciones.
Concéntrese en las transacciones definidas por el usuario o en las definiciones de páginas URL que tienen algún significado para la comunidad empresarial. Por ejemplo, si hay entre 200 y 300 definiciones de páginas únicas para una aplicación determinada, agrúpelas en 8 a 12 categorías de alto nivel. Esto permite generar informes de SLA significativos y proporciona información de tendencias sobre el rendimiento de la aplicación desde una perspectiva empresarial: comience con categorías amplias y refine con el tiempo. Para obtener una comprensión más profunda, consulte Gestión de transacciones comerciales .
El monitoreo de componentes en profundidad (DDCM) requiere la instalación de un agente y generalmente está orientado al middleware , centrándose en servidores web, de aplicaciones y de mensajería. Debe proporcionar una vista en tiempo real de las pilas J2EE y .NET , vinculándolas con las transacciones comerciales definidas por el usuario. Un monitor sólido muestra una ruta clara desde la ejecución del código (por ejemplo, spring y struts) hasta la URL representada y, finalmente, hasta la solicitud del usuario. Dado que DDCM está estrechamente relacionado con la segunda dimensión en el modelo APM, la mayoría de los productos en este campo también proporcionan mapeo de dependencia de descubrimiento de aplicaciones (ADDM) como parte de su oferta.
Es importante llegar a un conjunto común de métricas para recopilar e informar sobre cada aplicación, y luego estandarizar una visión común sobre cómo presentar los datos de rendimiento de la aplicación. La recopilación de datos sin procesar de los otros conjuntos de herramientas en todo el modelo APM proporciona flexibilidad en los informes de aplicaciones. Esto permite responder a una amplia variedad de preguntas de rendimiento a medida que surgen, a pesar de las diferentes plataformas en las que se puede ejecutar cada aplicación. Demasiada información es abrumadora. Por eso es importante mantener los informes simples o no se utilizarán. [22]