SentryOne Team Blog (blogs.sentryone.com)

SQL Sentry and System Center Operations Manager

SQL Sentry has many customers who have found our monitoring and deep dive tuning capabilities to be a great complement to System Center Operations Manager (SCOM) in their SQL Server environment. SCOM does not provide much out-of-the-box functionality for SQL Server, even with the SQL Server Management Pack. SQL Sentry provides the same scalability as SCOM with a less labor-intensive configuration process. This, of course, is all combined with our visual scheduling and chaining across SQL Server, Windows Task Scheduler, and Oracle servers, as well as our comprehensive performance dashboard with real-time and historical performance analysis and baselining.

SQL Sentry is capable of interfacing with SCOM for purposes of alerting through SNMP traps, the preferred method, or by passing alerts through the Windows Event Log. SQL Sentry supports SNMP versions 1, 2C, and 3, and can send SNMP traps for over 100 alerting conditions provided by SQL Sentry. A monitor can be created within SCOM to pick up these alerts to easily integrate them into SCOM and its enterprise-level alerting and monitoring architecture. SQL Sentry’s SNMP MIBS are installed with the standard setup, and are easily imported into SCOM.

In the following table, I have included a basic overview of features and capabilities of SCOM for monitoring your SQL Server environment, along with high-level information of what SQL Sentry adds:

Feature / Capability SCOM Provides: SQL Sentry Adds:
Alerting High-level alerts on SQL Server conditions such as database offline, backup failures, full files, and job failures. Max runtime alert thresholds for SQL Agent jobs can be configured at the global level only. In-depth alerting on over 100 SQL Server specific conditions including blocking, deadlocks, long running queries, job status, reporting services, and integration services. Max runtime alert thresholds are configurable globally down to the object level, both explicit and percentage-based. Custom conditions can be used to add alerting and response rulesets for any metric on the system.
Performance Monitoring Basic monitoring of a handful of windows counters such as CPU utilization and logical disk utilization/space. Other counters can be viewed manually at the individual server level through the Perfmon library. Live and historical dashboard views of all of the most relevant and actionable SQL Server and Windows level performance metrics. Including but not limited to performance counters, wait stats, disk activity and space down to the SQL Server file level. Also provides drilldown capabilities to and from performance metrics and SQL activity.
Query Tuning /
Problem Resolution
Can be manually configured at the individual instance level to collect some basic information for blocked SPIDs. Provides live and historical monitoring and analysis of long running and high-impact queries, execution plans, blocking, and deadlocks. We also recently added a feature to collect aggregate performance data for queries and procedures that are run extremely frequently, even if individual executions do not exceed your configured runtime threshold.
Reporting Reports for SQL Server lock analysis and top deadlocked databases, SQL Server service pack levels across discovered roles, user connection activity. Detailed and configurable reports on all collected metrics. All reports are able to be generated either from the SQL Sentry Console Directly or can be deployed to Reporting Services to create subscriptions and publish to the web. Our new cloud.sentryone.com service allows you to publish a subset of your performance data to the cloud, providing quick high-level reporting from anywhere (including mobile).

While there are some small areas of monitoring overlap between the two tools, they are primarily centered on high-level alerting capabilities which are provided by both products. As these high-level alerts are already configured within your SCOM deployment, they can simply be turned off within one of the tools to avoid any duplication. I recommend starting out with both sets of alerts enabled to determine which you prefer, then selectively disable those that you don’t want to receive.

As both the SQL Sentry Power Suite and SCOM are designed to minimize the impact of their monitoring upon the servers they watch, they are easily able to monitor servers simultaneously without degrading performance. The combination of the two tools enables the team managing the SQL environment to easily receive alerts through the existing SCOM architecture, then use SQL Sentry to investigate the issue in detail and resolve it quickly.

Comments ( 4 )

    • Jason Hall says:

      Great write up Scott!

      Another nice benefit of integrating this way is that, in most cases, DBAs don't have access to manage security and alerts in SCOM themselves. Using this type of integration, they can have very fine control over what goes to SCOM, when, and how often.

    • Scott Fallen says:

      Thanks Jason! That's a great point.

    • Murad says:

      Scott, could you please provide detailed steps to configure SCOM 2012 R2 to receive and SQL Sentry to send snmp traps successfully. The reason I ask is because out of the box the only way SCOM 2012 R2 can receive snmp traps is if/when the sending device (usually a network or linux device) is configured to run and is running snpm deamon service. Our SQL Sntry is installed/running on Win 2012 R2 and it can't discovered as a network device in SCOM which is required for it to receive traps.

      I would appreciate any help you can provide in resolving this.

      Murad

    • Scott Fallen says:

      Hi Murad,

      Thanks for the feedback. Just a disclaimer to start us off, I know SQL Sentry inside and out, but I'm not a SCOM expert by any means. I think the best workaround for your issue is to not use SNMP for integrating alerts into SCOM. Most of our customers have switched to using the Log To Windows Event Log response within SQL Sentry for alerts they want to deliver to SCOM. Logging to the Windows Event Log gets around new issues like this one, but also and perhaps more importantly, gives more control of SCOM's handling of those alerts. SNMP alerts from SQL Sentry all go into the same bucket within SCOM, where you can use different logging levels and customized event IDs to influence how SCOM picks up and categorizes those alerts.

      I hope this is helpful, please let me know if you have any questions.

      -Scott

    The comments are now closed.