Can I change the history level on an existing Camunda 7.6.2/WildFly 10.1.0 installation from “full” to “audit” on an existing installation. I have done this experimentally in a lab by changing the value from “full” to “audit” in WildFly’s standalone.xml and then setting the historyLevel value to “2” in the ACT_GE_PROPERTY table. All this was done with WildFly stopped, so nothing was moving through the system.
I need an “official” ruling here, though there are suggestions as to what the answer might be (no). Are there conditions under which it might be acceptable such as waiting until all processes had finished?
Thanks.
Michael
Hi Michael,
you already found the recommended way: stop the process engine, update config + database.
If you don’t want to stop the process engine, it’s hard to ensure that no history for process instance etc. is written. You would have to disable the job executor, suspend the process instances etc. and somehow change the config (e.g., standalone.xml).
Best regards,
Philipp
hi, Philipp but the document said
Note that when using the default history backend, the history level is stored in the database and cannot be changed later.
document is conflict to what you recommended.
Is the issue with the documentation?
Hi @zhangchao,
the documentation is correct. It is not recommended to change the history level afterward. But if you need to then you can do it as described.
Best regards,
Philipp
1 Like
I think there would be a lot of camunda user who deploy the service with default log level, after a period running, log level full may consume database storage a lot. then people want to change the log level. If the feature is not very difficult to implement and could help a lot of user, why don’t we made the modification of log level a officially supported feature?
as a normal user of camunda, above content is just my personal idea.
by the way, not recommended is different from cannot. the document should change to
the history level is stored in the database, you can change it by update the database record, but it’s not recommended.
2 Likes
Hi @zhangchao,
technically you have to update the historyLevel entry in the ACT_GE_PROPERTY table and change the value in the configuration file.
The engine will check both values if they fit together during startup. If they didn’t fit, the engine won’t start.
Hope this helps, Ingo
You are correct. We had to turn it off because it was so resource intensive for our applications. You could choose lower levels of detail from the beginning, but that didn’t give us what we needed. We wrote our own history service.
Phillip’s recommendation to not change it is based, in my opinion, on the fact that Camunda captures “state” after each activity. These states become history and if you were to change how those were recorded, there is the potential for confusion as to what history can tell you before and after the change.
Camunda is very much a database driven application, which is why it is so robust and rarely fails to complete properly developed processes. As such, the less that we alter the function and structure of the data it creates and consumes, the more reliable it becomes.
What I would like to see is a feature to completely offload the history database to an external database. I would not offload any of the runtime time data, only the data stored after a process is complete.
Michael
Hi @mppfor_manu,
times has changed since your tries and the (Camunda) world improves. Today you can use the history Cleanup of the engine: https://docs.camunda.org/manual/7.10/user-guide/process-engine/history/#history-cleanup and import the data into Camunda Optimize beforehand: https://docs.camunda.org/optimize/2.3/.
As Optimize is based on ElasticSearch it should be infinite scalable.
Cheers, Ingo
How can we update this property using liquibase scripts?