By scottyjay - 29 May 2024
Apologies if this has been asked previously, my search doesn't yield results for this,
I have multiple applications that log to application.log or some derivation. By necessity they have different variables in their output format (not vastly different, but different).
As there is no difference in the filename (the path does differ) the parser mapping must be selected everytime.
Well being able to select the parser would be a boon, instead I'm prompted with a new default parsing wizard dialog when I open the subsequent differing application.log file. I've played around with ordering, but this doesn't seem to yield a result.
I.e. two different applications log to
/var/logs/application_logs/[application-name]/application-2024-05-29.log
My parser mappings can only be application-*.log, but if I open one application's logs after setting up for another that differs in format, LogViewPlus fails to use the "best" previously configured parser.
A workaround is probably to open a file WITH a specific filter, but that means hard-coding I believe, and a level of verbosity I don't care for.
Am I missing something?
|
By LogViewPlus Support - 29 May 2024
Ideally, LogViewPlus wants to be able to identify a file parser based on the log file name. Sometimes this is not possible and in this case, you have two options.
1. Manually select a target parser when opening the log file. When using this option, it helps if your parser configurations have a descriptive name.
2. Alternatively, LogViewPlus can parse a log file with all matching parsers and select the best match heuristically. Given your description, I think this is the option you are looking for.
Hope that helps,
Toby
|
By scottyjay - 30 May 2024
Thanks Toby,
That did help by slowing me down and pointing me in the right direction. Will post my "Solution" a little later
I think I could have got there a lot sooner if the "Save Configuration" dialog was changed a little.
https://www.logviewplus.com/docs/automatic_configuration.html
If I could suggest:-
- Adding or using pattern name rather than file pattern.
- Using the term "Delete selected parser configuration" for the third icon mouseover, which I believe is what it does, which is an odd location to have this functionality
- Allow verbose selection of parser here. This functionality is missing, and here's one great location to have it. The other would be in log-file properties
- Also, but less importantly. I think adding the warning mouseover text to a body element in the dialog, would be more useful than hiding it in a mouseover.
Most configuration formats I have, use the same pattern. Having it in the "Configuration" column of this dialog doesn't really help me terribly. I assume it's helpful for others?
|
By scottyjay - 30 May 2024
N.B. I use monitor folder and don't specify a specific parser for each file.
Every time I open an application log I was constantly getting the conflict dialog. I'd edit it, and then would happen again next time.
I didn't realize I'd deleted my previous secondary application.log parser and mapping.
I wasn't entirely aware I was constantly editing the same parser config over and over again.
However even after recreating it, the problem remained.
I confirmed I was using heuristic parser selection.
Solution:
I paid a lot more attention to the patterns I was using, and how the test-files work with each. Tweaking the auto-detected format, converting "S" to "s", and removing length limits on "%m".
I collated several samples and, then tested each parser's pattern until they were robust.
Previously I would always get the same "broadest" parser used in the conflict dialog, which made it difficult to identify the issue with the parser I wished to use.
After ensuring the parsers did not error, heuristic selection is now using the correct parser, despite the multiple possible options.
FTW!
|
By LogViewPlus Support - 30 May 2024
Thanks for the feedback.
The Automatic Configuration dialog is not really designed to handle the scenario where multiple log files have the same name with a different parser configuration. Instead, it directs to the user to fix an existing configuration rather than:
1. Create a new parser.
2. Use a different parser.
3. Switch to heuristics matching.
I can see where this is could be causing confusion for new users.
Your suggestions above are very helpful. Let me experiement a bit with this scenario and see what I can come up with. I think it is possible that a new dialog is needed.
Thanks for highlighting this issue!
Toby
|
|