Unfortunately so. That pattern matches the hundreds of lines produced after the first line, see the "Message with no timestamp" lines in the example log below:

Log file open, 04/05/24 16:14:04
Logger: Message with no timestamp 1
Logger: Message with no timestamp 2
Logger: Message with no timestamp 3
Logger: Hundreds of these messages with no timestamp
[2024.04.05-16.14.05:545][123]Logger: Message with timestamp 1
[2024.04.05-16.14.05:546][123]Logger: Message with timestamp 2
[2024.04.05-16.14.05:547][123]Logger: Message with timestamp 3
[2024.04.05-16.14.05:548][123]Logger: An error has occurred!
--- CALLSTACK ---=[C](-1) : ?
@C:/Path/To/Source/Files/sourceA.py(123) : functionA
@C:/Path/To/Source/Files/sourceB.py(456) : functionB
@C:/Path/To/Source/Files/sourceC.py(789) : functionC
--- CALLSTACK ---
[2024.04.05-16.14.05:549][123]Logger: Message with timestamp 4
[2024.04.05-16.14.05:550][123]Logger: Message with timestamp 5

I think I've now managed to get this working, with the following parser mapping:

[%d{yyyy.MM.dd}-%d{%H.mm.ss:fff}][%t]%c: %m%n
[%d{yyyy.MM.dd}-%d{%H.mm.ss:fff}][%t]%c: %m--- CALLSTACK ---%n
%c: %m%n
%m, %d{dd/MM/yy %H:mm:ss}%n

The additional --- CALLSTACK --- line seems to match these errors. Can you think of a reason why this wouldn't work and/or a better solution?

Please see our definition of a log entry.

Consider the log line:

[2024.04.05-16.14.05:548][123]Logger: An error has occurred!
--- CALLSTACK ---=[C](-1) : ?
@C:/Path/To/Source/Files/sourceA.py(123) : functionA
@C:/Path/To/Source/Files/sourceB.py(456) : functionB
@C:/Path/To/Source/Files/sourceC.py(789) : functionC
--- CALLSTACK ---

Is that one long entry - or four or six?  According to our definition, it is one log entry because there is only one timestamp.

The parser configuration:

%c: %m%n

Does not meet our definition of a log entry because it does not define a timestamp.  This is actually a bug which I believe is specific to multi-patterns (which are an advanced feature).  We will probably need to fix this in a future release.  In fact, this thread is leading me to think it should be fixed with a higher priority because we don't test for this scenario and you are likely to have additional issues with this configuration in future (which we will not be able to support).

I would suggest using the parser configuration:

[%d{yyyy.MM.dd-HH.mm.ss:fff}][%t]%c: %m%n
%m, %d{dd/MM/yy %H:mm:ss}%n

Using this configuration, the file above contains 7 log entries.  The two 'advanced' entries will be parsed across multiple lines:


If it is necessary to break the header up across multiple lines and you are not able to change your application, you may also want to consider a custom parser which will give you an opportunity to set a timestamp even if one does not exist in the log entry.

Hope that helps,

Toby