Метрики

Этот раздел перенесён из документации Camunda 7 и в дальнейшем будет доработан с учётом особенностей OpenBPM Engine

Движок процессов отправляет runtime-метрики в базу данных, что помогает делать выводы об использовании, нагрузке и производительности Camunda 7. Метрики записываются в таблицы базы данных ACT_RU_METER_LOG и ACT_RU_TASK_METER_LOG. Отдельные записи метрик в ACT_RU_METER_LOG состоят из идентификатора метрики, значения в виде натурального числа в диапазоне Java long, которое метрика приняла за определенный интервал времени, и имени, идентифицирующего источник метрики. Записи task-метрик в ACT_RU_TASK_METER_LOG включают псевдонимизированное значение assignee фиксированной длины и момент времени, когда оно было назначено. По умолчанию отправляется набор встроенных метрик.

Встроенные метрики

В следующей таблице описаны встроенные метрики. Идентификаторы всех встроенных метрик доступны как константы класса {{< javadocref page="org/camunda/bpm/engine/management/Metrics.html" text="io.openbpm.bpm.engine.management.Metrics" >}}.

Категория	Идентификатор	Описание
Выполнение BPMN	root-process-instance-start*	Количество запущенных выполнений корневых экземпляров процесса. Это также известно как Process Instances (PI). Корневой экземпляр процесса не имеет родительского экземпляра процесса, то есть это выполнение верхнего уровня.
	activity-instance-start*	Количество запущенных экземпляров flow node (экземпляров активностей) (FNI).
	activity-instance-end	Количество завершенных экземпляров flow node (экземпляров активностей).
Выполнение DMN	executed-decision-instances*	Количество вычисленных экземпляров решений (DI). Экземпляр решения - это таблица решений DMN или DMN Literal Expression.
	executed-decision-elements*	Количество элементов решения, выполненных при вычислении таблиц решений DMN. Для одной таблицы это рассчитывается как количество условий, умноженное на количество правил.
Job Executor	job-successful	Количество job, успешно выполненных.
	job-failed	Количество job, выполнение которых завершилось ошибкой и которые были отправлены на повторную попытку. Учитывается каждая неудачная попытка выполнения job.
	job-acquisition-attempt	Количество выполненных циклов получения job.
	job-acquired-success	Количество job, которые были получены и успешно заблокированы для выполнения.
	job-acquired-failure	Количество job, которые были получены, но не могли быть заблокированы для выполнения из-за того, что другой job executor параллельно заблокировал/выполнял эти job.
	job-execution-rejected	Количество успешно полученных job, отправленных на выполнение, но отклоненных из-за насыщения ресурсов выполнения. Это признак того, что очередь job пула потоков выполнения заполнена.
	job-locked-exclusive	Количество exclusive job, которые немедленно блокируются и выполняются.
Task-метрики	unique-task-workers*	Количество пользователей задач (TU), которые выступали assignee.
Очистка истории	history-cleanup-removed-process-instances	Количество экземпляров процессов, удаленных очисткой истории.
	history-cleanup-removed-case-instances	Количество экземпляров case, удаленных очисткой истории.
	history-cleanup-removed-decision-instances	Количество экземпляров решений, удаленных очисткой истории.
	history-cleanup-removed-batch-operations	Количество batch-операций, удаленных очисткой истории.
	history-cleanup-removed-task-metrics	Количество task-метрик, удаленных очисткой истории.

Категория

Идентификатор

Описание

Выполнение BPMN

root-process-instance-start*

Количество запущенных выполнений корневых экземпляров процесса. Это также известно как Process Instances (PI). Корневой экземпляр процесса не имеет родительского экземпляра процесса, то есть это выполнение верхнего уровня.

activity-instance-start*

Количество запущенных экземпляров flow node (экземпляров активностей) (FNI).

activity-instance-end

Количество завершенных экземпляров flow node (экземпляров активностей).

Выполнение DMN

executed-decision-instances*

Количество вычисленных экземпляров решений (DI). Экземпляр решения - это таблица решений DMN или DMN Literal Expression.

executed-decision-elements*

Количество элементов решения, выполненных при вычислении таблиц решений DMN. Для одной таблицы это рассчитывается как количество условий, умноженное на количество правил.

Job Executor

job-successful

Количество job, успешно выполненных.

job-failed

Количество job, выполнение которых завершилось ошибкой и которые были отправлены на повторную попытку. Учитывается каждая неудачная попытка выполнения job.

