top of page

Configuração de Limpeza de Histórico (History TTL) no Camunda com Spring Boot

O histórico no Camunda pode sobrecarregar seu banco de dados, e se faz necessário manter um controle para que sua aplicação não fique lenta e possamos manter uma boa performance, vamos entender neste post como configurar o agendamento da limpeza automática de histórico (history cleanup).


Imagem contendo o titulo do post.

Muitas vezes precisamos manter o histórico de nossos processos salvos em um banco de dados para fins de auditoria, ou para possíveis problemas futuros,

A limpeza de histórico no Camunda é uma parte crucial da manutenção do desempenho e da eficiência do sistema. No Camunda, a limpeza de histórico pode ser configurada para garantir que os dados antigos sejam removidos automaticamente, ajudando a evitar o crescimento excessivo do banco de dados. Neste post, vamos explorar como configurar a limpeza de histórico em uma aplicação Camunda com Spring Boot, usando exemplos de configuração com application.yaml e application.properties.


O Que É Limpeza de Histórico?


No Camunda, o histórico é usado para registrar todas as informações sobre a execução de processos e tarefas. Com o tempo, essas informações podem acumular e impactar o desempenho de sua aplicação, pois são as tabelas de histórico e métricas são as que mais crescem no banco de dados do Camunda. A limpeza de histórico é o processo de remover registros históricos antigos e não mais necessários para liberar espaço e melhorar a eficiência. A limpeza de histórico no Camunda é baseada nas colunas REMOVAL_TIME_ contidas em todas as tabelas de histórico. O cálculo para obter a data para este REMOVAL_TIME_ depende das propriedades historyTimeToLive, historyCleanupStrategy e do historyRemovalTimeStrategy.


Se quiser saber mais como funciona o cálculo do tempo para remoção (TTL - Time to live), acesse o post do link abaixo que explica de forma completa:



Todas as tabelas de histórico possuem em sua nomenclatura as letras "HI" de "History", exemplos: ACT_HI_ACTINST, ACT_HI_PROCINST, ACT_HI_BATCH, entre outras, e cada uma destas tabelas armazena detalhes úteis para o monitoramento do que ocorreu com suas instâncias. Os níveis de informações salvas nestas tabelas também podem ser configurados, mas por default o nível de infos salvas é o mais completo (FULL).


Configurando a limpeza de histórico em seu Camunda com Spring


Para configurar a limpeza de histórico em um Camunda com Spring Boot, você pode usar tanto o arquivo application.yaml quanto o application.properties. Vamos ver como configurar cada um à seguir:


Utilizando o application.yaml:

O caminho para o arquivo application.yml deve ser o src/main/resources/application.yaml.

Através das "generic-properties" podemos definir ou sobrescrever as propriedades genéricas para nossa aplicação Camunda conforme exemplo abaixo:

Imagem com exemplo de configurações para limpeza de hitórico no Camunda usando application.yaml

Utilizando o application.properties:


O caminho para o arquivo application.properties deve ser o:


src/main/resources/application.properties.


No application.properties as configurações são as mesmas, porém a forma de declaração muda um pouco, conforme veremos logo abaixo no exemplo mostrando exatamente as mesmas configurações utilizadas no application.yaml.


Imagem com exemplo de configurações para limpeza de hitórico no Camunda usando application.properties


Lembre-se que não devemos declarar as propriedades em ambos arquivos ao mesmo tempo, mesmo que sejam propriedades com valores diferentes, pois entrarão em conflito já que o Spring não conseguirá identificar de qual arquivo necessita ler as propriedades. Então escolha um arquivo apenas, e defina as propriedades nele.


Entendendo o que cada uma destas propriedades significam:


historyTimeToLive: Tempo que o histórico ficará armazenado no banco de dados a partir da data definida como data de remoção na coluna REMOVAL_TIME_, esta data será definida de acordo com o CleanupStrategy e com o RemovalTimeStrategy utilizados.


