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

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

При интенсивном использовании движок управления процессами может произвести огромное количество исторических данных. History Cleanup (очистка истории) — это функция, которая позволяет удалять эти данные на основании конфигурационных настроек по времени жизни.

При очистке удаляются:

Исторические экземпляры процессов со всеми относящимися к ним историческими данными (например, экземплярами исторических переменных, задач, разрешений, все относящиеся к ним комментарии и аттачменты и т.д.)
Исторические экземпляры решений и вся относящаяся к ним историческая информация (например, экземпляры входных и выходных данных исторических решений)
Исторические экземпляры сценариев и все относящиеся к ним исторические данные (например, экземпляры исторических переменных, задач и т.д.)
Исторические batch-и и вся относящаяся к ним историческая информация (исторические инциденты и логи джоб)

Очистку истории можно запустить вручную или поставить в расписание и производить регулярно. Только члены группы camunda-admins имеют разрешение на выполнение очистки истории вручную.

Пример сценария использования

Предположим, что у нас етсь процесс для биллинга, по которому мы должны хранить исторический след в течение 10 лет по причине необходимости соответствия закону. Далее, у нас есть также процесс подачи заявления на отпуск, по которому исторические данные остаются релевантными только на короткий период времени. Чтобы снизить количество данных, которые нам необходимо сохранять, мы хотим быстро удалить данные, относящиеся к отпускам.

С помощью функции очистки истории мы можем назначить процессу биллинга время жизни истории в десять лет, а процессу оформления отпуска время жизни истории в семь дней. Функция очистки истории гарантирует, что все данные будут удалены, как только истечет их срок жизни. Таким образом мы можем избирательно хранить исторические данные на основании их важности для нашего бизнеса. В то же самое время, в базе данных мы храним только то, что необходимо.

Примечание: Точное время удаления данных зависит от пары настроек конфигурации, например, от выбранной стратегии очистки истории (history cleanup strategy). Базовые концепции и настройки разъясняются в последующих разделах.

Базовые концепции

Очищаемые экземпляры

Очищаемыми являются следующие элементы истории Camunda:

Экземпляры процесса
Экземпляры решения
Экземпляры сценария
Batch-и

Обратите внимание, что очистка одного такого экземпляра всегда удаляет вместе с ним всю зависящую от него историю. Например, очистка экземпляра процесса удаляет исторический экземпляр процесса и все экземпляры его исторических активностей, исторические экземпляры задач и т.д.

ПРИМЕЧАНИЕ:

Джоба, осуществляющая очистку истории , не удаляет исторические джобы timer-start-event. Причиной этого является то, что задачей джобы timer-start-event является запуск экземпляра процесса, то есть, она не принадлежит экземпляру процесса.

Время жизни истории

Время жизни истории (Time To Live, TTL) определяет, насколько долго исторические данные останутся в базе данных до того, как их удалят при очистке.

Экземпляры процессов, сценариев и решений: TTL можно задать в XML файле соответствующего определения. Это значение может быть изменено в дальнейшем после деплоймента через Java и REST API.
Batch-и: TTL может задаваться в конфигурации движка управления процессами.

См. раздел о TTL конфигурации, чтобы узнать, как устанавливать TTL.

Время окончания для экземпляров

Время окончания (End time) — это тот момент времени, когда экземпляр перестает быть активным.

Экземпляры процессов: время, когда экземпляр заканчивает работу.
Экземпляры решений: время, когда решение прошло оценку.
Экземпляры сценариев: время, когда экземпляр завершает выполнение.
Batch: Время, когда batch заканчивает выполнение.

Время окончания сохраняется в соответствующих таблицах экземпляров: ACT_HI_PROCINST, ACT_HI_CASEINST, ACT_HI_DECINST и ACT_HI_BATCH.

Время удаления экземпляра

Время удаления (Removal Time) — это время, после которого экземпляр будет удален. Оно вычисляется по формуле время удаления = базовое время + TTL. Базовое время конфигурируется и может равняться либо времени старта, либо времени окончания экземпляра. В частности, это означает:

