Apologies Bryan, the previous status update was a bit of a mixup
49 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.
You're probably right that a fraction of these votes are about the job step failure alert - but I have no way of splitting these votes out (this is why multi-part suggestions are a bit of a headache). We'll definitely monitor the uptake of the new suggestion you've created (thank you for that!), and prioritise it accordingly if it gains traction, also considering the number of votes from this suggestion.
I'd recommend opening a new suggestion about the "quit the job reporting failure" aspect, as it's quite different from the original suggestion.
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?
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.
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.
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?