No two organizations are alike, so why should your event response tools be? With FrameFlow, you can customize the alerts you want to receive using notification actions. This article is full of tips and tricks that will help you further customize your FrameFlow installation to your organization's needs.
This is the third and final instalment of a series of three articles we've been releasing all about advanced notification settings. The first two are also available for viewing on the blog.
For each of the following tips, go to Settings > Notifications: Profiles > Add/Edit Notification Profile > Add Action, then hit the "More" dropdown to see all options.
By default, the event text generated each time an event monitor runs will contain both the checks were successful and the ones that failed:
Some customers prefer to see only the text about checks that did not succeed. In the Notification Action Properties, there's a checkbox labeled "In error events, don't include text about checks that passed". Clicking it will exclude all successful events from the notification summary available in the event history. Checks that once looked like the above image will now look like the one below, keeping extraneous information to a minimum.
You may have event monitors checking for your network device's up/down status as well as multiple event monitors checking the status of higher-level services. If a device is down, of course the various services it provides are also unavailable. In this situation, you probably don't want the higher-level checks to send alerts when lower-level checks are already reporting the failure.
To give some context, imagine a scenario where you're running a SQL Server database check on a network device that isn't responding. This will cause the SQL Server Event Monitor's check to fail, but it's almost guaranteed that a lower-level check that runs on a more frequent basis has picked up on this already, i.e. a Ping Event Monitor. In the SQL Server Event Monitor's settings, check the box titled "Don't trigger if pings to the originating device fail" and, in the event of a failure, the event monitor will try to ping the device in question. If it doesn't respond, devices with this notification profile will not send an alert telling you the device is down.
This was a feature added in the very earliest FrameFlow releases. You can still use it; however, we recommend you instead use FrameFlow's dependency options as they offer more features and flexibility.
The option called "Don't trigger if pings to this machine fail" works the same as the above option, but you can enter the IP/hostname of any device instead of the originating one.
You can also choose not to trigger certain alerts based on what tags are assigned to the device. Imagine a scenario where you're working on one or more network devices and want to continue monitoring, but don't want to receive email alerts for the device you're working on. You can use the option titled "Don't trigger if the originating device is tagged" to achieve this. Create a tag labeled "No Emails" or something similar and assign it to the devices you want to work on. Apply this tag to whatever network devices you'd like to temporarily disable alerts for, then remove the tag when you're done working on them.
The final option available in Notification Action Settings is the option to stop processing more actions when the notification action is triggered. FrameFlow processes your list of notification actions from top to bottom. If an action is triggered and it has this option enabled, no further notification actions will be processed. This is especially handy when implementing a tiered event response system, as seen in the last blog post on advanced notification actions.
As you can see, FrameFlow is full of endless ways to customize your user experience. It doesn't stop at just notification actions! Give us a try for free and see for yourself how well our product fits your use cases. Click the button below!