Infrastructure and platform monitoring

<< Click to Display Table of Contents >>

Navigation:  Bizagi Engine > Bizagi system administration > Maintenance and administration > Monitoring >

Infrastructure and platform monitoring


A fundamental task for project maintenance and administration in a Bizagi System, is to monitor the underlying platform which enable an operational Bizagi Engine.

A platform administrator should be alert to any significant changes or abnormalities in the system's behavior and performance, and in charge of taking proper actions when necessary.

Infrastructure and platform services to monitor include the servers on which Bizagi components run, but it also considers other IT assets and services which make part of your system architecture and which are typically immerse in the solution, such as the storage or network.

Adequate and pro-active monitoring will allow you detect if there are potential issues or bottlenecks to resolve and where to do so.





The following guidelines provide a starting point as well as useful recommendations for purposes of monitoring and diagnostics the infrastructure and platform.

However, these guidelines do not cover up exactly every task a platform administrator needs to carry out regarding such purposes, or regarding further maintenance (the information provided below is illustrative and not exhaustive).


Monitoring the infrastructure

It is recommended to permanently monitor the adequate operation and performance of critical IT assets and services.

For a Bizagi system, these aspects are specifically important:


1. Performance of physical data repository (SAN).

In a typical enterprise implementation, the databases, files, virtual machines and other IT assets, reside in a repository that is separated from the physical servers and shared among different servers and other computing devices.

If this is your case, please refer to your storage provider documentation in order to determine the right monitoring procedures and recommendations regarding storage performance.

When the database storage is presented to the Windows Server as a volume, it is possible to use Windows Performance Monitor as the means to identify possible data repository performance issues.

Best practices regarding storage performance analysis in a Windows environment are well documented by the Microsoft as the vendor.

For more information, refer to


2. Latency between database servers and SAN.

Monitoring physical disk latency can be achieved by using specific commands as provided by the database engine vendor.


For instance, the sys.dm_io_virtual_file_stats Transact-SQL (as provided by SQL Server), serves this purpose.

For more information on the command please refer to

Since the returned information might be difficult to understand, it is recommended to process it in order to get a clear view of what is really happening with each database.

We recommend carrying out a thorough analysis. For instance, this blog post provides a useful script for improving the readability of IO subsystem latencies.


For Oracle database, you may rely on the use of Oracle Enterprise Manager to monitor such aspect.

For more information, refer to Monitoring I/O options such as the one shown at


3. Latency between the Bizagi servers and the database servers.

Given that Bizagi is an intensive data-access application, you will need to consider these optimal measures for the network connection between the Bizagi servers and the database servers:


Low latency: The network should have a latency of 0,15 ms (on average). In corporate system architectures, a low latency is usually achieved while having the Bizagi server and database server on the same network segment and involving a switch.

Monitoring network latency between the Bizagi server and the database server can be also achieved by means of a PING command from the console.


Adequate bandwidth: The recommended bandwidth is at least 10,000 kb in 64ms, according to the results presented when invoking the following RESTful service:


You may invoke such service by using the browser, once having ensured that you set your the corresponding values for your [Bizagi_Server] and [Work_Portal_Site].




4. Connection between clients and the Bizagi servers.

Specially for the corporate network (on-premise), or a VPN, monitoring the network (in this case, the bandwidth is relevant) between the Bizagi Server and the clients can be achieved by posting a PING command from the console of the client.


5. Other services.

Recall that you should monitor other services which are external to Bizagi, but which are integrated to the solution.

This includes an ESB or other systems exposing web services, or data sources to Bizagi, other services as offered by the corporate E-mail server, the file server or ECM repositories, as well as any system or repository used for authentication purposes (e.g, the Active Directory), or additional appliances such as firewalls or a load balancer.

Keep in mind that services must be operational, and that Bizagi should have granted access when applicable (to those meant to provide access).



Monitoring the platform

To monitor the platform on which Bizagi Engine components run, you may rely on usual OS performance counters.

For health checks, or to measure and monitor the performance of the Bizagi server platform, these performance counters as recommended (in addition to any other you consider relevant):


Processor\% Processor Time: Refers to the average percentage of processor time occupied. It is a main indicator to consider when deciding whether the CPU power of the IIS server is enough. It is recommended for this counter to remain below 85% for the system to be considered healthy.

System\Processor Queue Length: The processor queue is being filled up with threads when the server’s processors are busy servicing other threads at the moment. If this counter is usually above 2 and the % Processor Time remains on high levels, then the processors are considered a bottleneck in the system.

Memory\Available Mbytes: Refers to the amount of physical memory (measured in Mbytes) on the system that can be used by new processes. If the free memory is equal or greater than 50%, the system is considered healthy. A value of 25% free memory indicates a potential problem. If the memory is below 10%, the condition has to be examined carefully and precautions have to be taken. If the free memory is less than 5%, the performance of the system is negatively impacted.

Memory\Pages/sec: Refers to the amount of read and write requests from memory to disk. If this value remains high and the Available Mbytes are less than 10%, then the Memory subsystem is considered a bottleneck. Less than 500 Pages/sec are considered normal, more than 500 may affect system’s performance.

Network Interface\Bytes Total/sec: Refers to the total amount of bytes – both sent and received – over the network. If the value of this counter is usually greater than 80%, then maybe another or faster network card should be installed on the server.



Ensure that your servers always have enough available free disk space.

Note that he appropriate available free disk space will depend on your project's implementation characteristics (given by your analysis for the solution's sizing and its growth rate) and your system architecture involved.


Whether for the database servers, the Bizagi servers, or any file servers involved for storage of documents, whenever used disk space gets close to the capacity, then you should take necessary actions.

Running your servers with an inappropriate amount of free disk space may result in performance issues and unexpected behaviors triggered by the operating system itself as well.


In addition to the above, you may also consider: Paging file (% of usage), Physical disk (% disk time), or Logical disk (% processor time).



As a best practice, you should keep track of any recorded changes in your server's logbook as well.

Apart from updates or audit trails, or certain measures, all important changes should be registered in there (with their corresponding timestamp).