Monitoreo de infraestructura y plataforma

<< Click to Display Table of Contents >>

Navigation:  Bizagi Engine > Administración del Sistema Bizagi > Mantenimiento y administración > Monitoreo >

Monitoreo de infraestructura y plataforma

Introducción

Una tarea muy importante en el mantenimiento y administración del Sistema Bizagi, es monitorear la infraestructura y plataforma la cuál soporta la ejecución de Bizagi Engine.

El administrador de plataforma deberá mantenerse alerta a cambios significativos o anormalidades en el comportamiento o rendimiento del sistema, y estar a cargo de tomar las medidas necesarias dado el caso.

Servicios de la infraestructura o plataforma que se deben monitorear, incluyen los servidores sobre los cuáles se ejecutan los componentes de Bizagi, y también otros activos y servicios de infraestructura que hacen parte de la arquitectura del sistema, y que están inmersos en la solución, como por ejemplo el almacenamiento o la red.

Un monitoreo proactivo y adecuado, le permitirá detectar aquellos puntos dónde potencialmente hay aspectos por resolver, o cuellos de botella.

 

User_PlatformAdmin

 

note_pin

Los siguientes lineamientos proveen un punto de partida así como también recomendaciones útiles para las tareas de monitoreo y diagnóstico de infraestructura y plataforma.

Sin embargo, estos lineamientos no abarcan extensivamente todas las tareas que un administrador de plataforma debe realizar para estos propósitos, ni para labores de mantenimiento (la información siguiente es enunciativa y no exhaustiva).

 

Monitoreo de la infraestructura

Se recomienda monitorear de manera permanente, la correcta operación y rendimiento de los activos y servicios de infraestructura críticos.

Para un sistema Bizagi, los siguientes aspectos son especialmente importantes:

 

1. Rendimiento del repositorio de datos físico (la SAN).

En una implementación típica corporativa, las bases de datos, archivos, máquinas virtuales y otros activos de infraestructura, se encuentran en un repositorio separado de los servidores físicos y compartidos entre diferentes servidores y otros dispositivos de cómputo.

Si este es su caso, consulte la documentación de su proveedor para determinar los procedimientos adecuados de monitoreo y las recomendaciones para mantener un rendimiento óptimo en la SAN.

Cuando el almacenamiento de la base de datos se presenta al sistema operativo como un volumen, en el caso de Windows, es posible usar Windows Performance Monitor para identificar potenciales inconvenientes de rendimiento allí.

Las mejores prácticas para el análisis del rendimiento del repositorio se encuentra documentado por Microsoft como proveedor.

Para mayor información, consulte http://blogs.technet.com/b/askcore/archive/2012/02/07/measuring-disk-latency-with-windows-performance-monitor-perfmon.aspx

 

2. Latencia entre los servidores de base de datos y la SAN.

El monitoreo de la latencia de disco física puede ser llevado a cabo mediante comandos específicos que provee el fabricante del motor de base de datos.

 

Por ejemplo, a través del uso de sys.dm_io_virtual_file_stats (que es un Transact-SQL que provee SQL Server), se puede tener la medición.

Para mayor información sobre este comando, consulte https://msdn.microsoft.com/en-us/library/ms190326.aspx).

Dado que la información que se retorna no es trivial de comprender, se recomienda un análisis detallado para tener claro lo que sucede con cada base de datos.

Por ejemplo, se puede consultar este enlace http://www.sqlskills.com/blogs/paul/how-to-examine-io-subsystem-latencies-from-within-sql-server/ que provee un script que permite una mejor lectura de los resultados (de la latencia I/O en el subsistema).

 

Para bases de datos Oracle, usted podrá apoyarse en el uso de Oracle Enterprise Manager para monitorear este tipo de aspectos.

Para mayor información, consulte las opciones de monitoreo de operaciones I/O como por ejemplo las que se enseñan en https://docs.oracle.com/cd/B28359_01/server.111/b28275/tdppt_realtime.htm#CHDCCFDG.

 

3. Latencia entre los servidores de Bizagi y los de base de datos.

Dado que Bizagi es una aplicación intensiva en el acceso a datos, usted deberá considerar las siguientes mediciones recomendadas en la conexión de red entre los servidores de Bizagi y los de base de datos:

 

Latencia baja: La red debe tener en promedio una latencia de 0,15 ms. En instalaciones corporativas, una latencia baja usualmente se logra con los servidores de Bizagi y los de base de datos en el mismo segmento de red e involucrando un switch.

El monitoreo de la latencia entre los servidores de Bizagi y los de base de datos se puede medir a través de un comando PING desde la consola.

 

Ancho de banda adecuado: El ancho de banda recomendado es de por lo menos 10,000 kb en 64ms, de acuerdo a los resultados presentados cuando se invoca el siguiente servicio REST de Bizagi:

