Bizagi Diagnostics is a toolkit featured by Bizagi Ltd in order to provide monitoring options for Bizagi Engine operations in a test or production environment.
The following section illustrates how to use Bizagi Diagnostics once it has been set up (as described at Setting up Bizagi Diagnostics).
Using Bizagi Diagnostics
Get started by clicking on the Bizagi Diagnostics shortcut created upon installation (alternatively use browser and go to the URL of the installed Bizagi Diagnostics web application --http://[your_server]/[Bizagi_diagnostics_website]/).
The shortcut will automatically open your default browser and load the Bizagi Diagnostics web application's overview page (may take a minute or so).
In there, you will find several options at the left hand panel, while allowing you to define a time frame to monitor in the upper part.
The general layout of the Bizagi Diagnostics web application is explained below, along with further detail regarding each of the options.
The main information you need to define to start monitoring your Bizagi Engine operation, is found in the upper part where you select:
•A time frame which will apply for all displayed information. Bizagi Diagnostics web application will show you the events of that given time frame (e.g, 1 minute, 5 minutes, 30 minutes, 1 hour, 3 hours, 6 hours, etc). Notice you may also fix the time frame with a specific start time and end time at the Custom date tab.
•An auto-refresh setting to determine If the Bizagi Diagnostics web application should keep displayed the latest information constantly (e.g, would mean that if you turn on the auto-refresh setting, while having a 5-minute time frame setting, you will constantly monitor the last 5 minutes of Bizagi Engine reported operations).
For instance, you can set auto-refresh to apply every second, every 5, 15 or 30 seconds, or by intervals of 1 or 5 minutes.
Notice if want to leave auto-refresh turned off, then you may use the Refresh button to manually update information.
Having set these parameters that indicate what you will be monitoring, each option on the left hand panel will present different views for the reported Bizagi Engine server events.
These views and charts are displayed in the main work area.
Detail on each option is described in the specific sections below.
Zooming in and out
Notice that at any time, in any chart, you may zoom in by defining an enclosed smaller time frame with your mouse (i.e by drawing a square to frame the portion you want to see in bigger detail):
Notice that at any time, in any chart, you may choose to produce a hyperlink that shares that same view for another user.
The hyperlink includes filtering options you are using for that chart:
The overview option provides a first impression that seeks to summarize the general behavior of Bizagi Engine and its performance.
It displays 3 charts:
•Average duration per request: The average time in milliseconds that requests are taking up to process (for the pre-defined time frame, shown in the chart as the horizontal axis).
The duration is presented while classified into 4 measurements:
oTotal duration: Decomposes into the following other 3 (it is their sum); and it is highlighted in a pale blue color.
oDatabase time: Represents the time spent in database engine tasks such as running SQL queries or procedures; and it is highlighted in a dark gray color.
oBizagi time: Represents the time spent in running logic or other Bizagi tasks; and it is highlighted in a pale green color.
oExternal time: Represents the time spent in wait for external systems to complete their tasks (e.g when Bizagi invokes interfaces).
It is highlighted in an orange color.
Given that Bizagi Engine provides a Work portal which is accessed through a browser (being a web application), a request in Bizagi includes those actions that produce an HTTP request to be sent over to the Bizagi server (and which in turn, require that Bizagi Engine processes and replies to each of those requests).
This means that a request as considered by these charts, includes whenever a new case is created, or an activity is completed, as well as other HTTP requests fired by the Work portal as needed by Bizagi.
•Bizagi Apdex indicator: A standard application performance index that will suggest under which conditions Bizagi Engine is operating (for the pre-defined time frame, shown in the chart as the horizontal axis).
Scoring is assigned as excellent, good, regular or bad (calculated as standard Apdex score from 0 to 1).
Whenever Bizagi Engine starts up or is restarted, the Apdex may show that Bizagi may take a minute or so to reach a state of optimal performance.
•Error rate (percentage): The percentage of reported errors while considering the successful requests (for the pre-defined time frame, shown in the chart as the horizontal axis).
Note that you should always watch after any errors presented (follow them up and resolve them), and aim at having a 0% error rate, or as close as possible to zero.
The discover option displays one chart to narrow down average duration for certain types of server events, and for specific data.
You may use its potential to dig into system activity by filtering the collected information and then clicking Apply changes.
Filtering options are described in the table below.
Allows you to define if you want to filter only reports which exceed a certain amount of time in milliseconds (by using the slider).
You may also define if you wish to filter by total duration, by database time, Bizagi time, or by external time (duration/time definitions apply the same as in the average duration per request chart).
Allows you to classify and stack the results by:
•Bizagi operation: Having detail in layers (stacked), for the type of operation executed by Bizagi (e.g, clicking Save, Next, or creating a new process).
•Process: Having detail in layers (stacked), according to the different processes of your project.
•Server instance: Having detail in layers (stacked), according to the different servers of your cluster.
•Source: Having detail in layers (stacked), according to the different Bizagi Engine components such as the Web application or the Scheduler service.
•Task name: Having detail in layers (stacked), according to the different activities in your project's processes.
•User: Having detail in layers (stacked), according to the different end users accessing your Work portal.
Allows you to define if you want the be able to filter information by seeing below a list of events.
•Bizagi operation: Those events associated to the regular operations run by Bizagi such as clicking Save, Next, or creating a new process.
•Get jobs: Those events associated to custom jobs as run by the Scheduler.
•Query: Those events associated to running queries at the database.
•Request: Those events associated to the regular operations run by Bizagi in overall requests.
•Thread: Those events associated to whenever the Scheduler fires new threads for programmed tasks.
Once you define this setting, you will be able to narrow down each bit of information that can be displayed in the chart. For example, for Query type events, you may notice you can then choose to mark Web application or Scheduler and Apply changes:
To mark or unmark bits of information regarding the events, consider the definitions above at the Stack by filters section, in addition to these other ones:
•Case number: List the process instances (i.e cases) which are reported.
•SQL: Lists the SQL statement or query which are reported as executed by Bizagi.
An in-depth look at SQL statements which show a significant delay, may indicate that some tables need database tuning (you may hand over such queries -when these handle your business tables- to your DBA in order for him/her to review statistics and indexes).
•URL: Lists the URL of the invoked REST services which are reported.
When viewing the chart, notice you may use top-down analysis options located in the upper right part (by default starts minimized), in order to totalize information (totalize as percentage, average or a count):
It is often important to review the number of counts for events which show a slow response time.
A lower number of counts for those events, may indicate that a given SQL query or invoked URL is part of the resources Bizagi Engine loads upon application startup or restart (in which case, it could be considered normal for those resources to present a much bigger delay when compared to transactional operations which occur on much greater scale).
Similarly, the lower part (by default starts minimized), will show a table with detail of the recorded events that compose the information of the chart.
Notice this table includes: Server instance, source component, event type, timestamp, the different duration measures (total duration, database time, Bizagi time, external time) and significant tags:
The health option displays the overall health status of all Bizagi Engine components reporting to Bizagi Diagnostics.
You will view a diagram illustrating your Bizagi system architecture with more than 1 Web server or Scheduler service being active when applicable.
The diagram shows average availability (server uptime for the Work portal or Scheduler service) for the pre-defined time frame.
Similarly, average time to the database is displayed for the Work portal or Scheduler service.
For the Work portal instances (Web servers), you may hover on each, and click Check health to run an immediate check on its associated resources availability:
For the Work portal instances (Web servers), you may hover on each, and click Detail to see its reported health status in terms of availability and latency:
For the Scheduler service instances, you may similarly hover on each, and click Detail to see its reported health status in terms of availability and latency, just the same as with Web servers.
The users option is a dedicated view to show the number of concurrent users working simultaneously (for the pre-defined time frame, shown in the chart as the horizontal axis).
The errors option is a dedicated view that lists all reported errors while providing in-depth detail for each.
This view considers a chart in the upper part to display the total number of errors (for the pre-defined time frame, shown in the chart as the horizontal axis), while showing a table with the detail of those reported errors having: the case instance, source, timestamp, the error exception, and diagnostic tags.
The traces option is a dedicated view that lists all custom tracing that is written in scripting expressions by means of the CHelper.trace() method solely.
Traces displayed by this view will allow you to browse according to the timestamp, server instance, source (Web application or Scheduler), category (name of the trace) or the logged data.
In order to make the most of this view, it is recommended to rely on a standard nomenclature for your traces (e.g, possibly including the case identifier in its file name) that you coordinate with you other team work members.
The settings option allows you to change settings uniformly for all of your Bizagi Engine components so that you can define which server events are reported into logs.
For more information about this option, refer to General pointers and tuning tips.