Introducción
Recomendamos al administrador de la plataforma, monitorear los servicios de Bizagi tanto de su componente web (el Portal de Trabajo) como del servicio Programado.
Ambos deberán encontrarse operando en todo momento y bajo un óptimo desempeño.
Un monitoreo proactivo y adecuado, le permitirá detectar aquellos puntos dónde potencialmente hay aspectos por resolver, o cuellos de botella.
Monitoreo del servidor de aplicación/web
En los servidores de Bizagi, y ya sea si se utiliza WebSphere, Weblogic, JBoss o IIS, asegúrese de monitorear de manera constante el servicio mismo del servidor de aplicación/web.
Para ello, puede apoyarse en los logs respectivos. La siguiente tabla ilustra los logs típicos para hacer seguimientos (o adicionales según instrucciones propias del fabricante):
LOG |
RUTA |
|---|---|
Logs registrados por el Visor de eventos |
C:\inetpub\logs |
Además de lo anterior, monitoree los eventos que Bizagi registra ante sucesos importantes.
Por ejemplo, en sistemas operativos Windows, podrá apoyarse en el Visor de eventos de Windows (eventvwr).
Acerca de las Actividades Asíncronas
También deberá monitorear cómo se procesan las Actividades Asíncronas de Bizagi.
Recuerde que éstas podrán ser procesadas en un segundo plano, e involucrando diversos reintentos (por ejemplo, típicamente debido a que una interfaz externa se encuentre fuera de servicio).
Si su proyecto se apoya significativamente en el uso de Actividades Asíncronas, se recomienda vigilar de cerca su ejecución adecuada.
También se recomienda apoyarse en la opción de administración que el Portal de Trabajo presenta para este fin, llamada la Consola de las actividades asíncronas.
Esta consola lista aquellas actividades que están pendientes por ejecutarse (debido a un intento fallido anterior).
|
Bizagi tiene disponible un log adicional que se recomienda monitorear, el cual registra aquellos servicios externos que no responden, o que lo hacen sobre un marco de tiempo alargado. Esto significa que cuando Bizagi invoca servicios web externos, se registra una entrada en un archivo .csv siempre que dicho servicio exceda el umbral predefinido para retornar una respuesta a tiempo (o, se cumpla el tiempo de espera). Este archivo se ubica dentro de .\Temporary\SOA\Log\ de la ruta del proyecto (por defecto se crea un archivo por interfaz de servicio, p.e C:\Bizagi\Projects\[your_project]\Temporary\SOA\Log\[interfaz]Log_1.csv) . Y, dicho archivo tendrá una línea para cada alerta descrita anteriormente, con el detalle: fecha (DateTime), descripción del error (ErrorDescription), idCase, nombre de la tarea (Task_Name), URL, nombre del método (Method_Name), y tiempo de la interfaz (InterfaceTime)- de la forma MM:ss:mmm. |
Acerca del IIS
Cuando se monitorea explícitamente el IIS, se recomienda tener en cuenta el tamaño de la cola de solicitudes directamente allí para directamente detectar si hay cuellos de botella en el servidor de Bizagi.
Si se detecta una cantidad en aumento de solicitudes que se encolan en el IIS (donde se implica una degradación porque el comportamiento de la cola sea incremental), entonces se debe considerar si se necesitan nodos adicionales en su configuración de clúster.
Demoras en el procesamiento de solicitudes que no se produzcan por servicios externos (p.e in en puntos de integración en Bizagi) o que no sean producidos por la capacidad del servidor de base de datos de retornar la información, sugieren que los servidores de Bizagi deben ser revisados y ajustados (un escalamiento horizontal de acuerdo a cómo aumente el tamaño de la cola).
Archivos de log de los hilos del servidor web proveen detalle adicional, ubicado por defecto en las carpetas tipo W3SVC dentro de C:\inetpub\logs\LogFiles:
.
ASPECTOS A MONITOREAR |
INTERPRETACIÓN |
|---|---|
Archivos de log de los hilos del servidor web.
|
Estos archivos presentan parámetros que presentan una medición en milisegundos: •timedb: El tiempo que toma la base de datos para entregar la información final al servidor de Bizagi. •timeba: El tiempo que toma el Portal de Trabajo en procesar la solicitud.
La suma de ambos totalizan el tiempo que toma en procesarse una solicitud por completo, una vez que se maneja en el IIS (quiere decir que no incluye el tiempo de espera en cola que pueda tener una solicitud).
Lo anterior sugiere que a través de los contadores de rendimiento del IIS se podrá acotar si las solicitudes aguardan un tiempo no esperado/deseado en cola.
Recuerde que usted podrá monitorear el contador llamado Current queue size (que está disponible en la clasificación HTTP Service Request queue), específicamente para el pool de aplicaciones que usa Bizagi (por defecto nombrado como Bizagi 64-Bit ASP.NET v4.0). Esto permite determinar el comportamiento en potencial encolamiento de los servidores de Bizagi. |
Podrá también utilizar contadores de rendimiento específicos del IIS (rol de servidor web), como por ejemplo:
•ASP.NET Applications\Requests/Sec: Muestra el rendimiento (en términos de throughput) de la aplicación ASP.NET en el servidor. Debe monitorearse conjuntamente con otros contadores para poder determinar de la mejor manera si el servidor está procesando las solicitudes de la aplicación como se espera.
•ASP.NET\Application Restarts: Indica el número de reinicios de la aplicación para determinar el tiempo real de servicio del servidor. Un valor alto de este indicador debe ser monitoreado con mayor detalle. Este tipo de contador junto con otros generales, puede ayudarle a identificar si hay un cuello de botella en el subsistema como tal, o producido en la aplicación.
•ASP.NET\Request Wait Time: Muestra la cantidad de tiempo (en milisegundos) que demoró la solicitud en cola de espera. Idealmente este valor debe ser cercano a 0 ms. Si por el contrario es mayor a 1000 ms, esto sugerirá que el servidor IIS tendrá aspectos por revisar/escalar dado que su rendimiento estará siendo impactado.
•ASP.NET\Requests Queued: La cola eventualmente se podrá llenar con solicitudes que esperan poder ser procesadas, por lo que este contador mostrará el número de solicitudes que se encolan. Debe ser monitoreado para esclarecer cuando una aplicación está siendo abrumada. Por lo tanto, un análisis del encolamiento de la aplicación en conjunto con contadores del servidor, proveerán una ayuda para determinar dónde está la causa.
•.NET CLR Memory\# Total Committed Bytes: Muestra la cantidad de memoria virtual reservada para la aplicación en el archivo de paginación. Debe monitorearse conjuntamente con otros contadores del servidor, para poder determinar si hay problemas de rendimiento. Los problemas pueden ser causados por una pequeña cantidad de memoria ya instalada, o porque una aplicación esté sobreutilizando la memoria.
•Web Service\Get Requests/sec: Muestra la cantidad de solicitudes tipo GET que se procesan por segundo. Si el valor no es óptimo para un servidor de IIS en particular (p.e en comparación con otros servidores), entonces el algoritmo de distribución de cargas del balanceador podrá replantearse para favorecer al servidor en cuestión (asumiendo que los servidores tienen características de hardware y software similares, o de lo contrario deberá tener en cuenta esas variables).
•Web Service\Post Requests/sec: Muestra la cantidad de solicitudes tipo POST que se procesan por segundo. Si el valor no es óptimo para un servidor de IIS en particular (p.e en comparación con otros servidores), entonces el algoritmo de distribución de cargas del balanceador podrá replantearse para favorecer al servidor en cuestión (asumiendo que los servidores tienen características de hardware y software similares, o de lo contrario deberá tener en cuenta esas variables).
•Web Service\Current Connections: Muestra el número de conexiones activas con el servicio. Si el valor no es óptimo para un servidor de IIS en particular (p.e en comparación con otros servidores), entonces el algoritmo de distribución de cargas del balanceador podrá replantearse para favorecer al servidor en cuestión (asumiendo que los servidores tienen características de hardware y software similares, o de lo contrario deberá tener en cuenta esas variables).
|
Así como en cualquier aplicación del IIS, se recomienda enfáticamente que vigile y realice afinamiento a los parámetros de reciclaje del pool de aplicación, de manera que dicha configuración no afecte de manera significativa a la operación dentro de horas laborales u horas pico. |
Monitoreo del Programador
El monitoreo del servicio Programador es fundamental para velar por una operación adecuada de Bizagi.
Dicho servicio debe estar permanentemente en un estado de ejecución para que las labores de mantenimiento de sistema de Bizagi se encuentren al día (p.e, la ejecución de este servicio no deberá verse interrumpida de manera inesperada).
|
Tenga presente que en algunos casos puede ser útil escalar horizontalmente el Programador, de manera que se cuente con múltiples instancias ejecutándose en paralelo (involucrando los nodos que sean necesarios). Esto se realiza con el fin de distribuir el procesamiento involucrado en las tareas que son llevadas a cabo por el Programador, que son principalmente: •Importar o sincronizar los usuarios contra un repositorio LDAP. •Importar o sincronizar la información de entidades paramétricas, vía la Replicación de datos de Bizagi. •Ejecutar las Actividades Asíncronas y sus reintentos. •Ejecutar los trabajos personalizados. •Enviar alarmas u otras notificaciones específicas. •Otras, como por ejemplo activar los temporizadores u otros patrones/eventos que impliquen una demora programada.
Por lo tanto y de acuerdo al dimensionamiento de su proyecto, producto del monitoreo pro-activo, o debido a otras características de su proyecto, evalúe si el uso de instancias adicionales del Programador proveerá una ayuda para su sistema. Nótese que el mantenimiento del sistema de Bizagi lo realiza también el Programador, sin embargo y en un clúster, esta labor la realiza la instancia maestra y no se distribuye por medio de un balanceo de cargas. |
De ocurrir algún error o comportamiento no esperado, Bizagi lo registrará en el log del servidor (p.e en un sistema operativo Windows, en el Visor de eventos).
Aspectos adicionales a monitorear son:
ASPECTOS A MONITOREAR |
INTERPRETACIÓN |
|---|---|
La ejecución de tareas por parte del servicio Programador de Bizagi |
Una tendencia incremental en la creación de tareas que deben ser ejecutadas por el Programador, contrastada con la capacidad actual del Programador para procesarlas, sugerirá que debe revisarse la configuración del mismo.
Al observar un incremento en las tareas que deben ser ejecutadas por el Programador y que se encolan, se debe considerar si se necesitan instancias adicionales del servicio Programador. |
Monitoreando el Servicio de Conectores
El monitoreo del Servicio de conectores es fundamental para garantizar la ejecución de los conectores externos instalados en su proyecto.
El servicio del conector debe estar permanentemente en modo iniciado para permitir que el conector se ejecute y genere rastros.
Aspectos adicionales de monitoreo:
ASPECTOS A MONITOREAR |
INTERPRETACIÓN |
|---|---|
Errores en el Event Viewer y archivos de logs |
Si observa algún error al ejecutar sus conectores, considere rastrear el conector para determinar la causa. |
Monitor del conector |
Puede revisar los registros del monitor del conector, que revisan constantemente si el servicio del conector está funcionando correctamente.
Puede encontrar estos registros en la siguiente carpeta: Bizagi Studio: C:\Program Files\Bizagi\Bizagi Studio\ConnectorsService Bizagi Engine: C:\Program Files\Bizagi\Engine\ConnectorsService
|
Usuario del sistema de Bizagi
El usuario (domain\admon) es el usuario de sistema empleado internamente por Bizagi (y creado por defecto). Este usuario debe estar siempre de manera activa y habilitado.Este usuario no se debe deshabilitar porque se requiere para realizar tareas automáticas tales como los temporizadores y trabajos programados, por esto es importante que revise si el usuario esta habilitado en la base de datos. Para más información del usuario Administrador haga clic acá.
Notas importantes sobre la base de datos
Es muy importante realizar un monitoreo en el motor de la base de datos para poder asegurar su adecuada operación y que pueda realizar consultas bajo el rendimiento esperado.
Al monitorear la base de datos y su rendimiento, usted podrá determinar si se requiere el escalamiento vertical de los servidores involucrados (o escalamiento horizontal en caso de usar un esquema de clúster activo-activo, como en el caso de Oracle RAC).
Para mayor información sobre los lineamientos tanto de monitoreo como de mantenimiento para la base de datos, consulte Mantenimiento de la base de datos.