Unable to change Log levels in Jira
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
When changing the log levels in Logging and profiling, the changes don't take effect or revert back to the previous values when the page is reloaded or after a while.
Environment
All versions of Jira Core 7.x and 8.x.
Diagnosis
It consists of two steps: trying to revert to the log4j.properties file and confirming the log changes is indeed being received by Jira (Data Center only).
In Jira Data Center, change anything on the Logging and profiling page takes effect on all nodes in the cluster (link explains further).
When a node is restarted, it's logging definitions revert back to it's own log4j.properties file.
1) Trying to revert to the Log4j or Log4j 2 configuration file
When Jira's restarted, it should load the log packages and log levels from the log4j.properties file (if you're using Jira 9.4 or older) or the log4j2.xml file (if you're using Jira 9.5 or newer). Both files are located in the <jira-install-dir>/atlassian-jira/WEB-INF/classes/ directory.
If after restart, there are more packages listed in Logging and profiling than in the Log4j or Log4j2 configuration file — or the log levels don't match — there may be something overwriting the log configs.
2) Confirm the log change was acknowledged
After changing something in Logging and profiling, execute the below command on Jira's database to confirm the log change was acknowledged:
1
2
3
4
5
6
SELECT * FROM CLUSTERMESSAGE WHERE UPPER(MESSAGE) LIKE 'LOG LEVEL:%' ORDER BY MESSAGE_TIME DESC;
id | source_node | destination_node | claimed_by_node | message | message_time
-------+-------------+------------------+-----------------+--------------------------------------------------------------------------+----------------------------
10101 | node1 | ALL | | Log Level:-com.atlassian.jira.web.filters.accesslog.AccessLogFilter-INFO | 2021-05-24 20:40:49.265-03
10100 | node1 | ALL | | Log Level:-a.b.c.d-WARN | 2021-05-24 20:24:14.646-03
10003 | node1 | ALL | | Log Level:-webwork.util.ServletValueStack-ERROR | 2021-05-24 20:23:30.555-03Check if the message_time matches the time you performed the change. If there are entries in this table yet the logs changes don't stick or revert back after a while, that's one more evidence something's overwriting them.
Cause
The most likely cause is a custom script somewhere actively adding logging packages or changing log levels.
Script Runner's an example of that, and it's Advanced Logging documentation exemplifies how it's accomplished.
Other script featuring apps should provide similar functionality.
Solution
You should manually review each script (in scheduled executions and in workflows) that contain such "logger" or "setlevel" directives. This may be peculiar to the scripting app you've installed (Groovy, Jython, custom language, etc).
Was this helpful?