Version 7.1.2 is now available and features a beta for the ability to install multiple base monitors with a single UI.
Documentation can be found here: https://documentation.red-gate.com/display/SM7/Multiple+base+monitors
We’d really like to get your feedback if you try this out, so we can get an idea of how many people are using multiple base monitors, and where we can improve it.
Please email firstname.lastname@example.org with any feedback, or if you have any questions we can help with.
"Something" really needs to be done to make this a whole lot easier. I've been a SQL Monitor user since the first v3 came out and am one of those Accidental DBAs who have a love-hate relationship with all things Windows and SQL Server security/Login/User stuff.
Having just reset a Windows box at Rackspace and using SQL Monitor on Azure, it took a half day to get SQL Monitor and that box to agree to being monitored.
Having had to erase everything to with the box's history from SQL Monitor and re-add it, rather than any re-deploy Action, I'm just glad that adding a box to SQLM isn't a daily chore/endurance/pain-in-the-posterior.
Even having read the SQLM documentation re Security, and the prior non-DBA's write-up (proved inaccurate), scaling to more than a few boxes is a limitation/weakness of the current SQLM iteration (5.1 BTW).
The far-end installer needs help to make it usable by A-DBA's like me.
The Host needs help with re-deployment. We absolutely need Friendly Name overrides on EVERY SINGLE PAGE - so tired of seeing a Group Name (friendly), then get stuck with an I.P. or a Rackspace device-ID on emails/subpages/configs at random... Even things like that will promote scalability by making the tool consistent/easier to use. It's often a case of "do I have to go over to SQLM to.....?" Sorry, but that's the truth...
currently under investigation
We’ve made some improvements in this area but will leave it open so you can continue to give us your suggestions
Our Production SQL Monitor DB is north of 90GB, skinnied down to near minimal data retention, (making the tool less useful for historical analysis). Please consider this as more of the norm for larger customers.
We, too, had to either use Azure, incurring the SQL Server license bump, or hunt for a spare license, which wasn't available without hurting a paying customer. Open source DB would be preferable to the 8K for Standard, likely to go up in price with Microsoft's mooted core licensing for Standard edition...
Thanks for the clarification, Fiona. I wonder this wasn't mentioned over a year ago when we purchased the product...
We will happily use SQL2008R2 Express with its 10GB limit and would welcome you posting the edits either here or as a sticky on the SQL Monitor 3 Forum itself (or both). We would prefer to keep the purge window small and NOT reduce the collection frequency.
Using hosted servers, we have a SQL cluster that is our Production machine. The inability to install the Base Monitor on that cluster requires us to purchase an additional SQL Server and license it at in excess of $8K for the SQL Std license plus ongoing monthly charges.
This makes an inexpensive, quality product much more expensive...
We have Web Servers to handle IIS7 but the Base Monitor is the issue.
Version 6.0.7 has just been released and contains beta support for Slack and SNMP integration for alert notifications.
We’re interested to hear your feedback on this.
SQL Monitor Development Team
This is also needed because there doesn't appear to be a way to say, "keep forever" (i.e., until explicitly deleted), and I keep "special" alerts in a separate email folder for reference.
When monitoring database growth over a year, SQL Monitor doesn't allow me to keep these alerts in a special "keep forever" state. The ability to go back to SQL Monitor and re-generate an email from a soon-to-be-deleted Alert covers my butt for the times I inadvertently permanently delete a set of Alerts, among which I failed to notice the DB Growth incident.
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
SQL2012 introduces a sluggish, blocking-prone "Maintenance Process" that operates on the SSISDB.
SSISDB is the object blocked and "SSIS ISSServerExec" is the process blocked.
Please give us database-savvy and process-name-savvy exclusion options, much like, at least for process names, those in place for Long Running Query Alerts.
Microsoft has a lot of work to do to make their SSIS maintenance and other SSIS artifacts better in SQL2012. Pending this, which is likely to a very long time, please consider these options for further reducing "noise".
ADAM, It has been almost a YEAR since your post. Any UPDATES?
Would that you could improve the Alert's "SQL Culprit". I have a UDF that is heavily used, so the snippet I see is that code, not the underlying code that used it, so I'm utterly blind and the Alert is nigh on useless. Is there ANYTHING you can do to "give me more about the context", please?
The additional SSIS info would be VERY helpful, especially as the SSISDB query from SSMS is a SLUG and cumbersome and calls for a lot of clicking to drill down to the information - and I only have ONE PACKAGE in SQL2012 to monitor!
Custom Metrics are OK for low-volumes of Jobs and servers, but as each and every Custom Metric of this kind cites ONE and ONLY ONE Job, and the Alert must, therefore, be named coincident with the Metric, it is not a long term viable option.
I have used a technique SIMILAR to what Fiona describes but using an excessive DURATION and, while it does work, it's not something I look forward to maintaining/reproducing across instances/jobs.
Please consider, as Steve requested, ENHANCING SQL Monitor so there is a built-in Alert that one can pick the Job Name and state EITHER the duration(s) from the Start-time after which a Low, Medium or High Alert must be emitted, or the exact time that the Job must be complete by.
SQL Monitor Forum Post http://www.red-gate.com/MessageBoard/viewtopic.php?p=57950#57950 details the scenario and query.
28 votesDaniel Rothig responded
Custom metrics on sys.dm_io_virtual_file_stats are the best way to get this today
As an accidental DBA, this, to me, seems quite important... Is it? If so, is there a reason why it doesn't appear in the Alert-set for SQL Monitor? Planned inclusion, perhaps?
Helpful insight within SQL Monitor would assist folks like me to act upon what seems a serious condition.
Comments, Red-Gate folks...? (I don't know enough about this kind of Alert to know one way or the other whether to take note or ignore - need guidance)