Hi folks
I wonder how the Stack Trace in atlassian-confluence.log can be reduced. We currently have up to 300 lines of stack trace per issue, for me as system admin only the first three are relevant.
I have placed this question to the Confluence community (see here), they suggested to place the question here.
From my understanding, I could make use of the parameter throwable{n} in log4j.properties.
Unfortunately, I was not able to get this working as expected. From my understanding, %throwable{n} is falsely getting interpreted as %t, which refers to the causing Thread.
Step by step:
in log4j.properties I have enriched all the lines with ConversionPattern with %throwable{3}. So e.g.
log4j.appender.confluencelog.layout.ConversionPattern=%d %p [%c{4}] %M %m%n %throwable{3}
The stack trace is still shown at full extend.
I realized that the log is showing localhost-startStop-1hrowable{3} which leads to my assumption that it is getting interpreted as %t + plain String hrowable{3}
I have tried the following variants, but all none with the expected result:
- surrounded with square brackets [%throwable{3}] (in order to make this a “single” statement)
- removed %t (in order to avoid conflict)
- put to the beginning of the ConversionPattern (before %d, in order to have this parsed first)
- instead of %throwable{3} use %throwable{short} (any other documented option instead of number)
- same for %throwable{none} (reason why see below)
From the official documentation, this option %throwable{n} is supported since log4j 1.2.16. I have verified that our Confluence installation has log4j-1.2.17.jar, which is also the latest release of log4j 1.x
Interestingly, I found a discussion in the Jira Community dealing with Jira logs and Syslog-Server. (see here.
The explanations there contain the usage of %throwable{none}.
So the usage of this parameter within the Atlassian universe seems to be common.
I have tried using %throwable{none}, but same result…
Thanks.
Regards, Ben