Microsoft SQL Server Monitoring

​LogicMonitor comes ready to monitor your Microsoft SQL Server database infrastructure, whether you’re running it on Windows, Linux, Docker containers, or hosted at Azure.

LogicMonitor’s SQL Server monitoring primarily uses SQL database queries to poll internal SQL monitoring tables. Connections are made through JDBC connection strings using Windows authentication or SQL Server authentication.

Requirements

• WMI (for SQL Server on Windows). LogicMonitor uses the WMI protocol for automated SQL-named instance discovery and SQL services (browser, reporting services, agent, and so on) discovery.
• SNMP (for SQL Server on Linux). LogicMonitor uses the SNMP protocol for automated SQL Server discovery.
• LogicMonitor’s Microsoft SQL Server package is compatible with SQL Server 2005 through 2022 using Windows or SQL Server Authentication.

Adding Resources Into Monitoring

Add your SQL Server hosts into monitoring. For more information on adding resources into monitoring, see Adding Devices.

Credentials

LogicMonitor must be able to provide the appropriate credentials in order to successfully access each instance of SQL Server. These credentials must belong to a user account with the following minimum SQL Server permissions:

/* make sure to put your complete username in the form of DOMAIN\USERNAME
If the user already exists for a database there will be errors displayed.  These can be ignored
*/
DECLARE @username VARCHAR(100)
 
--Enter username here
select @username = '<MonitorUserName>'
 
DECLARE @dbname VARCHAR(50)  
DECLARE @statement NVARCHAR(max)
Use master;
SELECT @statement = 'CREATE USER ['+@username+'] FOR LOGIN ['+@username+'];
GRANT VIEW ANY DEFINITION TO ['+@username+'];
GRANT VIEW SERVER STATE TO ['+ @username+'];
GRANT VIEW ANY DATABASE TO ['+ @username + '];
USE MSDB;
CREATE USER ['+ @username + '] FOR LOGIN ['+ @username + '];
GRANT SELECT ON SYSJOBS TO ['+ @username + '];
GRANT SELECT ON SYSJOBHISTORY TO ['+ @username + '];
GRANT SELECT ON SYSJOBACTIVITY TO ['+ @username + '];'
exec sp_executesql @statement
 
/* this section will create access for Microsoft_SQLServer_Storage datasource only. 
Not needed if not using this module.
*/
 
DECLARE db_cursor CURSOR
LOCAL FAST_FORWARD
FOR 
SELECT name
FROM MASTER.dbo.sysdatabases
WHERE name NOT IN ('master','model','msdb','tempdb','distribution') -- ignore system databases
OPEN db_cursor 
FETCH NEXT FROM db_cursor INTO @dbname 
WHILE @@FETCH_STATUS = 0 
BEGIN 
SELECT @statement = 'use ['+@dbname +'];'+ 'CREATE USER ['+@username+']
FOR LOGIN ['+@username+']; '
exec sp_executesql @statement
FETCH NEXT FROM db_cursor INTO @dbname 
END 
CLOSE db_cursor 
DEALLOCATE db_cursor

As discussed next, the user account that LogicMonitor uses to connect with SQL Server will be authenticated by either Windows or SQL Server, depending upon the operating system upon which SQL Server is running.

Integrated Security (Windows)

By default, LogicMonitor assumes Integrated Security is used and will attempt to connect with SQL Server using Windows authentication, not SQL authentication. LogicMonitor uses the Windows credentials that are associated with the user on the Collector; therefore, the user on the Collector must have the minimum SQL Server permissions mentioned previously. There is no way to update the user associated with the Collector to an alternate user with Integrated Security.

If Integrated Security is not configured, connection can be authorized via JDBC credentials, as discussed in the following section. Otherwise, JDBC credentials, even if present as properties on the Collector, are ignored.

Conditional requirement:

• SQL Server Browser service. Allows the Collector to communicate with SQL Server instances without the need for specifying ports. This is only required if one of the following conditions is present:
  • The SQL Server instance(s) are listening on non-standard ports (ports other than default 1434) and you have elected not to define these ports using the jdbc.mssql.port property (this property is discussed in the following Assign Properties to Resources section of this support article).
  • A SQL Server instance is set to listen on dynamic ports.

