We recommend a platform administrator monitor Bizagi services: the Work Portal, the Scheduler, and the connector server.
Make sure all services are running and operational at all times, and that they are performing adequately.
Adequate and pro-active monitoring will help you detect if there are potential issues or bottlenecks to resolve and where to make adjustments.
Monitoring the web server
Make sure you constantly monitor the service of the Bizagi web servers, such as IIS, provide.
You may rely on their logs.
Event Viewer logs
In addition to these logs, monitor events recorded by Bizagi.
For instance, on Windows operating systems, you can review the Windows Event Viewer (eventvwr).
Regarding Asynchronous Activities
Monitor how Bizagi Asynchronous Activities are processed.
These activities may run in the background, and may involve retries (for instance, due to an external interface being off-line).
If your project relies strongly on Asynchronous Activities, we recommend that you closely monitor their execution.
You can also rely on the Asynchronous Activities Console in the Work Portal, which displays tasks waiting for processing (due to a previous failed attempt).
Bizagi provides an additional log which we recommend that you monitor, which keeps track of those external services which present a delay or are unresponsive.
Whenever Bizagi invokes external web services, a new entry is recorded in a .csv file if the external service exceeds the expected time threshold to return a response, or produces a timeout.
This file is saved in the .\Temporary\SOA\Log\ path of your project, with one file being stored per web service, as C:\Bizagi\Projects\[your_project]\Temporary\SOA\Log\[your_interface]Log_1.csv.
Each file has one line per alert, with details including: DateTime, ErrorDescription, idCase, Task_Name, URL, Method_Name, and InterfaceTime(MM:ss:mmm).
Regarding the IIS
We recommend that you monitor the size of the IIS request queue to detect bottlenecks produced at the Bizagi servers.
Having a growing size of requests queued in the IIS (implying an increase in the number of requests in queue -a degrading pattern, suggests that your clustered configuration needs additional nodes.
Delays in processing requests which are not produced by external services (i.e in integration points in Bizagi) or not produced by the database server's capacity to deliver information, suggest that you should tune your Bizagi server or scaled them up if the delays are increasing in frequency.
Log files of the web thread found by default at the W3SVC folders of C:\inetpub\logs\LogFiles provide detail:
ASPECTS TO MONITOR
Log files of the Web threads
The files present the following data measured in milliseconds:
•timedb: The time it took for the database to deliver the information requested by the Bizagi server.
•timeba: The time it took Bizagi's Work Portal to process the request.
The sum of these figures adds up the total time it took to process a request once it started in the IIS not including not consider the time a request was waiting in queue.
Through IIS performance counters you may check whether requests are being left in the queue in an undesired/unexpected behavior.
You can monitor the Current queue size counter (under the HTTP Service Request queue classification) for the dedicated Bizagi application pool (by default named Bizagi 64-Bit ASP.NET v4.0) to determine queue behavior in the nodes.
You can also involve additional IIS-role specific performance counters, such as:
•ASP.NET Applications\Requests/Sec: Shows the throughput of the ASP.NET application on the server. It is monitored along with other counters to determine whether the server is handling the application as it’s supposed to.
•ASP.NET\Application Restarts: Indicates the number of restarts of the application in the server’s uptime. A high value for this indicator should be investigated. The general counters can help you identify whether it is caused by a bottleneck in the system or by the application itself.
•ASP.NET\Request Wait Time: Shows the amount of time (in milliseconds) that the last request was held in the queue. It should be close to 0 ms. If this indicator is usually greater than 1000 ms, performance of the IIS server is suffering.
•ASP.NET\Requests Queued: The queue fills up with requests that are waiting to be processed. This counter should be monitored to find out when an application is overwhelmed. Analyzing of the application and server performance together can help the administrator identify the cause for the filled queue.
•.NET CLR Memory\# Total Committed Bytes: Shows the amount of virtual memory reserved for the application on the paging file. It should be monitored along with the general counters to identify issues with performance of the IIS. Problems can be caused by having insufficient memory installed or by an application overusing the memory.
•Web Service\Get Requests/sec: Measures the number of GET requests processed in a second. If the value is not optimal for a particular IIS server when compared to other servers, you can apply load balancing or clustering technologies to lower the burden of the server in question. Check if server hardware and software characteristics are similar; if they are not, include them as variables in your analysis.
•Web Service\Post Requests/sec: Measures the number of POST requests processed in a second. If the value is not optimal for a particular IIS server when compared to other servers you can apply load balancing or clustering technologies to lower the burden of the server in question. Check if server hardware and software characteristics are similar; if they are not, include them as variables in your analysis.
•Web Service\Current Connections: Shows the number of active connections with that server's service. If the value is not optimal for a particular IIS server when compared to other servers you can apply load balancing or clustering technologies to lower the burden of the server in question. Check if server hardware and software characteristics are similar; if they are not, include them as variables in your analysis.
As with any IIS application, we strongly recommended that you tune and monitor the application pool's recycling parameters so that their settings do not affect your working or peak hours significantly.
Monitoring the Scheduler
Monitoring the Scheduler is fundamental to ensuring adequate operation of Bizagi.
The Scheduler must be permanently in a started mode to keep Bizagi system maintenance tasks up to date, this service should not be unexpectedly interrupted.
In some scenarios it may be useful to scale-up the Scheduler and use multiple instances running simultaneously (adding additional nodes as necessary).
This is especially useful to distribute the processing involved in tasks carried out by the Scheduler:
•Importing and synchronizing users with an LDAP repository.
•Importing and synchronizing information of parameter entities via Bizagi's Data Replication technology.
•Executing Asynchronous activities and their retries.
•Executing custom jobs.
•Sending alarms or other specific notifications.
•Others activities, such as triggering timers or other scheduled/time-based delays.
Depending on the sizing of your project, further pro-active monitoring or other characteristics of your implementation, decide whether using additional instances of the Scheduler service is needed.
System maintenance is also performed by the Scheduler, but in a cluster, these tasks are always performed by the master instance and not distributed/load balanced.
Should any error or unexpected behavior happen, the server's log (for instance, in a Windows operating system, in the Event Viewer) records it.
Additional aspects to monitor are:
ASPECTS TO MONITOR
Scheduler executing jobs
A growing trend in the creation of jobs to be executed by the Scheduler, when compared to the Scheduler's processing capacity, suggests reviewing its configuration.
If you notice an increase of jobs to be executed by the Scheduler in queue, consider additional instances for a clustered Scheduler configuration.
Monitoring the Connector Service
Monitoring the Connector Service is fundamental to ensuring the execution of external connectors installed in your project.
The Connector Service must be permanently in a started mode to let the connector run and generate traces.
Additional aspects to monitor are:
ASPECTS TO MONITOR
Errors in the Event Viewer and Log files
If you notice any error when executing your connectors, consider tracing the connector to determine the cause.
Connector monitor logs
You can review logs of the connector monitor, that constantly review if the Connector service is up and running correctly.
You can find these logs in the following folder:
Bizagi Studio: C:\Program Files\Bizagi\Bizagi Studio\ConnectorsService
Bizagi Engine: C:\Program Files\Bizagi\Engine\ConnectorsService
Bizagi system user
The domain\admon is the system user employed internally by Bizagi (created by default). You may not disable this user since it is needed to perform automatic tasks such as timers or scheduled jobs, and we recommend that you check that the user is enabled in the database. For further information about the Admon user, click here.
Important notes regarding the database
It is very important that you monitor the database engine to make sure that it is operational and that it can process the requested information in a timely fashion.
By monitoring the database and its performance, you can determine if you need to scale-up the servers hosting the database (or scale them out, when using an active-active cluster scheme such as Oracle RAC).
For more information about guidelines on both monitoring and maintenance of the database, refer to Database maintenance.