MSSQL monitoring tracks the availability, performance, and capacity of a Microsoft SQL Server instance: whether databases are reachable and responsive, how much of a transaction log is consumed, whether log flush waits and truncations look normal, and whether transaction throughput is drifting. SQL Server’s built-in tooling answers why an individual query was slow. Monitoring answers whether the instance is healthy right now, and who gets told when it isn’t.

SQL Server monitoring lets you:

• Prevent write outages by catching a transaction log before it fills
• Catch degradation early through connection time, throughput, and log behavior trends instead of user complaints
• Plan capacity with evidence by tracking database growth over months, not checking size once during an incident
• Verify scheduled work ran so a failed backup or import job surfaces the same day
• Shorten diagnosis by seeing the database, its Host, and its storage in one place

Nagios XI includes three MSSQL configuration wizards that guide you through connecting to a SQL Server instance and selecting the checks you want to run. Find them under Configure > Configuration Wizards and search “mssql.”

SQL Server Database Monitoring

The MSSQL Database Wizard monitors metrics for a specific database:

• Connection Time: Measure how quickly the instance responds, so a slow-to-answer database surfaces before an application timeout does.
• Database Size: Track overall growth and storage consumption over time.
• Log File Usage: Monitor how much of the transaction log is consumed. This is the check that catches a log filling toward a stopped database.
• Active Transactions: Watch currently running transaction counts to spot stuck or runaway transactions.
• Transactions Per Second: Measure throughput as a performance indicator.
• Log Flush Waits, Growths, Shrinks, and Truncations: Monitor transaction log behavior, where unexpected patterns often precede a capacity or performance problem.
• Log Cache Hit Ratio: Evaluate log cache efficiency.

Reference: How To Monitor MSSQL Databases With Nagios XI 2024 and 2026 (PDF)

SQL Server Instance Monitoring

The MSSQL Server Wizard monitors the health of the SQL Server instance as a whole rather than an individual database, covering server-wide performance and resource metrics. Unlike the Database and Query wizards, it does not require you to name a database.

SQL Server Query Monitoring

The MSSQL Query Wizard runs a query you define and tests the result against an expected string or number. This covers the conditions no generic metric reaches:

• Scheduled Job Status: Query job history for the last run result, so a failed backup or import job alerts the same day.
• Availability Group State: Query the HADR dynamic management views to track synchronization state and secondary lag.
• Replication Health: Check distribution latency or undistributed command counts against a threshold.
• Application-Specific Checks: A row count that should never be zero, a queue depth, a status column, or a timestamp that should be recent.

Reference: How To Monitor MSSQL Queries With Nagios XI 2024 and 2026 (PDF)

Thresholds, Alerting, and Reporting

• Configurable Thresholds: Set Warning and Critical levels per metric in Step 2 of each wizard, following the Nagios Plugin Development Guidelines threshold format.
• Unified Alerting: SQL Server alerts route through the same notification chains, contacts, and escalation policies as the rest of your monitored environment.
• Retained Performance Data: Nagios XI keeps performance data from every check, so Capacity Planning and Availability reports can show that a metric has been drifting for weeks rather than only that it looks wrong today.
• Agentless Connection: Nagios XI connects to the instance over the network. Nothing is installed on the database Host.

Security and Access

• Dedicated Monitoring Account: Do not use the sa or administrator account. Create a purpose-built monitoring login and grant it VIEW SERVER STATE.
• Windows or SQL Authentication: Both are supported. Windows authentication maps a domain account to an internal MSSQL user.
• Role-Based Access Control: Per-object permissions, read-only user roles, AD and LDAP integration, API-key authentication, and two-factor authentication mean DBAs can see database Services without seeing the whole estate.
• Self-Hosted: Nagios XI runs on your infrastructure, so database credentials and performance data never leave your network.

Catch Capacity Problems Before They Stop Writes: Transaction log exhaustion is entirely predictable. A log at 80 percent with a Warning threshold gives you hours. A log at 100 percent gives you an outage and a recovery.

Diagnose Faster Across Layers: “The database is slow” and “the storage under it is saturated” produce identical complaints and need different fixes. Monitoring the instance, its Host, and its volumes together turns an hours-long investigation into a glance.

Turn Monitoring Data Into Planning: Retained performance history answers “when will this need more storage,” not just “how full is it now.” That version survives a budget conversation.

Consolidate Tooling: The same installation monitors MySQL, PostgreSQL, Oracle, and IBM DB2, plus the servers, storage, and network path around them.

Add Monitoring in Minutes: Adding an instance is a guided five-step form, not an afternoon of editing object configuration files.

Extend It Yourself: Built on open-source Nagios Core. The MSSQL Query Wizard runs any query you can write, and anything scriptable in any language becomes a check.

Your SQL Server needs a small amount of preparation before the wizards will connect. The full walkthrough with screenshots is in How To Monitor Microsoft SQL With Nagios XI 2024 and 2026 (PDF). The essentials:

Create a monitoring account

• Create a login in the MSSQL instance for Nagios XI to connect with, using either Windows or SQL authentication. Even with Windows authentication, a linked MSSQL account is required.
• Grant that login the VIEW SERVER STATE permission, then assign it as a user on each database you intend to monitor.
• Do not use the sa or administrator account.
• Make sure the account cannot expire. If it does, monitoring breaks at that moment with no warning. For SQL authentication, un-check Enforce password expiration.

Confirm network access

• The default MSSQL instance commonly listens on TCP 1433. Create an inbound Windows firewall rule permitting traffic from the Nagios XI server.
• If Nagios XI and the SQL Server are on separate subnets, the routers between them may need rules too.
• To connect by instance name rather than port, the SQL Server Browser service must be running and UDP 1434 must be permitted. Each instance also needs its own dedicated port and firewall rule.
• In the wizard you supply either an instance name or a port, not both.
• Multiple instances on one server, and SQL Express Edition, should be configured on fixed ports rather than dynamic ones.

1. Prepare the SQL Server: create the monitoring login, grant VIEW SERVER STATE, assign it to the target databases, and open the firewall.
2. In Nagios XI, go to Configure > Configuration Wizards and search “mssql.” Choose the Database, Server, or Query wizard.
3. Step 1: Enter the connection and authentication details. Use the FQDN rather than a flat host name, supply either the instance name or the port, and provide the monitoring credentials. The Database and Query wizards also require the database name.
4. Step 2: Select the metrics to monitor and set Warning and Critical thresholds for each. Confirm the Host Name field clearly identifies this SQL Server.
5. Steps 3 through 5: Complete the remaining options, then click Finish to apply the configuration and begin monitoring. Use the View status details link to see the new Host and Services.

Nagios XI covers availability, capacity, and threshold monitoring. It tells you the instance is unhealthy, the log is filling, throughput has dropped, or a job failed, and it tells the right person immediately. Statement-level tuning such as execution plan capture and index recommendations is a different category of tool.

The breadth is the point. A database-only console tells you the database is unhappy. Nagios XI tells you whether the cause is the database, the volume underneath it, or the Host it runs on.

Other Databases

• Database Monitoring covers the full range across platforms
• MySQL Monitoring
• PostgreSQL Monitoring
• Oracle Monitoring
• IBM DB2 Monitoring

The Infrastructure Underneath

• Server Monitoring for the Windows or Linux Host running the instance
• Disk Monitoring for the storage a database fills
• Log File Monitoring for SQL Server error logs and job output
• Microsoft Azure Monitoring for cloud-hosted instances

Bring database health checks into the same platform you already use for the rest of your infrastructure. Start a free trial or book a demo to see how MSSQL monitoring fits your environment.