﻿<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>LogViewPlus Support » LogViewPlus Support » Features &amp; Suggestions  » Automatic error indicator per parser</title><generator>InstantForum 2017-1 Final</generator><description>LogViewPlus Support</description><link>https://www.logviewplus.com/forum/</link><webMaster>LogViewPlus Support</webMaster><lastBuildDate>Mon, 22 Jun 2026 19:27:45 GMT</lastBuildDate><ttl>20</ttl><item><title>Automatic error indicator per parser</title><link>https://www.logviewplus.com/forum/post/566</link><description>Hi LogViewPlus,&lt;br/&gt;&lt;br/&gt;this is an idea for a new detection.&lt;br/&gt;We get multiple logfiles which we have to investigate. When opening a logfile then I can use templates to search for potential issues.&lt;br/&gt;If this could be automated that would be a great advantage.&lt;br/&gt;&lt;br/&gt;My idea would be to store specific patterns inside LogViewPlus per parser. If such a pattern fits then show a message to the analyst so he can confirm if this is an issue or false positive.&lt;br/&gt;&lt;br/&gt;&lt;strong&gt;Example 1:&lt;/strong&gt;&lt;br/&gt;In one of our logs a synchronization start and a synchronization stop is visible. Depending on the time such a synchronization takes this could be a problem or not. We could define to throw a message in case that the synchronization takes more than 3 minutes. Then it would popup for the analysist and he can decide if this is a problem or not. The option "Calculate Elapsed" already exists in LogViewPlus and could be used for this case.&lt;br/&gt;&lt;br/&gt;&lt;strong&gt;Example 2:&lt;/strong&gt;&lt;br/&gt;Using the same example from "Example 1" that we check for a synchronization time. These synchronization attemps will be executed all 15 minutes in an interval. Normally the log would look as follows:&lt;br/&gt; - Sync start&lt;br/&gt; - Sync stop&lt;br/&gt; - Sync start&lt;br/&gt; - Sync stop&lt;br/&gt;In case that a synchronization takes more than 15 minutes the log would look as follows. The stop message is missing.&lt;br/&gt; - Sync start&lt;br/&gt; - Sync start&lt;br/&gt;In many logs a message is thrown when a process started and when a process stopped. If we can catch when a process was never stopped that would be great&lt;br/&gt;&lt;br/&gt;&lt;strong&gt;Example 3:&lt;/strong&gt;&lt;br/&gt;Throwing a message in case a specific log order is not as expected.&lt;br/&gt;Let's use an example for a login process on a computer and imagine that for each process a logentry will be written:&lt;br/&gt; - computer starts&lt;br/&gt; - login screen shown&lt;br/&gt; - credentials entered and sent by the user&lt;br/&gt; - local accounts will be checked and user will be logged in if available&lt;br/&gt; - domain accounts will be checked and user will be logged in if available&lt;br/&gt; - login fails&lt;br/&gt;For this example it could be that the login fails but the domain accounts were never be checked (maybe a network issue) so then the "login fails" message appears but one message was skipped. This could appear as a warning and gives the analyst a fast help to investigate.&lt;br/&gt;Please note that depending on the system there can be a lot of processes running in parallel so it must also be possible to check the process order based on a column. Within such a column there could be a Generic ID or username given which was available in the log.&lt;br/&gt;&lt;br/&gt;&lt;strong&gt;Example 4:&lt;/strong&gt;&lt;br/&gt;Some errors appear seldom but if they appear they do have a specific pattern.&lt;br/&gt;This pattern could be a single error message or a row of error messages. If such pattern is matched then a message to the analyst should be thrown.&lt;br/&gt;&lt;br/&gt;I can imagine that there are many many more examples but hopefully my idea makes sense. :-)&lt;br/&gt;The error indicators should only be available per parser as otherwise there will be a lot of checks on logfiles where this makes no sense. This just increases CPU usage even when not needed.&lt;br/&gt;&lt;br/&gt;It would also be great if per such indicator 2 more information can be given:&lt;br/&gt; - urgency: defines how serious such error can be as a help for the analyst who maybe never experienced this before&lt;br/&gt; - information field: this information field can either contain a link to a bug report or knowledgebase article or contain a small description which does help the analyst for investigation&lt;br/&gt;&lt;br/&gt;Best regards,&lt;br/&gt;Matthias</description><pubDate>Wed, 10 Jun 2020 09:38:21 GMT</pubDate><dc:creator>MatthiasB</dc:creator></item><item><title>RE: Automatic error indicator per parser</title><link>https://www.logviewplus.com/forum/post/575</link><description>Hi Matthias,&lt;br/&gt;&lt;br/&gt;Thanks for the feedback!&lt;br/&gt;&lt;br/&gt;I think this is a good vision and I would love for LogViewPlus to be able to do these things more easily.&amp;nbsp; However, I really do not want to increase application complexity.&amp;nbsp; It is very important for new users to be able to quickly understand the application.&amp;nbsp; I think applications can become complicated unintentionally when big features are added too fast.&lt;br/&gt;&lt;br/&gt;One feature on our backlog is "Triggers".&amp;nbsp; Actions that take place when something happens or is detected in a log file.&amp;nbsp; For example, "Apply a template if you see this log line".&amp;nbsp; Triggers have a wide appeal and are easy to understand.&amp;nbsp; I think they would be a good stepping stone toward the vision you have outlined above.&amp;nbsp; My preference would be to revisit some of these use cases once that feature is complete.&lt;br/&gt;&lt;br/&gt;Part of the power of LogViewPlus comes from the composition of simple ideas.&amp;nbsp; I would like to move toward the vision above, but I think it needs to be done with simple building blocks - and this will take time.&lt;br/&gt;&lt;br/&gt;Hope that helps,&lt;br/&gt;&lt;br/&gt;Toby</description><pubDate>Wed, 10 Jun 2020 09:38:21 GMT</pubDate><dc:creator>LogViewPlus Support</dc:creator></item></channel></rss>