Экземпляры процессов: базовое время — это либо время, когда экземпляр процесса запускается, либо время, когда он заканчивает работу. Это можно конфигурировать.
Экземпляры решений: базовое время — это время, когда оценка решения завершена.
Экземпляры сценариев: концепция времени удаления не реализована для экземпляров сценариев.
Batch: базовое время — это либо время, когда batch создан, либо время, когда batch завершает работу. Это можно конфигурировать.

Для экземпляров процессов и решений внутри иерархии (например, когда экземпляр процесса запускается другим экземпляром процесса через BPMN Call Activity), время удаления всех экземпляров усегда равно времени удаления корневого экземпляра.

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

Время удаления сохраняется во всех исторических таблицах. Таким образом, в случае с экземпляром процесса время удаления присутствует в ACT_HI_PROCINST, также в соответствующих вторичных вхождениях в ACT_HI_ACTINST, ACT_HI_TASKINST и т.д.

См. раздел конфигурация стратегии времени удаления, чтобы узнать, как осуществлять уонфигшурацию, если время удаления основано на времени старта или времени окончания экземпляра.

Стратегии очистки

Чтобы использовать очистку истории, вам необходимо решить, какую из двух доступных стратегий очистки выбрать: Removal-Time-based или End-Time-based. Стратегия Removal-Time-based является опцией по умолчанию и рекомендуется для большинства сценариев. Обе стратегии и их различия будут детально описаны в последующих разделах. См. раздел конфигурирование стратегии очистки, чтобы узнать, как конфигурировать каждую из стратегий.

Стратегия "Removal-time-based"

Стратегия очистки removal-time-based (основанная на времени удаления) удаляет данные, для которых прошло время удаления.

Преимущества:

Поскольку каждая таблица истории имеет атрибут removal time (время удаления), очистка истории может быть произведена при помощи простых SQL запросов типа DELETE FROM <TABLE> WHERE REMOVAL_TIME_ < <now>. Это намного проще, чем при использовании стратегии end-time-based.
Поскольку время удаления совпадает для всех экземпляров внутри одной иерархии, такая иерархия всегда зачищается сразу и целиком, как только проходит время удаления. Ситуация, при котороой экземпляры будут удалены в разное время, невозможна.

Ограничения:

Модет удалять только те данные, для которых задано время удаления. Эьтого может не произойти, особенно с данными, созданными в Camunda любой версии старше 7.10.0.
Изменения TTL определения применяется только к данным истории, которые будут созданы в будущем. При этом не происходит динамического обновления времени удаления для уже сохраненных исторических данных. Однако, существует возможность установить время удаления через Batch-операции.
Исторические данные для экземпляров сценариев не очищаются.

Стратегия "End-time-based"

Стратегия очистки end-time-based (основанная на времени окончания) удаляет данные, для которых прошло время окончания + TTL. По контрасту со стратегией removal-time, это значение вычисляется при каждом выполнении очистки истории.

Преимущества:

Изменение TTL определения вличет также на уже сохраненные исторические данные.
Может удалять данные от любой версии Camunda.

Ограничения:

Время окончания сохраняется только в таблицах экземпляров (ACT_HI_PROCINST, ACT_HI_CASEINST, ACT_HI_DECINST и ACT_HI_BATCH). Чтобы удалить данные из всех таблиц истории, очищаемые экземпляры сначала загружаются через запрос типа SELECT. На основании этих загруженных данных для каждой таблицы истории выполняются запросы типа DELETE. Эти запросы могут включать join-конструкции. Это менее эффективно, чем очистка истории по стратегии removal-time-based.
Иерархии экземпляров не зачищаются автоматически. Поскольку индивидуальные экземпляры имеют различные времена окончания, их очистка будет происходить в разное время. В результате появятся частично удаленные иерархии.
Разрешения на исторических экземплярах не очищаются.
Джобы очистки истории не удаляются из лога исторических джоб.

Взгляд на очистку изнутри