JDBC Credentials

For direct SQL authentication in Azure, Docker, or Linux (or Windows if Integrated Security Is Unavailable), JDBC credentials are required. These credentials are configured as properties (jdbc.mssql.user and jdbc.mssql.pass) on the host. If there are different authentications for individual SQL instances then the mssql.<instance name>.user and mssql.<instance name>.pass properties are used instead. For more information on these and other properties available for assignment on SQL Server hosts, see the next section of this support article.

Assign Properties to SQL Server Resources

The following properties can be set on the SQL Server resource within LogicMonitor. LogicMonitor strives to auto-discover all properties needed for SQL Server configurations. However, there may be use cases where you will need to manually enter properties or override auto-discovered properties. For more information on assigning properties, see Resource and Instance Properties.

Migration to Latest LogicModules

In February 2020, LogicMonitor’s SQL Server package received significant updates to enhance performance and have a lower impact on Collector and SQL Server load. As a result of these updates, some DataSources may create new instances with new names. This is the result of fixes to earlier DataSource versions that were creating non-conforming instance names. If new instances are created, the old instances will no longer collect data but will remain in place (until you manually delete them) for historical purposes.

In addition, the following DataSources were deprecated:

• Microsoft_SQLServer_AgentJobs. This DataSource has been superseded by Microsoft_SQLServer_SystemJobs, which captures the same data.
• WinSQLServer-. This DataSource has been superseded by Microsoft_SQLServer_GlobalPerformance, which captures the same data.
• WinSQLServerConnection-. Used to report the roundtrip time for a connection, this data has largely been found to not be useful.

Troubleshooting: Missing Performance Counters

SQL Server Performance Objects and counters are installed automatically as part of the installation. If these objects and counters are missing, it is likely that the installation process experienced an error which resulted in the counters not being properly installed.

A definitive way to check if failures have occurred is to search for Error: 3409 in your SQL setup logs.

To reset the counters, perform the following steps:

1. Unload the counters by running unlodctr mssql$ from Run Command.
2. Identify the file path where performance counters are located. The default path is HKLMSYSTEMServicesCurrentcontrolsetServicesMSSQL$Performance.
3. Reload the counters by running lodctr from Run Command.

Additional performance counter troubleshooting can be found in Microsoft’s documentation system.

LogicModules in Package

LogicMonitor’s package for SQL Server consists of the following LogicModules.

AlwaysOn Availability

AlwaysOn Availability Groups use SQL clusters and require the use of SQL Listeners on a Windows Cluster Virtual Network Name (VNN).

By default the AlwaysOn modules use one Listener. When only one Listener exists, the DataSources monitor the system databases on the active node for the Listener and monitor any databases not assigned to the Listener but on the currently active node. In situations with multiple Listeners, the resource property mssql.onlyAlwaysOnDatabases=true must be set on the VNN resource. When this resource is set, only databases in the AvailabilityGroup assigned to the Listener are monitored. System databases and databases not assigned to the AvailabiltyGroup are not monitored.

ConnectionStatus

The Microsoft_SQLServer_ConnectionStatus DataSource is used to check connectivity from the collector to an SQL Server database. By default, the DataSource attempts to connect to the SQL Server database three times using the following behavior before alerting:

• First attempt fails: DataSource waits three seconds and then attempts to reconnect.
• Second attempt fails: DataSource waits 12 seconds and then attempts to reconnect.
• Third attempt fails: DataSource sends an alert.

You can use the ConnectionStatus properties to set the number of tries and the length of time between tries. To prevent the DataSource from hitting a timeout or exceeding the collection interval, keep in mind the following time constraints:

• The collection interval times out at 60 seconds.

• The timeout for DataSources defaults to 180 seconds, but can be changed in the collector properties.

When a connection to the database is successful, the DataSource runs the select statement SELECT getdate() as systemDate and reports the number of rows returned, as well as the time for execution. This select statement can be overridden with a device property. Properties are in the form of mssql.propertyName or mssql.instance.propertyName.  When mssql.instance.propertyName is used, the property will be used for a specific SQL instance name.  When there is no instance specified, the DataSource uses the same property for each SQL instance on the device.

ConnectionStatus Properties

Sample Setup