The process engine reports runtime metrics to the database that can help draw conclusions about usage, load, and performance of CIB seven. Metrics are reported in the database tables ACT_RU_METER_LOG and ACT_RU_TASK_METER_LOG. Single metric entries in ACT_RU_METER_LOG consist of a metric identifier, a value as natural number in the Java long range that the metric took in a certain timespan and a name identifying the metric reporter. Task metric entries in ACT_RU_TASK_METER_LOG comprise a fixed-length, pseudonymized assignee value and the point in time it was assigned at. There is a set of built-in metrics that are reported by default.

Built-in Metrics

The following table describes the built-in metrics. The identifiers of all built-in metrics are available as constants of the class org.camunda.bpm.engine.management.Metrics .

Querying

Metrics can be queried by making a MetricsQuery offered by the ManagementService. For example, the following query retrieves the number of all executed activity instances throughout the entire history of reporting:

long numCompletedActivityInstances = managementService
  .createMetricsQuery()
  .name(Metrics.ACTIVTY_INSTANCE_START)
  .sum();

The metrics query offers filters #startDate(Date date) and #endDate(Date date) to restrict the collected metrics to a certain timespan. In addition, by using the filter #reporter(String reporterId) the results can be restricted to metrics collected by a specific reporter. This option can be useful when configuring more than one engine against the same database, for example in a cluster setup.

Task metrics can be queried by using the getUniqueTaskWorkerCount method offered by the ManagementService. This method accepts optional Date values for startTime and endTime to restrict the metric to a certain timespan. For example, the following statement retrieves the number of all unique task workers until now:

long numUniqueTaskWorkers = managementService.getUniqueTaskWorkerCount(null, null);

Configuration

Metrics Reporter

The process engine flushes the collected metrics to the runtime database tables in an interval of 15 minutes. The behavior of metrics reporting can be changed by replacing the dbMetricsReporter instance of the process engine configuration. For example, to change the reporting interval, a process engine plugin replacing the reporter can be employed:

public class MetricsConfigurationPlugin implements ProcessEnginePlugin {

  public void preInit(ProcessEngineConfigurationImpl processEngineConfiguration) {
  }

  public void postInit(ProcessEngineConfigurationImpl processEngineConfiguration) {
    DbMetricsReporter metricsReporter = new DbMetricsReporter(processEngineConfiguration.getMetricsRegistry(),
        processEngineConfiguration.getCommandExecutorTxRequired());
    metricsReporter.setReportingIntervalInSeconds(5);

    processEngineConfiguration.setDbMetricsReporter(metricsReporter);
  }

  public void postProcessEngineBuild(ProcessEngine processEngine) {
  }

}

Reporter Identifier

Metrics are reported with an identifier of the reporting party. This identifier allows to attribute reports to individual engine instances when making a metrics query. For example in a cluster, load metrics can be related to individual cluster nodes. By default the process engine generates a reporter id as <local IP>$<engine name>. The generation can be customized by implementing the interface org.camunda.bpm.engine.impl.history.event.HostnameProvider and setting the engine property hostnameProvider to an instance of that class.

Disable Reporting

By default, all built-in metrics are reported. For the configuration via XML file (e.g. standalone.xml or bpm-platform.xml) you can disable reporting by adding the properties:

<property name="metricsEnabled">false</property>
<property name="taskMetricsEnabled">false</property>

If you are directly accessing the Java API, you can disable the metrics reporting by using the engine configuration flags isMetricsEnabled and isTaskMetricsEnabled and set them to false.