Очистка истории реализована через джобы (jobs) и выполняется при помощи job executor. Соответственно, она конкурирует за ресурсы с другими джобами, eНапример, с триггерами событий таймера в BPMN.

Выполнение очистки можно контролировать тремя способами:

Окно очистки (Cleanup Window): задает временные рамки, внутри которых происходит очистка истории. Это позволяет нам использовать ресурсы job executor-а только когда нагрузка на системы мала (например, ночью или в выходные). По умолчанию окно очистки не задается. Это означает, что очистка истории не производится автоматически.
Размер Batch: задает, сколько экземпляров может быть очищено в одной транзакции. По умолчанию: 500.
Степень параллелизма (Degree of Parallelism): задает, сколько джоб очистки может работать параллельно. По умолчанию: 1 (параллельное выполнение отсутствует).

См. раздел по конфигуриции очистки, чтобы узнать, как задавать эти значения.

Если не осталось доступных для очистки данных, джоба уходит на экспоненциально растущий перерыв между прогонами, чтобы уменьшить нагрузку на систему. Такой перерыв ограничен максимальной продолжительностью в один час. Он не относится к запускам очистки вручную.

Если очистка не удалась, применяется механизм повторных попыток job executor-а. Когда у джобы очистки заканчиваются повторные попытки, она не будет запускаться вновь, пока не будет выполнено одно из следующих действий:

Запуск очистки истории запущена вручную
Перезапуск движка управления процессами (это действие сбрасывает количество повторных попыток для джобы в значение по умолчанию)
Увеличение количества повторных попыток вручную (например, с помощью Java или REST API)

Джобы зачистки истории можно найти через метод API HistoryService#findHistoryCleanupJobs.

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

Время жизни истории

Обязательное свойство

Время жизни истории является обязательным, любой деплоймент или повторный деплоймент любого модельного ресурса (BPMN, DMN, CMMN), содержащего historyTimeToLive равное null, будет предотвращаться, если только оно не отключено явно через конфигурацию движка управления процессами. Чтобы задать TTL по умолчанию для определений процессов и определений решений, если не задано никакое другое значение, обратитесь к конфигурации historyTimeToLive.

Определения процессов/решений/сценариев

Экземпляры процессов очищаются только в том случае, когда их соответствующее определение имеет валидное время жизни (TTL). Используйте атрибут расширения "historyTimeToLive" определения процесса, чтобы задать TTL для всех его экземпляров:

<process id="oneTaskProcess" name="The One Task Process" isExecutable="true" camunda:historyTimeToLive="5">
...
</process>

TTL можно также задавать в формате данных ISO-8601. Функция принимает нотацию только для задания количества дней.

<process id="oneTaskProcess" name="The One Task Process" isExecutable="true" camunda:historyTimeToLive="P5D">
...
</process>

После деплоймента TTL можно обновлять через Java API:

  processEngine.getRepositoryService().updateProcessDefinitionHistoryTimeToLive(processDefinitionId, 5);

Установка значения в null очищает TTL. То же самое можно сделать с помощью {{< restref page="updateHistoryTimeToLiveByProcessDefinitionKeyAndTenantId" text="REST API" tag="Process-Definition" >}}.

Для определений решений и сценариев TTL можно задать подобным образом.

Если вы хотите предоставить значение TTL по умолчанию для всего движка и всех определений процессов, решений и сценариев, используйте атрибут "historyTimeToLive" из конфигурации движка управления процессами. Это значение применяется как значение по умолчанию во всех случаях, когда деплоится определение без TTL. Обратите внимание, что оно не меняет TTL для уже задеплоенных определений. Используйте приведенный выше метод API, чтобы изменить TTL в таких случаях.

Batch-и

TTL для batch-ей можно задать через атрибут конфигурации движка управления процессами.

<!-- default setting for all batch operations -->
<property name="batchOperationHistoryTimeToLive">P5D</property>

Свойство batchOperationsForHistoryCleanup можно сконфигурировать в приложении, написанном на Spring или через кастомные плагины движка управления процессами. Это задает время жизни истории для каждой конкретной исторической batch-операции.