http://[Servidor_Bizagi]/[Work_Portal_Site]/Rest/SystemUtilities/Diagnostics/Database/DatabaseBenchmark

Usted podrá invocar este servicio usando el navegador, asegurándose de usar los valores correspondientes para [Servidor_Bizagi] y [Work_Portal_Site].

 

Latency

 

 

4. Conexión entre los dispositivos cliente y los servidores de Bizagi.

Especialmente para la red corporativa en sus instalaciones (o una VPN), el monitoreo de la red  (en este caso, el ancho de banda) entre los servidores de Bizagi y los dispositivos clientes, puede medirse a través de un comando PING desde la consola.

 

5. Otros servicios.

Recuerde que debe monitorear otros servicios que son externos a Bizagi, pero que están integrados a la solución.

Esto incluye el ESB u otros sistemas que expongan servicios web, o repositorio de datos a Bizagi, o servicios como el del servidor de correos corporativo, servidores de archivos o repositorios del ECM, como también, cualquier otro sistema o repositorio que se use para la autenticación (p.e el Directorio Activo), o dispositivos adicionales como firewalls o el balanceador de cargas.

Tenga en cuenta que estos servicios deben estar operando, y que Bizagi debe contar con acceso autorizado cuando aplique (a los que se Bizagi necesite acceder).

 

Monitoreo de la plataforma

Para monitorear la plataforma sobre la cual los componentes de Bizagi Engine se ejecutan, puede apoyarse en los contadores de rendimiento usuales del sistema operativo.

Para realizar chequeos de la salud del servidor (health checks) o medir y monitorear de manera constante el rendimiento de la plataforma de los servidores de Bizagi, se recomienda usar estos contadores (además de otros adicionales que usted considere apropiados):

 

Processor\% Processor Time: Se refiere al porcentaje en promedio del tiempo de procesador ocupado. Es un indicador principal para considerar si la capacidad de procesamiento (CPU) en el servidor IIS es suficiente. Se recomienda que este contador debe permanecer con un valor inferior al 85% para que el sistema se encuentre en un estado saludable.

System\Processor Queue Length: La cola de procesamiento que va llenado con hilos cuando los procesadores del servidor se encuentran ocupados atendiendo otros hilos en ese momento. Si este contador está usualmente por encima de 2 y el porcentaje de tiempo de procesamiento (% Processor Time) permanece en niveles altos, entonces se considera que hay un cuello de botella en el sistema.

Memory\Available Mbytes: Se refiere a la cantidad de memoria física (medida en MBytes) del sistema que puede ser usada por nuevos procesos. Si la memoria libre es igual o mayor que el 50%, entonces el sistema se considera en un estado saludable. Un valor de 25% o menor de memoria libre, sugiere un potencial problema. Un valor por debajo del10%, entonces debe revisarse la condición de manera cuidadosa y seguramente tomar acciones con las precauciones debidas. Un valor menor al 5% impactará de manera negativa al desempeño del sistema.

Memory\Pages/sec: Se refiere a la cantidad de solicitudes de lectura y escritura de la memoria al disco. Si este valor permanece alto y la cantidad de Mbytes disponibles es menor al 10%, entonces el subsistema relacionado a la memoria se considera un cuello de botella. Menos de 500 Pages/sec se considera normal, más de 500 puede resultar impactando el rendimiento.

Network Interface\Bytes Total/sec : Se refiere a la cantidad total de bytes – tanto enviados como recibidos – sobre la red. Si el valor de este contador es usualmente mayor que 80%, entonces es posible que se deba instalar otra NIC de mayores capacidades en el servidor.

 

note_pin

Asegúrese que todos sus servidores cuenten con suficiente espacio disponible de disco.

La cantidad adecuada de espacio libre en disco dependerá de las características de su implementación (dadas por el análisis del dimensionamiento en particular), y de la arquitectura de sistema que involucre.

 

Sea para los servidores de base de datos, los servidores de Bizagi, o para cualquier servidor de archivo usado en el almacenamiento de adjuntos de documentos, cuando el espacio en disco usado esté cerca de la capacidad, usted deberá tomar las medidas adecuadas.

Ejecutar los servidores con una cantidad inapropiada de espacio puede resultar en problemas de rendimiento y comportamientos no esperados por parte del sistema operativo en sí.

 

Además de lo anterior, considere también: Paging file (% de uso), Physical disk (% tiempo de disco), or Logical disk (% tiempo de procesador).

 

note_pin

Como buena práctica, además de trazas de auditoria o de actualizaciones (p.e service packs), tenga en cuenta que los cambios importantes en general deben ser registrados en la hoja de vida del servidor (fecha de cambio vs el cambio).