How it works

One SQLBeat server watches everything else.

SQLBeat is installed on its own SQL Server instance. From there, SQL Agent jobs reach out to the servers you monitor, collect what they need, and bring it home to a warehouse that SQLBeat manages itself.

Your servers

SQL Servers

Queried directly, or run SQLBeat's scripts from the shared folder

Windows servers

WMI, PowerShell and event logs

IIS servers

Log and config files read over UNC paths

Network devices

Ping, traceroute, syslog

SQLBeat server

Dedicated SQL Server instance

SQL Agent jobs run the checks on schedules you set per server group.

NotificationAuditConfigurationWeblogs

Raw detail goes to monthly databases such as Weblogs202610, rolled up into day and week tables. Three months are kept by default; many teams keep everything.

Shared folder

Scripts that monitored servers run locally, and PowerShell for WMI and AD

Out

Alert engine

Rules pick who gets each alert, and when

Email and chat

Any address, list or channel that accepts email

You

SSMS, Power BI, Grafana or your own procedures, straight against the warehouse

The parts

Four databases, a shared folder, and SQL Agent.

NotificationThe core. Server inventory and settings, SQL monitoring, the alert rules engine and outbound messages.
AuditObject definitions, permissions, logins, files and Active Directory, kept as a history of changes.
ConfigurationWMI monitoring: the counters to read per server, each run's results, processes and application pools.
WeblogsIIS and Apache logs, normalized into fact and dimension tables and rolled up by site, page and day.
Shared folderSQL and PowerShell scripts SQLBeat runs against monitored servers. It must be readable by their service accounts.
SQL Agent jobsA base set of jobs is installed; a trigger creates the per-group monitoring jobs whenever you add a server group.

Day to day

Configured with data, not a control panel.

There's no separate application to run. You add servers, change thresholds and edit alert rules with T-SQL against SQLBeat's tables, or with the procedures that wrap the common changes.

-- Add a server group (its monitoring jobs are created for you)
exec Notification.dbo.pr_addNewServerGroup 'Production', 1

-- Monitor a new SQL Server in that group
exec Notification.dbo.pr_configureForType 'SQLPROD04', 'SQL Server', 1

-- Page the on-call list for critical alerts, day or night
insert into Notification.dbo.messageRules
       (userName, sendMessage, severity, businessHours, offHours)
values ('OnCall', 1, 1, 1, 1)

Requirements

What the SQLBeat server needs.

SQL ServerA dedicated instance, Standard edition or above, with SQL Agent running. SQL Server Express support (through SQL Free Agent) is planned.
Server optionsxp_cmdshell, Agent XPs, Ole Automation Procedures and CLR enabled. The installer turns these on.
SoftwareNothing extra. SQLBeat uses Windows PowerShell and the SQL Server tools already on a Windows server running SQL Server.
AccessNetwork, SQL and WMI access from the SQLBeat server to each monitored server, and an SMTP server it can send through.
Monitored serversSQL Server 2000 through 2022, any edition, and Windows servers reachable over WMI. Nothing is installed on them.

Install SQLBeat