About This File
This is the "Internal Monitor For Automatic Resets on Ticket Status" (IMFARTS)
The tickets themselves aren't sticky, this is a solution for designating specific monitors so that if the ticket is closed without the monitor healing, the alert will be reset and a new ticket will be created. This is specifically for the scenario that exists for Internal Monitors that are configured to "Send Fail After Success". These monitors are useful because they do not continuously generate tickets or ticket comments. But issues can be lost if the ticket is closed without the monitor actually healing. If a monitor alert must be ignored, the agent should be excluded from the monitor instead of just closing the ticket. I am not saying that this should apply to every monitor (sometimes you may accept just closing the ticket). But if you have a monitor that you want to insure is not ignored, this monitor this can help.
The monitor works by searching for open alerts and tickets that have been generated by the all monitors. Any alerts found where the ticket has been closed but the alert is still active will be returned as a result. You do not want to alert (create a ticket or other action) on the result of this monitor. The results are only there to show you what alerts are currently not being watched because there is an active alert with no active ticket. Based on this, you can decide which monitors you want to enforce.
For monitors that you have chosen to enforce, if they are found to have no active ticket the previous alert will be cleared, allowing the monitor to generate a new alert (and ticket) the next time that monitor is processed. This monitor determines which monitors are being watched by a keyword in the other monitor's definition.
To enforce a monitor (so that it's tickets will be re-opened), you need to include the string "ENABLEIMFARTS" in the Additional Condition field. A simple way to do this is to add " AND 'ENABLEIMFARTS'<>'IGNORED' " to the Additional Condition field. This will always evaluate to TRUE, so it will not change the existing monitor's logic. You could also use computers.name NOT LIKE 'ENABLEIMFARTS', etc.. As long as the string is in the Additional Conditions, the monitor will be watched. It can easily be incorporated for regular or RAWSQL monitors.
An example: A Drive Monitor is reporting that under 2GB of free space exists for the "C" drive on AgentX. A ticket is created, and the monitor is configured for "Send Fail After Success". A technician accidentally closes the ticket. This Monitor detects that there is an active alert for AgentX on the "C" drive, but all tickets from that alert have been closed. If the string 'ENABLEIMFARTS' is found in that monitor, the current alert for AgentX "C" drive will be cleared. When the Drive Monitor processes next and it still finds that AgentX has an issue with "C", because there are now no active alerts this is treated as a new alert and a new ticket will be created.
To use: Import the attached SQL. I have prepared it to be safe for import using SQLYog or Control Center, and if you had added it previously it will safely update your current monitor.
Revision History:
2017-09-09 20:00:00 - Version 1 Posted.
2017-10-18 06:00:00 - Version 2. Adds support for ignored alerts (so it ignores that the ticket may be closed) and greatly improves the matches by catching alert tickets with customized alert subjects.
2018-12-11 03:00:00 - Version 3! Indicates when it resets status in the Alert History for any monitor it is acting on.
