SQL Server monitoring is the ongoing tracking of a Microsoft SQL Server instance’s availability, performance, and capacity, so that a filling transaction log, a rising deadlock count, or an instance that stopped accepting connections becomes an alert rather than an incident.

Microsoft ships its own diagnostic tooling for deep query analysis: SQL Server Profiler, Extended Events, execution plans, and dynamic management views. Those answer “why was this query slow.” Nagios answers a different and equally important question: is this instance healthy right now, and who gets told when it isn’t. The two are complementary, and most teams need both.

Three configuration wizards cover Microsoft SQL Server (MSSQL). Find them under Configure > Configuration Wizards by searching “mssql.”

MSSQL Database Wizard tracks per-database health:

• Connection time, so you know when the instance is slow to answer before an application does
• Database size and growth
• Transaction log usage, which is the check that catches a log filling toward a stopped database
• Active transaction counts

MSSQL Server Wizard tracks instance-level performance:

• Cache hit ratios
• Pages per second
• Deadlocks per second
• Other server-wide health metrics

MSSQL Query Wizard runs a query you define and tests the result against an expected string or number. This is how you monitor something specific to your environment: a row count that should never be zero, a status column, a queue depth, a job’s last-run timestamp.

Every check reports through the same OK, Warning, and Critical states as the rest of your monitoring, so SQL Server alerts land in the same dashboards, notification chains, and escalation policies as your servers and network gear.

Prerequisites worth knowing: The MSSQL wizards depend on prerequisites that need installing first, and on a monitoring account you create in SQL Server.

Two things are worth planning for rather than discovering mid-setup:

1. Use a dedicated monitoring account with minimal privileges. The underlying check_mssql_health plugin will work with the sa account, but doing so puts a cleartext administrator password into Nagios configuration files. Create a purpose-built monitoring user with only the permissions the checks require.
2. Network access. The Nagios server needs inbound access to the SQL Server port (1433 by default), and named instances require the SQL Server Browser service to be running.

Full setup instructions are in the MSSQL Database monitoring guide.

What Nagios does well is the operational layer: knowing the instance is up, catching capacity problems before they stop writes, alerting on deadlocks and cache degradation, and putting all of it next to the rest of your infrastructure rather than in a database-only console. It’s also built on an open-source foundation, which matters to teams that want to inspect and extend what they run, and it monitors MySQL, PostgreSQL, and IBM DB2 through the same platform if SQL Server isn’t the only database you’re responsible for.

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 Agent job output
• Microsoft Azure Monitoring for cloud-hosted instances