batchOperationHistoryTimeToLive: O Camunda possui em seu mecanismo a possibilidade de operações em lotes (batchs), que servem para não sobrecarregar sua aplicação ao executar determinados serviços. Imagine que você possua 10.000 instancias para fazer Migration de um fluxo antigo para um novo, não queremos fazer as 10.000 migrações de uma vez só pois isso sobrecarregaria nossa aplicação. Outros serviços também podem ser executados desta mesma forma, então usamos a API de batch para criar um lote e executar este lote em partes menores, sendo assim temos algumas tabelas exclusivas para armazenar estas operações e esta propriedade define quanto tempo o histórico de operações em lote serão mantidos no banco.


historyCleanupStrategy: Define a estratégia de remoção do histórico, que pode ser removalTimeBased (o calculo de remoção é o tempo descrito na coluna REMOVAL_TIME_ do banco + o tempo definido na configuração de TimeToLive), ou endTimeBased (baseado no tempo descrito na coluna END_TIME_ do banco + o tempo definido na configuração de TimeToLive).


historyRemovalTimeStrategy: Esta propriedade é aplicável apenas para a estratégia de RemovalTimeBased, pode ser do tipo start, end e none. O start calcula o tempo de remoção a partir da data de criação da instancia ou serviço, isto permite que o mecanismo exclua histórico de instancias ainda em execução, o que às vezes pode não ser o comportamento desejado. O end calcula à partir da data que a instancia ou serviço são finalizados, e a partir deste cálculo define um valor na coluna REMOVAL_TIME_, que é onde o mecanismo do Camunda verifica a data em que aquela linha de histórico pode ser removida.


historyCleanupDegreeOfParallelism: Esta propriedade controla quantos threads ou processos paralelos serão usados para realizar a limpeza do histórico.


historyCleanupBatchSize: Define o número de registros que serão processados em cada execução de limpeza em lote. Serve basicamente para otimizar a performance do sistema durante a limpeza de histórico, ajustando a quantidade de dados processados de uma só vez.


batchJobsPerSeed: Configura quantos jobs serão gerados por "seed", que é uma unidade de trabalho que inicializa outros jobs ajudando a balancear a carga de trabalho da aplicação, distribuindo as tarefas de limpeza em várias partes menores.


invocationsPerBatchJob: Especifica o número de invocações ou operações que cada job de lote deve realizar, controlando a granularidade dos jobs em lote, permitindo um ajuste fino na execução dessas operações para evitar sobrecarga.


historyCleanupBatchWindowStartTime: Define um horário diário para iniciar o trabalho de limpeza de histórico, todo dia iniciará a limpeza na hora definida.


historyCleanupBatchWindowEndTime: Define um horário diário para parar o trabalho de limpeza de histórico, todo dia irá parar a limpeza na hora definida.


saturdayHistoryCleanupBatchWindowStartTime: Quando queremos definir um horário para inicio da limpeza de historico exclusivo para um determinado dia da semana. Exemplo: Definimos que as limpezas de historico iniciam todos dias às "22:00", mas aos sábados queremos iniciar às "00:00". (para escolher outro dia da semana, basta mudar a primeira palavra da propriedade para o dia da semana correspondente em inglês). Esta propriedade sobrescreve o horário da propriedade historyCleanupBatchWindowStartTime para esta data específica.


saturdayHistoryCleanupBatchWindowEndTime: Quando queremos definir um horário para parar a limpeza de historico exclusivamente em um determinado dia da semana. Exemplo: Definimos que as limpezas de historico finalizam todos dias às "06:00", mas aos sábados queremos finalizar às "23:59". (para escolher outro dia da semana, basta mudar a primeira palavra da propriedade para o dia da semana correspondente em inglês). Esta propriedade sobrescreve o horário da propriedade historyCleanupBatchWindowEndTime para esta data específica.


Antes de implementar o History Cleanup, eu já tinha histórico em meu banco de dados, e a coluna REMOVAL_TIME_ não está preenchida, e agora?


Se seu histórico estava ativo e você ainda não tinha um history cleanup definido, é provável que em suas tabelas de histórico a coluna REMOVAL_TIME_ não esteja com data de remoção definida, e com isto a sua limpeza automática não funcionará.


Se este é o seu caso, acesse o post abaixo e entenda o que pode ser feito para resolver este problema e executar sua limpeza automáticamente:




Quer conhecer um pouco mais sobre esta ferramenta e outras tecnologias?

Nos siga nas redes sociais @gerandocodigo (instagram / youtube / tiktok / facebook).




Comments


bottom of page