Diferencias entre APM y NPM

El objetivo de este artículo es explicar las diferencias entre los conceptos de APM y NPM. Para plasmarlas se confrontaran las similitudes y divergencias en puntos clave. NPM significa “Network Performance Monitoring” o Monitorización del Rendimiento de la Red.  APM significa “Application Performance Monitoring” o Monitorización del Rendimiento de las Aplicaciones. Orientación/objetivos

• Puntos en común: En ambos casos, el objetivo es detectar incidencias en IT que puedan llegar a afectar la experiencia del usuario final y disponer de información necesaria para facilitar su resolución. Adicionalmente, también se recoge información que resulta útil para planificar mejoras en la infraestructura IT.
• Puntos de divergencia: El foco de NPM es “controlar” el rendimiento de la red y detectar posibles incidencias tanto a nivel LAN como WAN. La orientación es más a nivel de enlaces o grupos de usuarios. El foco de APM está en “controlar” el rendimiento de las aplicaciones desde el punto de vista de los servidores y del usuario final. La orientación es más a nivel de usuario o incluso a nivel de transacción

Métodos/puntos de captura

• Puntos en común: En ambos casos se almacena un gran número de datos e información que permiten tener histórico que incluye la captura de tráfico en tiempo real.
• Puntos de divergencia: NPM puede recibir pasivamente información de elementos de red a través de protocolos como NetFlow o IPFIX o bien realizar consultas a través de protocolos tipo SNMP. APM extrae información a través de agentes en los servidores involucrados en el suministro de la aplicación y también de los dispositivos que realizan las consultas (PC o navegador).

Alcance de la información obtenida

• Puntos en común: En ambos casos, se espera obtener información que pueda permitir emitir un veredicto sobre la experiencia del usuario final en el uso de una aplicación. Por tanto, se tiene que poder distinguir y categorizar aplicaciones a la vez que se obtienen métricas relevantes al respecto.
• Puntos de divergencia: NPM centra la información proporcionada en estadísticas de red tales como retransmisiones, pérdidas de paquetes o tiempos de respuesta. APM se centra en datos como recogidos en servidores o PC como por ejemplo tiempos de carga, componentes software ejecutados o recursos consumidos.

Usos de la información obtenida:

• Puntos en común: En ambos casos se obtiene una alerta en cuanto hay una degradación de la experiencia de usuario. Adicionalmente, se proporcionan información y herramientas para realizar un rápido diagnóstico del foco del problema.
• Puntos de divergencia: NPM permite obtener información detallada de usos indebidos de la red o detección de congestiones. Adicionalmente permite realizar acciones de “capacity planning” a nivel de infraestructuras IT. APM centra la obtención de información en la “performance” de las aplicaciones dentro de los servidores y de los dispositivos de los usuarios. La información obtenida permite realizar mejoras a nivel de aplicación, como por ejemplo cambios en código o formato de consultas en base de datos.

Automatización de Pruebas con Selenium

Selenium es un framework Open Source que permite realizar pruebas sobre aplicaciones Web. Se trata de una herramienta especialmente útil para todos los desarrollos basados en Web porque permite automatizar procesos de testing y repetirlos de manera iterativa, lo que nos lleva a un ahorro de tiempo y esfuerzo muy importante en un proceso de desarrollo y mantenimiento de cualquier aplicación.

Vamos a ver dos elementos claves del ecosistema Selenium:

Selenium IDE

Se trata de un entorno para la grabación guiada de test basada en Mozilla Firefox, se instala como un plugin sobre nuestro navegador y permite la grabación guiada de test mediante clicks en la página web a testear.

También permite la reproducción de las pruebas de manera individual o conjunta y da la posibilidad de configurar una planificación ordenada para realizar las mismas.

El lenguaje en el que las pruebas quedan registradas en Selanese, un lenguaje propio de Selenium con el objetivo de facilitar la creación de scripts, interpretando los elementos existentes en una navegación Web y dotando de múltiples posibilidades en la personalización de las acciones, con un funcionamiento muy usable e intuitivo.

