----------------------------------------------------------€¦ · La monitorizacion de aplicaciones distribuidas tambien se denomina APM ... Application Server ... Cluster SQL con
Post on 20-Sep-2018
218 Views
Preview:
Transcript
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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).
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.
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.
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
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)
top related