How it Works

Loupe analyzes all of the log data it receives and categorizes each warning, error, or critical log message into Log Events.  These events are compared between all of the sessions that have been received to identify the unique Application Events.  Depending the rules defined on the server or manual actions you take these Application Events can be used to create Issues. 

This multi-tier aggregation method means that vast amounts of log data can be summarized into the smallest number of distinct items to be reviewed. 

• Log Event - All of the messages in a single session that have the same severity, category, class, and caption.  These are presumed to identify a common problem to be reviewed.
• Application Event - A common Log Event across multiple sessions. This identifies the same problem regardless of the individual application session.  Since this is constrained to the same product & application a Log Event that has the same severity, category, class, and caption that happens in two different applications will be considered unique Application Events.
• Issues - One or more Application Events can be used to open an Issue.  An Issue represents a recognized problem that needs to be researched, managed, and resolved.  Once it's been resolved if it reoccurs in a later version it'll be automatically reopened.

Lifecycle of an Issue

Once an Issue has been opened it's considered either New (if it was opened by a Rule) or Active (if it was opened by a person).  New issues are on their own list so it's easy to review the issues that are being created automatically and suppress ones that shouldn't have been created. 

An Open issue can be commented on, assigned to a person for them to work on, have additional related Application Events added to it, and ultimately be either Resolved or Suppressed.

• Resolving an Issue - When the underlying application has been changed to addressed the problem the Issue can be resolved, recording the application version where the fix was incorporated. 
• Suppressing an Issue - If an issue is determined to not be a software problem it can be Suppressed.  This removes it from the Issue metrics and prevents it from being reopened by future occurrences. 
• Deleting an Issue -  If an issue was opened by accident it can be Deleted.  This removes if permanently and frees the Event to be added to another issue or re-triaged.

Issues Vs. Alerts

Loupe Resolve is designed to perform automatic issue management for development teams as opposed to providing Alerts for operations teams (which is done by Loupe Monitor).  The key distinction is the workflow - An Event and ultimately an Issue is expected to be resolved by making a software change in a new version of the application. 

By contrast, an Alert could be resolved and a new Alert open from the same underlying error message without requiring a new software version.  For example, a server losing network connectivity would cause errors that should raise an alert and once the network is restored the alert can be marked resolved.  If connectivity is lost again a new Alert should open.  No software changes were required to address the alert and therefore there isn't a new version of the application.

For operational monitoring, use Loupe Monitor.