First off, Sentry One includes its own SQL Agent job to trap any alerts so essentially what we'll do is replace any notification within the alert and get the alert to run a job instead, in this case the Sentry One trap.
Here's a screen dump of one of the alerts in Management Studio.
Dead simple and of course in this case we wouldn't need to enable database mail as the monitoring application will handle any notifications but if we wanted to retain our mail functionality we can easily do that by ticking the notify operators box and selecting the appropriate operator:
In many cases however this would be overkill but our native functionality can still be of use. Remember the job we're calling? Well we can add a notification to that so should any errors occur between alert and monitoring app we have it covered.
This is just a basic example of how we can implement both native and third party alert effectively with no duplicated alerts. There are of course many different ways of approaching this so definitely test alongside any applications that your organisation already uses to find the optimal way of handling alerts.
This is just a basic example of how we can implement both native and third party alert effectively with no duplicated alerts. There are of course many different ways of approaching this so definitely test alongside any applications that your organisation already uses to find the optimal way of handling alerts.
No comments:
Post a Comment