See how alerts correlate in time
CONTEXT: When investigating an alert, it is useful to see what else has happened at the time. SQL Monitor gives detailed performance and query data with every alert details report, but doesn't show what other alerts have been raised at the time
PROBLEM: Sometimes alerts inform one another. E.g. a Long-running query can be caused by a blocked process, or a deadlock can cause a job failure. Alerts coinciding with the current one potentially help us to determine the root cause
• List time-correlated alerts when viewing alert details
• See alerts over time on a graph
• Export alerts to an outlook calendar
What do you think about these solutions? Got another idea? Let us know in the comments!
We are releasing a version of the beta at the beginning of August which will show alerts over time on the server overviews. We’d love to get your feedback on this.
Drop us a line at firstname.lastname@example.org if you’d also be interested in talking to us so we can get a better understanding of how we can improve this feature.
Dennis Walker commented
I am glad to hear my suggestion has finally made it to the top of your list. Let me know when the beta is available and I will give it a test.
Thanks for your suggestion, I think this would improve the efficiency of researching events. I have logged this suggestion as SRP-9223
Dennis Walker commented
I have been fighting an occasional Blocked Process alerts. One of the problems with researching these events is that the first event, the one causing the issue, is not the first event on the Alerts tab of Heath Monitor. Also, the emailed alerts note an Alert number, which is not displayed on the website anywhere that I have been able to find except the URL of the web page. It would be helpful to be able to sort the list of alerts by either the time the event was FIRST raised, or by the event number. This would then make the offending event show up first in the list. For now, I have to review the email stream to locate the first event.
Thanks for the clarification. I'm beginning to wrap my head around why this nonstandard use of iCal is actually quite an elegant improvement over the RSS metaphor. I'll be interested to see how other people feel about this feature, and how popular this suggestion becomes compared to the other feedback we receive.
Just one other point Daniel, you asked:
"Would a calendar view within SQL Monitor be more or less useful than viewing the information in an iCal client?" but perhaps a better question might have been:
"Would the information in the RSS feed (which is what Jonathon originally blogged about) be more or less useful than viewing the information in an iCal client?"
Both are subscription technologies. Both require specialist client software (RSS client & Calendar client respectively).
The advantage of iCal (IMO) is that presenting the information in a calendar provides the priceless context of *when*. Furthermore, everyone uses a calendar, not everyone uses an RSS reader.
The point being, if you're providing an RSS reader then I can't really see any justification for not providing an iCal feed also.
"In what scenarios would you like to see a calendar view of your alerts? "
Not really sure what you mean. I think the answer is "all scenarios".
"why would a calendar view be more readable than, say, a plain list of alerts?"
The beauty of subscribable calendars is that the data just 'flows' into the places that I already send my time (i.e. my Outlook/GMail calendar). "More readable" isn't really the benefit here, its simply that I don't have to go to (yet) another place to see data. The data comes to me, I don't have to go and get it.
"How would you expect the system to behave if there is a large volume of alerts? Would you still like to receive all of them?"
"Would a calendar view within SQL Monitor be more or less useful than viewing the information in an iCal client? Why?"
Less. Hopefully my previous answer speak to the "why".
"Any feedback you could give us would be much appreciated!"
Subscribable calendars are a bit of a soapbox subject for me. For further explanation I invite you to take a read of this blog post that I wrote some while back: http://sqlblog.com/blogs/jamie_thomson/archive/2010/06/03/thinking-differently-about-bi-delivery.aspx
Thank you Jamie.
Jonathan Allen recently blogged about the ability to view SQL Monitor alerts as an RSS feed: https://www.simple-talk.com/blogs/2013/06/04/sql-monitor-alerts-in-outlook-without-configuring-email-settings/
This is cool and all, one thing I'd also like to do is be able to view these events in my calendar (any calendar, not just an Outlook calendar).
An industry standard exists for subscribable calendars - its called iCalendar. iCalendar allows someone to expose data (any data) in a manner that allows iCalendar compliant clients (e.g. Outlook, Google Calendar, Outlook.com calendar) to consume and display that information. The beauty of *subscribing* to iCalendar calendars rather than *importing* them is that new events automatically turn up in the client. if the user has got that calendar synced to their smartphone they automatically show up there too. No work required on the part of the user. This is the power of subscription (its wonderful when it works).
Hence, my suggestion is that you expose the same events that are currently in the RSS feed in iCalendar format - thus allowing someone to view that data in their calendar and thus get the context of *when* something happened as well as simply *what* happened (which is what the RSS feed gives you).
Hope that makes sense.
note that i discussed this with Jonathan & Priya Sinha on Twitter and Priya suggested (https://twitter.com/sinha2009/status/342287315307220992) I raise it here.
Priya Sinha commented
Thanks a lot Andrew for the idea!
Andrew Hodge commented
I would like to be able to filter on alerts based on time only. I want to see the alerts that are occurring on a repeating pattern. ie All the alerts between 1.00am and 2.00am over the last n days.