Integrate SQL Monitor notifications with devices, ticketing systems and and other monitoring tools
CONTEXT: SQL Monitor is one of multiple tools I use to monitor my estate, such as SCOM, Tivoli, and OpenView. I would like to consoldate notifications from all of these tools
PROBLEM: SQL Monitor only sends human-readable email notifications, but other integration points like SNMP traps are not provided out of the box
• Provide an SNMP demon against SQL Monitor's alerting data
• Make SQL Monitor send SNMP notifications out of the box
• Ability to send SMS or other push notifications
• Ability to "forward" an alert into a ticketing system
Blaž Dakskobler commented
Some have already suggested API, I support that idea - add "REST API for alerts" to the section "EXAMPLE SOLUTIONS".
That would allow us to set up our own integrations.
Justin Whaley commented
I would love to see JIRA integration!
Stephen A commented
+1 for JIRA integration
Arneh Eskandari commented
Integration with Jira or ServiceNow has been coming up quite frequently recently. the request is to be able to create a ticket from the alert details page.
Douglas Johnston commented
I think you may have missed a valuable opportunity here. Personally, I would like the notification channels to be 'plugins', which you could write and we could enable ... or we could write our own based on an API that you publish. This could allow us to fill out the possible channels as a community (similar to the custom alerts), but also allow you to improve the value of Monitor by writing new notification channels.
Steven John Cuthill commented
webhooks webhooks webhooks !!!
Andy Davies commented
SNMP is workable. It would require an additional piece of software between SQL Monitor and Slack though. Would the output be as helpful and readable as the alerts?
I know Red-gate use and promote Slack with DLM particularly. Do you feel that SNMP is workable for your Slack purposes, is this something you are already considering for your own internal purposes?
Andy Davies commented
Be good to have the option to send alerts to Slack in addition or as alternative to email. You have the facility in DLM. Are you planning on rolling out across appropriate products?
Ben Challis commented
We would really like to see plain text emails implemented, or even better a way of modifying the emails so we can put our own text in with variables.
SQLMonitor is a great tool offering, among other things, a practical "alerting console". From the alerting console I would like to "forward" the alert to other alerting systems.
Scenario is: 80% of alert go straight to local developers group or local dba group. The 20% of the alerts cannot go directly to local group, instead it must go to the 24x7 global monitoring system. Since the global group is 90% non Windows, we need to talk with that system.
A possible way is to format the alert to fit the Windows Application Log: from there, an HP Openview agent will catch up the "error number xy" and pass it to the Openview main processor, to feed 24x7 global monitoring system.
I wonder if it is possible to make the "forward" automatic, chosse an extra option in the alert configuration.
This two condition will fix my issue: automatically forwarding some alerts to central systems
I've merged in another suggestion, which was slightly more general in terms (eg, it was looking for other alerting mechanisms like SNMP or OS level commands).
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.
Yes, we can't use this for production monitoring due to this feature not existing as all alerts need to go to a central monitoring tool as snmp. Idera support this, as do Quest with a workaround.
Erin Rajala commented
Would like to add functionality that allows our users to manually trigger an email, when our SOPs state that an Alert requires a support case. To explain further, we do not want the email generated automatically when an Alert is thrown, we want to be able to click a button to generate it Manually, should an Alert need that action taken.
Don Ferguson commented
Now that email messages are more wordy with the 3.3 version of SQL Monitor, this is needed even more. Please don't change a thing with the standard alerts for normal email. I really like the fact that you took the alert number out of the subject line.
What I am requesting is that an additional text only short version alert notification (SMS friendly) be created. It would have a separate set of distribution email addresses. The problem now that certain alerts are configured to send me SMS notification via email address. But it is cluttered with formatting and font information, and the important part of the message is now truncated on my phone.
Thanks a lot for your suggestion.
Matt Laffoon commented
To be more accommodating to different SOPs and workflows it would be beneficial to send an alert email on an ad hoc basis to a variable email address. This allows for the user of SQL Monitor to notify someone of an alert that needs to be reviewed.
For example if a junior level DBA is responsible for monitoring the alerts and only wants to escalate certain alerts that he/she has reviewed, this would allow them to send the email when they are ready by typing in the email address and a custom message. The email history with custom messages can then be stored in the comments of that alert.
I view this as adding flexibility without turning SQL Monitor into a ticketing system.
Thanks for the suggestion - we've logged this as SRP-6953. Incidentally, the alert email headers are currently machine readable if that is useful?
james esterly commented
Allow sending email in plain text format. This will allow integration with ticketing systems and directly sending to text devices (such as cell phones).
Please get this baby working with Paessler's PRTG.