<!-- specific TTL for each operation type -->
<property name="batchOperationsForHistoryCleanup">
  <map>
    <entry key="instance-migration" value="P10D" />
    <entry key="instance-modification" value="P7D" />
    <entry key="instance-restart" value="P1D" />
    <entry key="instance-deletion" value="P1D" />
    <entry key="instance-update-suspension-state" value="P20D" />
    <entry key="historic-instance-deletion" value="P4D" />
    <entry key="set-job-retries" value="P5D" />
    <entry key="set-external-task-retries" value="P5D" />
    <entry key="process-set-removal-time" value="P0D" />
    <entry key="decision-set-removal-time" value="P0D" />
    <entry key="batch-set-removal-time" value="P0D" />
    <entry key="set-variables" value="P1D" />
    <entry key="correlate-message" value="P2D" />
    <!-- in case of custom batch jobs -->
    <entry key="custom-operation" value="P3D" />
  </map>
</property>

Если конкретное значение TTL не установлено для некоего типа batch-операции, то применяется опция batchOperationHistoryTimeToLive.

Логи джоб

Очистка истории всегда производится посредством выполнения джобы очистки истории. Как и все остальные джобы, эта джоба будет создавать события, которые логируются в лог исторических джоб. По умолчанию эти вхождения останутся в логе на неопределенное время, и их очистка должна выполняться в явном виде. Обратите внимание, что это работает только для стратегии очистки истории removal-time-based.

Свойство historyCleanupJobLogTimeToLive может использоваться для задания TTL для записей в логе для исторических джоб, порожденных джобами очистки истории. Это свойство прннимает значения в формате даты ISO-8601. Отметим, что разрешена только нотация, задающая количество дней.

<property name="historyCleanupJobLogTimeToLive">P5D</property>

Метрики задачи

Движок управления процессами отчитывается о рантайм-метриках и помещает эти отчеты в базу данных, что помогает делать выводы об использовании, нагрузке и производительности BPM-платформы. При каждом назначении задачи соответствующий назначенный сотрудник сохраняется как псевдонимизированное значение с фиксированной длиной в таблице ACT_RU_TASK_METER_LOG вместе с временной меткой. Очистка для этих данных должна быть сконфигурирована в явном виде, если она нужна.

Свойство taskMetricsTimeToLive можно использовать для определения TTL для вхождений метрик задачи, производимых назначениями пользовательских задач на исполнителей. Это свойство принимает значения в формате даты ISO-8601. Отметим, что разрешена только нотация, задающая количество дней.

<property name="taskMetricsTimeToLive">P540D</property>

ВНИМАНИЕ!: Если вы клиент уровня enterprise, выше лицензионное соглашение может потребовать, чтобы вы ежегодно отчитывались об определенных метриках. Пожалуйста, сохраняйте метрики из таблицы ACT_RU_TASK_METER_LOG как минимум 18 месяцев, пока не отправите по ним отчет.

Окно очистки

Чтобы очистка истории проводилась автоматически на регулярной основе, необходимо сконфиоурировать окно batch на период времени в течение дня, во время которого должна производиться очистка.

Используйте приведенные ниже конфигурационные свойства, чтобы задать окно batch для каждого дня недели:

<property name="historyCleanupBatchWindowStartTime">20:00</property>
<property name="historyCleanupBatchWindowEndTime">06:00</property>

Очистка также может иметь индивидуальное расписание для каждого дня недели (например, запускаем очистку только на выходных):

<!-- default for all weekdays -->
<property name="historyCleanupBatchWindowStartTime">20:00</property>
<property name="historyCleanupBatchWindowEndTime">06:00</property>

<!-- overriding batch window for saturday and sunday -->
<property name="saturdayHistoryCleanupBatchWindowStartTime">06:00</property>
<property name="saturdayHistoryCleanupBatchWindowEndTime">06:00</property>
<property name="sundayHistoryCleanupBatchWindowStartTime">06:00</property>
<property name="sundayHistoryCleanupBatchWindowEndTime">06:00</property>