Esta es la apariencia que tiene el plugin:

Plugin

Una de las limitaciones más significativas es que solamente podemos utilizarlo en Firefox, por lo que si necesitamos realizar pruebas contra otros navegadores no es una opción válida.

Selenium Web Driver

Es la implementación clave de Selenium y permite enviar comandos al navegador mediante un controlador especifico a cada una de las instancias que nos interese, lo que se traduce en que podemos realizar nuestras pruebas a distintos navegadores, bastará con tenerlos instalados en nuestro entorno de trabajo donde se ejecuten las pruebas y tener el controlador correcto que podemos descargar de la página de Selenium.

Soporta Selanese y un número elevado de los lenguajes más populares  (Java, Ruby, Pythin, C#). Su API nos provee de todas las acciones necesarias para emular todas aquellas navegaciones de usuario que necesitemos crear.

El proceso más óptimo para crear estas pruebas para Java, por ejemplo, pasa por grabarlas con Selenium IDE, por su comodidad y rapidez, exportar la prueba como Java / Junit / WebDriver e importarla en un proyecto que tenga las siguientes librerías incluidas:

Proyecto para Java

Una vez hecho esto, podremos ejecutar nuestra prueba como un test unitario con el framework JUnit y evaluar sus resultados, cosa muy útil si queremos realizar múltiples casos de pruebas para nuestra aplicación que ejecutaremos de manera recurrente.

Veamos un ejemplo de código:

Código del test

Dónde en el momento de la instalación del driver (new FireFoxDriver) podríamos variarlo y realizar la prueba sobre cualquier navegador que necesitemos, siempre y cuando tengamos el driver accesible y cargado en nuestro proyecto.

Monitorización avanzada de sistemas en aplicaciones web multicapa

En el actual entorno de aplicaciones web multicapa con balanceadores, frontales web, servidores de aplicaciones y servidores de bases de datos, la monitorización tradicional de sistemas –para entendernos– limitada a monitorizar el uso de CPU, memoria y espacio en disco disponible, queda obsoleta.

En estos entornos se producen frecuentemente problemas de rendimiento que serán muy complicados de analizar si utilizamos únicamente la monitorización tradicional.

La monitorización de estos entornos presenta un desafío porque constan de determinados elementos que no deben quedar fuera del alcance de la monitorización como pueden ser los siguientes:

Servidores de aplicaciones

• Servidores de aplicaciones (con sus instancias de java o JVMs): Dentro de estos servicios se ejecutan máquinas virtuales de JAVA o .NET que poseen porciones de memoria asignadas y gestionadas por las propias instancias. El uso que se realiza dentro de los servidores de aplicaciones (Tomcat, Websphere, Jboss) de estas porciones de memoria queda oculta a las métricas proporcionadas por el sistema operativo y por ello es necesario utilizar herramientas adicionales para obtener los parámetros clave de rendimiento. Estos parámetros clave son:

1. Tiempo en Garbage Collection: Es valor nos permite obtener el % del tiempo de ejecución que se está gastando en limpieza de los objetos que están presentes en la pila (Heap Space) pero ya no están referenciados y por lo tanto pueden ser eliminados. Si se llena el Heap Space y el proceso recolector de basura no es capaz de liberar memoria estará pasando continuamente dejando la JVM de atender las transacciones de los usuarios. Más info en: http://en.wikipedia.org/wiki/Java_virtual_machine#Generational_heap
2. % Libre de Heap Space: Porcentaje libre de pila para el almacenaje de los objetos generados mediante la ejecución del código de la aplicación.
3. Heap Consumption: Medido en MBytes por segundo nos indica el nivel de actividad (lecturas/escrituras) en la Heap Space. Valores muy elevados en relación a la actividad realizada por las aplicaciones (nivel de usuarios y operaciones realizadas) nos indicaran ineficiencia en el uso de dicho espacio de memoria.

• Servidores de bases de datos: Estos sistemas sufren de forma muy intensa la actividad de los usuarios de aplicaciones transaccionales. Además de la monitorización clásica de sistemas (CPU/Memoria/Disco) es muy importante no olvidarse de monitorizar otros parámetros críticos:
  1. Delays en los accesos a disco: Los delays en los accesos a disco deben ser muy bajos para garantizar tiempos de bloqueo en los accesos a datos mínimos que eviten que ciertas peticiones sean retardadas de forma importante. Por ejemplo, los sistemas basados en Oracle están pensados para funcionar de forma óptima con delays de escritura a disco inferiores a 10 ms.
  2. Parámetros relevantes de BBDD: Aunque en otro post analizaremos en detalle los parámetros más relevantes en cuanto a la monitorización de métricas de estos sistemas, podemos avanzar que tener en cuenta parámetros como Buffer Cache Hit Ratio (que indica el porcentaje de peticiones que son resultas mediante accesos a páginas que están en memoria) o el Average Lock Wait Time (que nos indica el promedio de tiempo que las peticiones tienen que esperar para ser ejecutadas) son críticos para asegurar un óptimo rendimiento del servicio. Más información en https://thwack.solarwinds.com/docs/DOC-167343

• Cabinas de discos: Con el uso intensivo de la virtualización el nivel de actividad que sufren estos sistemas es muy elevado. Además el hecho de que diversos sistemas diferentes estén a menudo accediendo sobre el mismo conjunto de discos puede crear penalizaciones cruzadas en los accesos muy difíciles de detectar. En este caso problemas en una aplicación pueden provocar problemas de rendimiento en otra aplicación que no tienen nada que ver con el diseño de la misma ni los servidores sobre los que está funcionando. Por ello es muy relevante monitorizar tanto el nivel de IOPS (número de operaciones de acceso a discos por segundo) total que le estamos pidiendo a la cabina en cada intervalo determinado como el número individual de IOPS generado por cada sistema para en el caso de que alguno de ellos este generando de forma prolongada un número muy elevado de accesos investigar cual es la causa.

Creemos que tener en cuenta estos puntos a la hora de definir como debe ser la monitorización de los sistemas en arquitecturas web multicapa es crucial para garantizar el correcto funcionamiento de los mismos.

Técnicas de monitorización del rendimiento de las aplicaciones

Entendemos como monitorización del rendimiento de las aplicaciones aquellas técnicas mediante las cuales se pueden detectar desviaciones en los tiempos de respuesta y/o un malfuncionamiento de las mismas de forma proactiva, generando las oportunas alertas cuando corresponda.

Existen 4 grandes técnicas de monitorización:

• Transacciones sintéticas: Mediante esta técnica se generan peticiones utilizando las mismas herramientas (por ejemplo: un navegador o una aplicación cliente) que utiliza el usuario para acceder a la aplicación y se miden los tiempos de respuesta de las diversas operaciones que puede hacer un usuario comparándolos con una línea base. Es importante no confundir las transacciones sintéticas con las sondas pues estas últimas no utilizan la misma aplicación utilizada por el usuario.
• Monitorización de la red: Mediante captura de tráfico se analiza el comportamiento de la aplicación a partir de los resultados obtenidos a partir del análisis del mismo (tiempo de respuesta del servidor, retardo causado por la red, etc). Para utilizar esta técnica es necesaria que los equipos que procesan este tráfico posean una gran inteligencia pues deben recomponer las transacciones de la aplicación a partir de la captura de paquetes a nivel de red.
• Monitorización desde la estación de trabajo del usuario (experiencia final del usuario): Esta técnica se basa en la captura del rendimiento de la aplicación des de la misma estación de trabajo del usuario obteniendo de esta forma el rendimiento de la aplicación para transacciones reales de usuario. En el caso de aplicaciones web se utiliza la inserción de código JavaScript para obtener estas mediciones en el equipo final del usuario ya que al ejecutarse dicho código en el navegador del usuario se podrán obtener medidas reales de la experiencia final del mismo (por ejemplo Google Analytics utiliza este sistema para obtener los resultados de rendimiento).
• Instrumentación de servidores: En este caso se utilizan agentes en los servidores (web, aplicaciones, bases de datos) para obtener medidas del rendimiento de la aplicación a partir del seguimiento de la ejecución del código dentro de estos servidores. Esta técnica es muy útil para obtener los puntos de la aplicación que presentan problemas de rendimiento y suministrar información útil a los desarrolladores para solucionar dichos problemas.

En futuros posts analizaremos las soluciones de algunos fabricantes (por ejemplo OPNET) al respecto de la monitorización de aplicaciones.

Extraer datos de rendimiento en páginas Web

Es posible, y en ocasiones altamente interesante, obtener información en forma de tiempo de todos los procesos que realizar una página web mientras se carga desde el lado del cliente, es decir, en el navegador, sin necesidad de acudir a complejos códigos que se ejecuten en el servidor.

En el pasado, los desarrolladores web accedían a estas métricas de carga de la página del lado del cliente mediante el uso de JavaScript Date. Un simple código como este : var  inicio = Date.now(); al inicio de la carga nos almacena una variable con el tiempo en que empieza el proceso y en el momento de finalizar la carga, con simple resta como esta : var tiempoCarga = Date.now()-inicio obtendríamos el tiempo total que se ha empleado en realizar la carga.

Este funcionamiento es limitado y poco fiable por algunas razones evidentes:

• El código de medida de tiempo se encuentra en la página, por lo que afecta a la forma en que la página se carga y modifica su comportamiento natural.  (Navigation Timing Api puede ser utilizado para obtener los tiempos
• Este javascript se trata de una aproximación, y dista mucho de ser preciso
• El objeto Date de JavaScript no se puede usar para medir la latencia de la red antes del comienzo de la carga.

Para solucionar todo este vacío que existía en este apartado es donde Navigation Timing entra en escena.

Navigation Timing es una Api Javascript que provee de los métodos necesarios para medir el funcionamiento de la web de forma precisa y sencilla y conseguir las estadísticas de la navegación y tiempos de carga.

Esta Api puede ser utilizada después de que la página haya terminado la carga, por lo que no afecta al proceso y no incrementa  de forma artificial sus tiempos, solucionando así uno de los puntos más críticos  mencionados anteriormente en el uso del objeto Date de JavasCript para la medición de tiempos.

Esta Api es accesible mediante las propiedades del objeto window.performance en dos variantes:

• Navigation : como navega a la página el usuario
• Timing: datos de la navegación y eventos de carga de la pagina

Los atributos accesibles a través de estos objetos quedan ilustrados en el siguiente diagrama extraído de la página: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html

Timing

Esta Api está disponible en muchos de los navegadores más utilizados habitualmente, pero no está soportada en todos. En la siguiente tabla se resume la disponibilidad asociada a la versión de navegador:

Navegador	Versión
Internet Explorer	9.0 +
Firefox	7.0 +
Chrome	6.0 +
Safari	No soportado
Opera	15.0 +
IOS Safari	No soportado
Opera mini	No soportado
Android browser	4.0 +
Black Berry browser	10.0 +
Opera mobile	14.0 +
Chrome android	29.0 +
Internet Explorer mobile	10.0 +
Firefox android	23.0 +

Actualmente, y mediante el uso de la Api Navigation timing, la herramienta ISM de experiencia web de usuario de NexTret implementa la recogida de nuevas métricas que complementan los datos que ya ofrecíamos a nuestros usuarios, dando así un valor añadido y una información extra, del comportamiento de una web, que resulta ser de gran utilidad y  muy valorada por nuestros clientes.