Unable to change Log levels in Jira

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問


プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。

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.

*Fisheye および Crucible は除く

    

要約

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.


環境

Jira Core 7.x と 8.x のすべてのバージョン


診断

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:

SELECT * FROM CLUSTERMESSAGE WHERE 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-03

Check 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.


原因

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.


ソリューション

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).


最終更新日: 2022 年 12 月 7 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.