----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Module 5: Configuring Application Performance Monitoring

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Monitorizacion de apliaciones distribuidas:

La monitorizacion de aplicaciones distribuidas tambien se denomina APM (Aplication Performance Monitoring/Management)

Un ejemplo tipico de apliacion distribuida es una aplicación 3 tier con:

- Tier 1: Front-end Web

- Tier 2: Application Server

- Tier 3: Database Server

System Center Operations Manager 2012 R2 es capaz de monitorizar aplicaciones de 3 tipos:

- Aplicaciones .NET alojadas en IIS.

- Aplicaciones WCF (Windows Communication Fundation)

- Aplicaciones Java (Nuevo en 2012 R2)

o Aplicaciones sobre apache tomcat

o Java JDK

o Struts, struts2

o GenericServlets

Por ejemplo:

Tier1: 5 servidores IIS con un balanceador de carga IIS-1, IIS-2, …, IIS-5

Tier2: 4 servidores de aplicación Apache Tomcat. Apache1, Apache2, Apache3, Apache4.

Tier3: Cluster SQL con 6 nodos.

No nos sirve, desde el punto de vista de la monitorización de la aplicación, monitorizar cada uno de estos 15 servidores por separado.

Si se está agotando el espacio en uno de los Apache, la aplicación puede seguir funcionando. No es motivo para clasificar el estado

de salud de la aplicación como critical.

SCOM incluye los management packs necesarios para monitorizar este tipo de aplicaciones . Incluso , es capaz de detectar estas

aplicaciones distribuidas. El propio SCOM es una aplicación distribuida.

Podemos llegar a monitorizar a nivel de codigo, de forma que podamos determinar cual es el bloque, componente o librería de codigo

que esta provocando problemas de rendimiento.

Monitorizar a este nivel de detalle se suele denominar end-to-end Monitoring. Ademas de monitorizar desde el punto de vista del

servidor y el codigo, tambien podremos monitorizar desde la perspectiva del usuario (Transacciones sinteticas).

Cuando se nos pide monitorizar una aplicación en un determinado escenario, los pasos deberían ser los siguientes:

1. Crear un grupo en Operations Manager. De esta forma es más sencillo organizar los diferentes componentes que forman

parte de la aplicación. Los grupos también son interesantes para aplicar Overrides a los monitores.

2. Utilizar monitores (vienen predefinidos en los Management Packs) y que podrían ser útiles para monitorizar nuestra

aplicación. % de uso de CPU, RAM disponible, …

3. Si alguno de estos monitores tiene umbrales o configuración que no se adapta a nuestra aplicación, creamos Overrides.

4. Definir monitores personalizados. Por ejemplo, número total de sesiones en un entorno RDS. Podemos definir una alerta

cuando el número de sesiones de usuarios es superior a 100. Esta alerta podría disparar un Runbook de forma que ejecuta un

Scale-Out del Tier 2 de la aplicación añadiendo más servidores Session Host.

5. Para medir el rendimiento de la aplicación (por ejemplo, Web Access Server de RDS):

a. Monitorizamos el puerto (443)

b. Monitorizamos si detrás del puerto hay una aplicación web que responde (https://rdsserver1.adatum.com/rdweb).

Comprobamos que no devuelve un error 404 ó un 503.

c. Monitorizamos si podemos navegar por la aplicación (transacción sintética)

6. Profundizamos aún más en la monitorización de la aplicación mediante APM: bloques de código, transacciones, operaciones

internas de la aplicación, …

Todo esto lo recogeremos en una Aplicación Distribuida que creemos usando DAD (Distributed Application Designer).

Vamos a crear nuestro propio grupo:

Pero si configuramos las maquinas de forma explicita, si se añaden más, no se incluirán en el grupo, por ello vamos a quitar esta

maquina.

Vamos a manejar este grupo que acabamos de crear.

Vamos a crear umbrales para que nos controle el numero de sesiones y avise de un estado critico:

Tenemos 3 tipos de monitores que podemos crear operation manager:

- Unit Monitor: Monitoriza un aspecto concreto: % de uso de CPU, memoria RAM disponible, numero de sesiones RDS, …

- Dependency rollup monitor: combina varios monitores basicos y sus dependencias entre si. Por ejemplo, disponibilidad de un

servidor, que depende de % de uso de CPU, memoria RAM, … podrian ser dependencias mas complejas, como la dependencia

del servidor de un swith, que a su vez depende de una tarjeta de red y esta de un router.

- Aggregate rollup Monitor: Agrupan diferentes monitores, pero sin relaciones entre ellos.

Vamos a utilizar un umbral simple (saludable o critico), con un umbral doble podriamos definir, saludable, warning y critico.

Si seleccionamos Session Host Server lo que hacemos es ver las sesiones por cada servidor, en cambio si elegimos el servicio,

valoraríamos las sesiones en el conjunto de servicios.

Vamos a monitorizar ahora los puertos:

Los Watcher node, tiene sentido que se elija uno para poder monitorizar el escenario real, puede interesarnos que se compruebe

desde un agente que esta fuera de la red local por ejemplo. Denominado también, Outside-In Monitroing.

Ahora creamos otro para el puerto 443:

Puerto 443 Web Access RDS

Monitorizamos el puerto 443 del portal de login para el web access de RDS

Vamos a monitorizar si podemos acceder al portal web

Aquí configuramos desde donde queremos que se hagan pruebas de acceso.

Ahora vamos a crear una monitorización sintética (vamos a ver si se puede navegarpor la pagina):

Marcamos esta casilla, aquí es donde grabaremos la transacción sintética.

Entramos en la página, iniciamos sesión y salimos de la misma. Paramos la captura.

Probamos lo que hemos hecho:

Monitorización de Aplicaciones Distribuidas:

Muchas de las aplicaciones actuales tienen componentes que se distribuyen entre servidores diferentes. Por ejemplo, el servicio RDS

tiene varios componentes que pueden instalarse sobre máquinas diferentes:

• RD Connection Broker

• RD Session Host (podemos tener multiples instancias)

• RD Web Access Server

• RD Licesing Server

• …

Además , estas aplicaciones dependerán (o serán una dependencia) de otras aplicaciones y dispositivos:

• Base de Datos

• Una interfaz en un router para salir a Internet

• Controlador de dominio para la autenticacion

• …

Por ejemplo, la aplicación podria tener un muy buen rendimiento (monitor .NET), el puerto esta a la escucha (443), pero el DC esta

caido y los usuarios no pueden autenticarse.

Para una monitorizacion completa debemos tener en cuenta todos los elementos y las relaciones entre si.

SCOM, cuando se integra con productos como ADDS, VMM y SCCM, puede recopilar la informacion necesaria para desarrollar

automaticamente estas relaciones.

Nosotros podemos desarrollar modelos de aplicaciones distribuidas donde indicamos a SCOM los componentes y las relaciones entre

ellos.

La herramienta que usamos es DAD (Distributed applications Designer)

Creamos una relación entre los componentes.

Ahora añadimos otro componente del que depende el IIS:

Se conecta desde los 2 servicios por que ambos dependen de la red