Using Bizagi Diagnostics

<< Click to Display Table of Contents >>

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

Using Bizagi Diagnostics

 

Overview

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).

 

Diagnostics_start

 

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.

 

General layout

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.

 

Diagnostics_web01

 

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.

 

Diagnostics_web02

 

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.

 

Diagnostics_web00

 

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):

 

Diagnostics_zoom

 

Sharing charts

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:

 

Diagnostics_share

 

Overview

The overview option provides a first impression that seeks to summarize the general behavior of Bizagi Engine and its performance.

 

Diagnostics_web03

 

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.

 

Diagnostics_web04

 

note_pin

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.

 

Diagnostics_apdex

 

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).

 

Diagnostics_errorrate

 

 

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.

 

Discover

The discover option displays one chart to narrow down average duration for certain types of server events, and for specific data.

 

Diagnostics_discover

 

You may use its potential to dig into system activity by filtering the collected information and then clicking Apply changes.

 

Diagnostics_web06

 

Filtering options are described in the table below.

 

OPTION

DESCRIPTION

Show (duration)

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).

Stack by

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.

Event type

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:

 

Diagnostics_web07

 

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):

 

Diagnostics_topdown

 

 

note_pin

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:

 

Diagnostics_discoverevents

 

 

Health

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.

 

Diagnostics_health

 

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:

 

Diagnostics_healthdetails

 

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:

 

Diagnostics_web05

 

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.

 

Users

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).

 

Diagnostics_cusers

 

Errors

The errors option is a dedicated view that lists all reported errors while providing in-depth detail for each.

 

Diagnostics_errors

 

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.

 

Traces

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.

 

Diagnostics_traces

 

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.

 

note_pin

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.

 

Settings

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.