Infrastructure and platform monitoring
A fundamental task for project maintenance and administration in a Bizagi System, is monitoring the underlying platform which enables an operational Automation Server.
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, as well as other IT assets and services which are part of your system architecture and which are typically involved in the solution, such as storage and network services.
Adequate and pro-active monitoring lets you detect potential issues or bottlenecks to resolve, and helps you identify where focus your efforts.
The following guidelines provide a starting point and useful recommendations for monitoring and generating diagnostics the infrastructure and platform.
However, these guidelines do not cover every monitoring task a platform administrator needs to carry out, or tasks related to maintenance and upgrades (the information provided below is illustrative and not exhaustive).
Monitoring the infrastructure
We recommend that you permanently monitor for adequate operation and performance of critical IT assets and services.
For a Bizagi system, these aspects are specifically important:
1. Performance of the 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, refer to your storage provider documentation to determine the right monitoring procedures and recommendations for storage performance.
When database storage is presented to the Windows Server as a volume, you can use Windows Performance Monitor to identify possible data repository performance issues.
Best practices regarding storage performance analysis in a Windows environment are well documented by Microsoft as the vendor.
For more information, refer to http://blogs.technet.com/b/askcore/archive/2012/02/07/measuring-disk-latency-with-windows-performance-monitor-perfmon.aspx
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, refer to https://msdn.microsoft.com/en-us/library/ms190326.aspx).
Since the returned information might be difficult to understand, we recommend that you process to get a clear view of what is really happening with each database.
We recommend carrying out a thorough analysis. This blog post http://www.sqlskills.com/blogs/paul/how-to-examine-io-subsystem-latencies-from-within-sql-server/ provides a useful script for improving the readability of IO subsystem latencies.
For anOracle database, use Oracle Enterprise Manager to monitor performance aspect.
For more information, refer to Monitoring I/O options such as the one shown at https://docs.oracle.com/cd/B28359_01/server.111/b28275/tdppt_realtime.htm#CHDCCFDG.
3. Latency between the Bizagi servers and the database servers
Since Bizagi is an intensive data-access application, 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, low latency is usually achieved when you have the Bizagi server and database server on the same network segment and use a switch.
You can also monitor network latency between the Bizagi server and the database server with 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 can invoke the service through the browser, after setting the corresponding values for your [Bizagi_Server] and [Work_Portal_Site].
4. Connection between clients and the Bizagi servers.
For a corporate network (on-premise), or a VPN, you can monitor the network (in this case, the bandwidth is relevant) between the Bizagi Server and the clients with a PING command from the console of the client.
5. Other services.
Monitor other services which are external to Bizagi, but which are integrated into the solution.
This includes an ESB or other systems exposing web services; data sources for Bizagi; other services 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.
Services must be operational, and Bizagi should have granted access to services meant to provide access.
Monitoring the platform
To monitor the platform on which Automation Server components run, you can rely on the usual OS performance counters.
For health checks, or to measure and monitor performance of the Bizagi server platform, we recommend these performance counters 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 when deciding whether the CPU power of the IIS server is sufficient. This counter should remain below 85% for the system to be considered healthy.
•System\Processor Queue Length: The processor queue fills with threads when the server’s processors are busy servicing other threads. If this counter is usually above 2 and the % Processor Time remains at high levels, the processors are a bottleneck in the system.
•Memory\Available Mbytes: Refers to the amount of physical memory (measured in Mbytes) in the system that can be used by new processes. If the free memory is equal to 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%, examine the situation carefully and take steps to free up memory. If the free memory is below 5%, the performance of the system suffers.
•Memory\Pages/sec: Refers to the number of read and write requests from memory to disk. If this value remains high and the Available Mbytes are below 10%, then the Memory subsystem is a bottleneck. Fewer than 500 pages/sec is considered normal, more may affect system performance.
•Network Interface\Bytes Total/sec: Refers to the total number of bytes – both sent and received – over the network. If the value of this counter is usually greater than 80%, maybe another or faster network card should be installed on the server.
Make sure that your servers always have enough available free disk space.
Note that the appropriate available free disk space will depend on your project's implementation characteristics (given by your analysis for solution sizing and its growth rate) and your system architecture.
Whether for the database servers, the Bizagi servers, or any file servers involved for storage of documents, whenever used disk space gets close to capacity, necessary actions to free up space.
Running your servers with too little free disk space may result in performance issues and unexpected behaviors triggered by the operating system itself.
In addition, you may also consider: Paging file (% of use), Physical disk (% of disk time), or Logical disk (% of processor time).
As a best practice, keep track of any changes in your server's logbook.
Apart from updates, audit trails, or certain measures, all important changes should be registered in there with their corresponding timestamp.