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.
Anuncios

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:

 Selenium

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:

SeleniumIDE

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:

Selenium_Codigo

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:

servidor de aplicaciones

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.

Mobile Application Status Monitor

Mobile Application Status Monitor, MASM, es un servicio de monitorización de aplicaciones para dispositivos móviles que permite recrear la experiencia del usuario con el fin de obtener métricas en tiempo real.

Es decir, este servicio monitorizará la aplicación de su negocio y le alertará si ésta no estuviera disponible para sus usuarios, pues el control de la user experience con su marca debe ser lo más importante.

Para mostrar la capacidad de la herramienta MASM este es el vídeo que se presentó en el Mobile World Congress 2015.

Monitoring your app service, NexTRetT

Frame de la presentación en el MWC 2015.

Testing de aplicaciones móviles: principales herramientas

Mientras que el testing de aplicaciones de escritorio desde la interfaz del usuario es bien conocido, con una gran cantidad de herramientas disponibles, el entorno móvil es diferente. Debido a la fragmentación de la plataforma y a las restricciones impuestas en los dispositivos iOS, el testing de aplicaciones móviles es algo más difícil de solventar. Con el tiempo se han desarrollado varias herramientas y en este post se mencionan las más populares. Podrían clasificarse de la siguiente forma:

1.  Herramientas específicas de la plataforma. – Normalmente las proporciona el propio proveedor del Sistema Operativo. Estas herramientas son capaces de testear la aplicación tanto en un dispositivo móvil como en el emulador. Las más conocidas son:

Instruments* – Instruments es un aplicación de Mac que forma parte de Xcode (IDE de desarrollo de aplicaciones iOS). A partir de Xcode4 se incluye una herramienta llamada “Automation” que permite testear aplicaciones desde la interfaz gráfica del usuario. Los scripts que simulan la interacción del usuario están escritos en JavaScript y Apple proporciona un conjunto de librerías.

Monkeyrunner** – Con Monkeyrunner se puede escribir un script en Python que controle tanto emuladores como terminales móviles Android.

2.  Herramientas de Scripting genéricas. – Estas herramientas son desarrolladas por terceros y suelen realizar el testing mediante scripts. Algunas de las más populares son:

Sikuli***– Sikuli utiliza procesado de imagen para testear gráficamente interfaces gráficas de usuario. Esta herramienta puede automatizar cualquier cosa que se vea en la pantalla mediante comparación de imágenes.

Robot Framework**** – Robot Framework es una librería de testing de aplicaciones Android que utiliza ‘Calabash Android’ para comunicarse con la aplicación. Esta herramienta tiene una sintaxis de tabulaciones que utiliza un enfoque de testing basado en palabras clave.
3.  Generadores de eventos aleatorios. – Existen herramientas que testean la estabilidad de las aplicaciones enviándoles eventos aleatorios.

Monkey***** – Monkey (que no es lo mismo que Monkeyrunner) puede ejecutarse tanto en emuladores como en terminales Android y generar secuencias pseudo-aleatorias de eventos de usuario como clic y ‘drag-and-drop’.

Automation – La herramienta Automation de iOS no tiene ningún generador de eventos aleatorios por defecto, pero estos pueden desarrollarse fácilmente creando módulos personalizados con JavaScript con la capacidad de toques, movimientos con los dedos, etc.
4.  Herramientas de testing whitebox. – Estas herramientas pueden examinar la estructura interna de la aplicación. Para este tipo de testing es necesario tener acceso al código de la aplicación, o al menos poder lincar la librería de teing a la aplicación para poder compilar.

Android Instrumentation – Este framework está basado en JUnit y permite testear clases/métodos que no usan APIs específicas de Android. Para testear clases/métodos específicos de Android se usan extensiones de JUnit.

Instruments – La herramienta Instruments forma parte del IDE de desarrollo de aplicaciones iOS y permite testing whitebox de aplicaciones iOS.
Frank y TestStudio también son herramientas de testing whitebox para aplicaciones iOS.

5.  Herramientas de testing Blackbox – Las herramientas de testing Blackbox comprueban la funcionalidad de la aplicación y no cómo se consigue esa funcionalidad. Estas herramientas no requieren tener acceso al código de la aplicación ni saber cómo funciona internamente.

Sikuli – Debido a la tecnología visual en la que se basa, no requiere de ningún tipo de conocimiento del código de la aplicación.

Robotium****** – Robotium es un framework que permite a los desarroladores crear tests blackbox así como whitebox para aplicaciones Android.

http://bit.ly/fZDCKT

** http://developer.android.com/tools/help/monkeyrunner_concepts.html

*** http://www.sikuli.org/

**** http://code.google.com/p/robotframework/

***** http://developer.android.com/tools/help/monkey.html

****** http://code.google.com/p/robotium/

La necesidad de la monitorización de experiencia de usuario

Vivimos en un momento donde la tecnología se ha extendido a la mayoría de la población. El uso de internet se ha vuelto cotidiano, no solo para consultar información (como hasta hace unos años) sino para realizar todo tipo de acciones que hasta hace poco eran impensables, tanto por la facilidad del acceso a internet des del hogar así como con la popularización de los Smartphones y las tarifas planas de acceso a internet.