job-acquisition-attempt

Количество выполненных циклов получения job.

job-acquired-success

Количество job, которые были получены и успешно заблокированы для выполнения.

job-acquired-failure

Количество job, которые были получены, но не могли быть заблокированы для выполнения из-за того, что другой job executor параллельно заблокировал/выполнял эти job.

job-execution-rejected

Количество успешно полученных job, отправленных на выполнение, но отклоненных из-за насыщения ресурсов выполнения. Это признак того, что очередь job пула потоков выполнения заполнена.

job-locked-exclusive

Количество exclusive job, которые немедленно блокируются и выполняются.

Task-метрики

unique-task-workers*

Количество пользователей задач (TU), которые выступали assignee.

Очистка истории

history-cleanup-removed-process-instances

Количество экземпляров процессов, удаленных очисткой истории.

history-cleanup-removed-case-instances

Количество экземпляров case, удаленных очисткой истории.

history-cleanup-removed-decision-instances

Количество экземпляров решений, удаленных очисткой истории.

history-cleanup-removed-batch-operations

Количество batch-операций, удаленных очисткой истории.

history-cleanup-removed-task-metrics

Количество task-метрик, удаленных очисткой истории.

*Некоторые enterprise-соглашения требуют ежегодной отчетности по части метрик. Сохраняйте эти метрики как минимум 18 месяцев.

Запросы

Метрики можно запрашивать через {{< javadocref page="org/camunda/bpm/engine/management/MetricsQuery.html" text="MetricsQuery" >}}, предоставляемый ManagementService. Например, следующий запрос получает количество всех запущенных экземпляров активностей за всю историю отчетности:

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

Запрос метрик предоставляет фильтры #startDate(Date date) и #endDate(Date date), чтобы ограничить собранные метрики определенным интервалом времени. Кроме того, с помощью фильтра #reporter(String reporterId) можно ограничить результаты метриками, собранными конкретным репортером. Эта опция может быть полезна, когда к одной базе данных подключено более одного движка, например в кластерной конфигурации.

Task-метрики можно запрашивать методом getUniqueTaskWorkerCount, предоставляемым ManagementService. Этот метод принимает необязательные значения Date для startTime и endTime, чтобы ограничить метрику определенным интервалом времени. Например, следующее выражение получает количество всех уникальных task worker на текущий момент:

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

Конфигурация

Репортер метрик

Движок процессов сбрасывает накопленные метрики в runtime-таблицы базы данных с интервалом 15 минут. Поведение отчетности метрик можно изменить, заменив экземпляр dbMetricsReporter в конфигурации движка процессов. Например, чтобы изменить интервал отчетности, можно использовать plugin движка процессов, который заменяет репортер:

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) {
  }

}

Записи task-метрик создаются при каждом назначении пользовательской задачи. Это поведение нельзя изменить, и оно не относится к зоне ответственности репортера метрик.

Идентификатор репортера

Метрики отправляются с идентификатором источника отчетности. Этот идентификатор позволяет привязывать отчеты к отдельным экземплярам движка при выполнении запроса метрик. Например, в кластере метрики нагрузки можно соотнести с отдельными узлами кластера. По умолчанию движок процессов генерирует идентификатор репортера как <local IP>$<engine name>. Генерацию можно настроить, реализовав интерфейс {{< javadocref page="org/camunda/bpm/engine/impl/history/event/HostnameProvider.html" text="io.openbpm.bpm.engine.impl.history.event.HostnameProvider" >}} и установив свойство движка hostnameProvider в экземпляр этого класса.

Интерфейс {{< javadocref page="org/camunda/bpm/engine/impl/metrics/MetricsReporterIdProvider.html" text="io.openbpm.bpm.engine.impl.metrics.MetricsReporterIdProvider" >}} и соответствующее свойство движка metricsReporterIdProvider объявлены устаревшими.

Отключение отчетности

По умолчанию отправляются все встроенные метрики. Для конфигурации через XML-файл (например, standalone.xml или bpm-platform.xml) вы можете отключить отчетность, добавив свойства:

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

Если вы напрямую используете Java API, можно отключить отчетность метрик с помощью флагов конфигурации движка isMetricsEnabled и isTaskMetricsEnabled, установив их в false.

Лицензия и атрибуция

Эта документация была создана на базе материала "Camunda 7 Docs" от Camunda, находится под лицензией Creative Commons Attribution-ShareAlike 3.0 Unported License .

Оригинал документации: https://docs.camunda.org