По умолчанию окно очистки не конфигурируется. В этом случае очистка истории автоматически не производится.

См. [engine configuration reference][configuration-options], чтобы найти полный список параментов.

Стратегия очистки

Чтобы выбрать стратегию очистки (removal-time-based или end-time-based), можно сделать следующее:

<property name="historyCleanupStrategy">removalTimeBased</property>

Валидные значения свойства: removalTimeBased и endTimeBased, при этом removalTimeBased является значением по умолчанию.

Стратегия removal-time-based

Время удаления для экземпляра рассчитывается по формуле removal time = base time + TTL, где base time (базовое время) может быт либо временем старта, либо времене окончания работы экземпляра для случая экземпляров процесса. Это можно сконфигурировать в движке управления процессами следующим образом:

<property name="historyRemovalTimeStrategy">end</property>

Валидными значениями являются значения start, end и none, при этом end является значением по умолчанию и рекомендованной опцией. Значение start немного более эффективно в том случае, когда движок управления проуессами наполняет данными таблицы истории, потому что тогда еум не придется выполнять дополнительные UPDATE-запросы, когда экземпляр закончит работу.

Примечание: если historyRemovalTimeStrategy установлено в start, появляется возможность удалять исторические данные активных экземпляров процессов. Когда процесс уже запущен, вычисляется время удаления (start+TTL), и оно будет установлено для всех активностей процесса. Как только время удаления наступило, данные из исторических таблиц будут удалены независимо от того, работает ли еще экземпляр процесса или закончился. Это может привести к удалению исторических данных еще до того, как экземпляр процесса закончит работу, в результате чего история будет недоступна как в Cockpit, так и в таблицах истории. Исправить эту ситуацию можно, выбрав большее значение для TTL или установив historyRemovalTimeStrategy в end.

ВНИМАНИЕ!: Вычисление времени удаления можно разрешить независимо от выбранной стратегии очистки в движке управления процессами. Это позволяет нам производить процедуру очистки за пределами движка через использование возможностей базы данных (например, через партиционирование таблиц по времени удаления).

Параллельное выполнение

Уровень параллельного выполнения для очистки истории может быть задан в конфигурации движка следующим образом:

<property name="historyCleanupDegreeOfParallelism">4</property>

Валидными значениями являются целые числа от 1 до 8. 1 является значением по умолчанию.

Это свойство задает число джоб, используемых для очистки истории. Соответственно, это значение определяет, сколько потоков job executor и сколько соединений с базой данных могут быть одновременно заняты под очистку истории. Выбор более высокого значения позволяет сделать очистку быстрее, но крадет ресурсы у других задач, которые движок и база данных тоже должны выполнять.

Объем удаляемых данных

Количество экземпляров, удаляемое в одной транзакции очистки, может быть установлено следующим образом:

<property name="historyCleanupBatchSize">100</property>

Значение по умолчанию (оно же максимально) равно 500. Если вы заметите таймауты в транзакциях во время очистки истории, можете уменьшить его.

Кластеризованная очистка

При наличии конфигурации кластера с многочисленными движками вы можете сконфигурировать, должен ли конкретный движок участвовать в очистке или нет. Убедитесь в том, что одна и та же конфигурация выполнения (окно, объем удаляемых данных, степень параллельности) присутствует на всех участвующих узлах.

Участие в выполнении очистки по узлам

Иногда необходимо исключить некоторые узлы конфигурации с несколькими движками из числа исполнителей очистки истории, например, чтобы снизить нагрузку на некоторые узлы.

Вы можете отключить очистку истории на каждом узле, используя следующий флаг:

<property name="historyCleanupEnabled">false</property>

Когда вы исключаете узел из выполнения очистки истории, вам не требуется задавать конфигурационные свойства, относящиеся к выполнению очистки, поскольку данный узел будет их игнорировать.

Примечание: Конфигурационные свойства очистки истории, которые не относятся к выполнению очистки, (например, время жизни, стратегия вычисления времени очистки) все еще должны задаваться на всех узлах.

configuration-options

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

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

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