Ya no vamos a nuestra oficina bancaria a realizar una transferencia, simplemente accedemos al servició de banca electrónica de nuestro banco donde podremos realizar la mayoría de los trámites habituales.

Todo esto ha conseguido abrir un gran mercado de servicios on-line, des de la banca electrónica al E-commerce, y ha obligado a cambiar el modelo de negocio de muchas empresas, donde estas ya tienen en la venta on-line una gran fuente de ingresos.

Para poder ofrecer estos servicios on-line se requiere de una infraestructura cada vez más compleja (frontales web, bases de datos, pasarelas de pago, etc.). Con la monitorización tradicional conocemos el estado de nuestros equipos, pero: ¿podemos afirmar que aun sin detectar problemas en nuestra infraestructura estamos ofreciendo un buen servicio a nuestros usuarios?

Con esta simple pregunta nace la necesidad de monitorizar des del punto vista de un usuario, además de la monitorización tradicional. Existen dos vías distintas para realizar la monitorización de experiencia de usuario. En este artículo nos centraremos en la monitorización web:

  • Monitorización de experiencia de usuario con transacción sintética
    • Esta solución se basa en la creación de usuarios ficticios que realizan siempre las mismas acciones de forma periódica, recogiendo métricas  de disponibilidad, tiempo, etc.  En el entorno web se utilizan aplicaciones que automaticen el navegador, y realice las acciones configuradas en un script tal como lo haría un usuario: rellenar formularios, acciones sobre la web, validación de contenido, etc.  Un robot será el encargado de ejecutar periódicamente estos scripts. Permite detectar fallos de rendimiento o caídas, notificando a los responsables y reduciendo el tiempo de reacción. Con la transacción sintética siempre tendremos un entorno de monitorización controlado y con condiciones repetibles.
  • Monitorización de usuarios reales (RUM)
    • Esta solución se basa en analizar los datos de todos los usuarios  que acceden a nuestro servicio. Estos nos permiten tener una visión global de todas las transacciones realizadas. Al tener una ventana de muestras más diversa, podremos procesar los datos obtenidos según diversos parámetros (Sistema Operativo, Localización, navegador,…).  Al igual que con transacción sintética, nos permitirá detectar en tiempo real fallos de rendimiento, indisponibilidades. Al tener un mayor número de muestras podremos identificar si los problemas son solo para una determinada localización, un determinado navegador, etc. Este tipo de monitorización se puede realizar de dos formas distintas, o bien se inserta un javascript en nuestra aplicación web (como google analytics) o bien poniendo productos específicos que capturaran (de forma transparente y no intrusiva) el tráfico dirigido a nuestra aplicación web.

Criterios para la evaluación de soluciones de Application Performance Monitoring

Vamos a introducir algunos conceptos en cuanto a los criterios más interesantes que podemos pedir a las soluciones de Application Performance Monitoring. Una fuente para estos criterios puede ser los que utiliza Gartner para la evaluación de estas soluciones. Los criterios que os presentamos son un poco más concretos. A grandes rasgos, nos gustaría:

Monitorización de la experiencia del usuario.

  • Una monitorización continua de la experiencia de usuario
  • La medida de la experiencia web a nivel de página, no sólo objetos. Incluyendo la complejidad de las peticiones AJAX.
  • El establecimientos de baseline y la generación de alertas para usuarios con bajo rendimiento
  • Una visión completa sobre geografía, plataforma y tendencias
  • La distribución de la latencia de los distintos componentes (red, servidor, etc)
  • La monitorización la disponibilidad de las aplicaciones incluso cuando no hay usuarios, usando transacciones sintéticas
  • Visibilidad de la experiencia de usuario para casos especiales

Seguimiento de transacciones y monitorización de los componentes de la aplicación.

  • Poder seguir a la aplicación por todas las capas: frontales, servidores de aplicaciones, bases de datos
  • Grabar e indexar todas las transacciones, no sólo muestras. Además, debemos poder encontrar lo que buscamos
  • Monitorizar los datos de rendimiento de manera fina, asegurando que no se pierden las anomalías. Las medias generalmente sólo sirven para el capacity planning
  • Soportar múltiples entornos, como java, .Net, paquetes comerciales y aplicaciones a medida
  • Monitorizar métricas de aplicación y de sistema
  • Bajo overhead
  • Configuración simple/automática y no intrusiva. Las soluciones que requieren la modificación del código no son bienvenidas
  • Facilidad para encontrar las transacciones con problemas

Mapas de transacciones

  • Generar mapas de dependencia de la aplicación en tiempo real
  • Generar mapas para entornos dinámicos (SOA, máquinas virtuales)
  • Aprovechar los datos obtenidos de fuentes existentes
  • Capacidad para trabajar con cualquier tipo de aplicación

Analítica

  • Detectar y correlar anomalías
  • Capturar e indexar todas las transacciones de los usuarios
  • Capacidad para la analítica con un gran volumen de información forénsica y de rendimiento
  • Utiliza métodos sencillos para la búsqueda de información

Cuadros de mando

  • Vistas personalizables para usuarios distintos
  • Vista de alto nivel que permiten una primera diagnosis
  • Facilita la exploración de información de forma sencilla (drill down)
Application Performance-rendimiento web. Layer8

Cuadro de Mando

Ejemplo de cuadro de mando