Apologies Bryan, the previous status update was a bit of a mixup
52 votesDaniel Rothig responded
We’re a bit sceptical about this one – with two RegEx fields, this alert already causes a fair amount of time overhead and cognitive load to get configured.
I’ll leave it open and see how it develops
OK that's reasonable - I am worried about increasing the complexity of the the already quite advanced Long-running query alert, but I'll re-open the suggestion to see what others have to say.
To help us understand the issue better, it would be useful if you could provide us with additional examples when you have a user that can't also be identified via the program name - this way we can ensure we'll build the right thing.
We’ve made some improvements in this area but will leave it open so you can continue to give us your suggestions
The underlying problem here seems to be that we run into the 10GB limit in order to not having to provision a non-express SQL Server version. I'll merge this suggestion into the corresponding idea.
Thanks for your suggestion. We are thinking a lot about data retention (for example, we've recently done some research to pinpoint recommended purge windows), and data aggregation is the holy grail in our considerations. However, different types of data require different aggregation tactics, and making this work across the app is a significant chunk of work. We are interested in doing more on this, but since most users are more interested in their recent data rather than their historic data, we often prioritise other work over this problem.
It is possible to extract pruned data (ie. an arbirary subset of representative data points for a given duration) for graphable metrics relatively easily from our data repository. For example, the query...
SELECT * FROM [Cluster_Machine_LogicalDisk_Capacity_UnstableSamples_DateRange]([utils].[DateTimeToTicks]('2013-03-25'), [utils].[DateTimeToTicks]('2013-03-26'), 500)
(object names quoted from memory, please double check)
...would retrieve 500 data points each for disk utilization of every disk on every machine you are monitoring for the specified time range. You could set up a weekly job to extract a week's worth of data from data sources you are interested in and put them into corresponding tables in a different database and derive SSRS reports from this. If you are looking for a workaround, this is probably the best route for you.
We are currently implementing a design which will allow grouping of emails in the Alerts inbox.
We’d really like some early feedback to make sure we’re on the right track. If you’d be willing to take a look at our designs, I’d be grateful if you could reply to email@example.com with ‘Alerts’ as the subject so I can send you further details.
Adam, SQL Monitor Development Team
CONTEXT: We receive Long-running query, deadlock and blocked process alerts. We have to triage large numbers of these alerts.
PROBLEM: Since one alert is raised per process, the number of alerts can be quite large. We have to click into every single alert details report to identify patterns, and configuring them using regular expressions is a time sink.
• Mention the stored procedure names for these alerts earlier on: In the alert emails or the Alert Inbox
• Group similar query-based alerts in the Alert inbox
• Have a "quick config" workflow that exludes the current query from the alert without us having to write any regular expressions
• Suppress query-based alerts for specific databases (e.g. deadlocking 3rd party vendor databases)
What do you think about these solutions? Got another idea? Let us know in the comments!
Hi Jacob, the underlying problem seems to be that the left-hand navigation doesn't drill down all the way to the job level, so if you look at "Job duration unusual" in the alert list, you'll always see a mixture of objects.
The good news is that there is already a list of time-ordered alerts of the same type on the same object! On any alert details page, if you click the "Occurences" tab, you will see a list of alerts on the same job, with a time stamp, linking you through to the relevant details pages. It's a bit bare, but I think it might just get the job done for you.
Hi John, thanks for your suggestion.
You can already filter alerts per database by clicking the expand arrow next to a SQL Server instance in the left-hand "Monitored Entitites" tree view, but some alert types are raised on the SQL Server instance level, and don't have a database associated with them. Did you have a particular problem scenario (or alert type) in mind with this suggestion?
The SQL Monitor database becoming unavailable is, unfortunately, the only edge case of something going wrong with SQL Monitor and it still being capable of sending an email alert.
If you were to monitor the SQL Server hosting the SQL Monitor database, you would get a “Database Unavailable” alert for this, which seems to do what you are asking for.
Could you let us know if that’s an adequate solution, or if we’re missing something?
Just to clarify: Are you monitoring the instance hosting the SQL Monitor database? If you do and don't get any alerts, would you mind dropping a line to support(at)red-gate.com?