You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see that chainsaw will stop parsing the thread name at the first right parenthesis, and consider the rest as next token. I think it should consider the levels and save them in a stack, sth like:
push the left parenthesis into a stack
whenever it sees a right parenthesis, pops out a left paring one
if stack is not empty, continue parsing this token.
Now the workaround is to change the log format to be like -{%t}-, and configure chainsaw to be the same. That is fine at dev time, but will not solve production issue when the format is fixed.
The text was updated successfully, but these errors were encountered:
Do you need to parse text lines? The version of chainsaw in master(likely somewhat unstable) does have some initial support for JSON based log messages, which would bypass this problem.
No, this is not a JSON log, but text lines. I could change Quarkus to output JSON format, but I would rather not; and I need to analyze other applications' logs which are not Quarkus based and they only have text line logs(cannot use JSON).
I think even for plain text logs, this should be checked. But I agree that things would become complicated as you may need to do this stack pop/push whenever you see a parenthesis/bracket/curly bracket in the pattern, in each field.
I have logs lines with
(%t)
like:or
I see that chainsaw will stop parsing the thread name at the first right parenthesis, and consider the rest as next token. I think it should consider the levels and save them in a stack, sth like:
Now the workaround is to change the log format to be like
-{%t}-
, and configure chainsaw to be the same. That is fine at dev time, but will not solve production issue when the format is fixed.The text was updated successfully, but these errors were encountered: