8.3 Monitoring with Database Watcher (Preview)

What Database Watcher Is

Azure Database Watcher (in preview as of the current exam) is a managed monitoring service built specifically for the Azure SQL family. Instead of each database being monitored in isolation through diagnostic settings and DMV scripts, a watcher is a regional Azure resource that you point at a set of SQL targets; it runs built-in collection sets on a schedule, lands the results in a central data store, and presents prebuilt dashboards on top. The goal is a unified, at-scale view of a fleet of databases and instances without authoring and maintaining a custom collection pipeline.

Database watcher is the replacement for the older Log Analytics monitoring solutions. SQL Insights (preview) was retired on 31 December 2024, and Azure SQL Analytics is a legacy Azure Monitor solution that is no longer in active development; Microsoft's documented recommendation for Azure SQL Database and Azure SQL Managed Instance is database watcher. Do not confuse the retired SQL Insights monitoring solution with the SQLInsights resource log category, which is Intelligent Insights and is unrelated. The architectural difference is that the retired solutions depended on each target's diagnostic settings streaming logs into a Log Analytics workspace, whereas database watcher performs its own scheduled collection directly from targets.

Watcher Components

A watcher has four moving parts, and the exam expects you to know what each does:

The watcher authenticates to targets using a managed identity that you grant the appropriate read permissions on the target SQL resources. This is a security property worth noting: Database Watcher does not store credentials; it uses Azure AD / Microsoft Entra identity to connect.

Enabling and Configuring

The high-level flow:

1. Create the watcher resource in the same region as (or a region reachable from) your targets.
2. Create a Microsoft Entra login for the watcher's managed identity on each logical server or managed instance. On Azure SQL Database, grant exactly the three server roles ##MS_ServerPerformanceStateReader##, ##MS_DefinitionReader##, and ##MS_DatabaseConnector##; on SQL Managed Instance, grant the equivalent server permissions plus SELECT on the msdb backup and SQL Agent tables. Granting more than the documented permissions is not harmless - the watcher validates its permission set on connect and disconnects if unnecessary permissions are present.
3. Add SQL targets to the watcher - identified by their Azure resource IDs.
4. Choose the data store - an Azure Data Explorer database or Real-Time Analytics in Microsoft Fabric - and grant the watcher access to it.
5. Start the watcher. A newly created watcher is not started automatically, which is the single most common reason a new deployment shows no data.
6. Review the dashboards - estate-level and resource-level Azure Workbooks that read from the data store.

No agent, no VM, no extension to install on the SQL target: the watcher reaches out from Azure using its managed identity and runs the built-in collection T-SQL directly.

Built-in Collection Sets

Microsoft ships collection sets covering the most-needed performance categories:

• Performance and resource counters - CPU, memory, IO at the database and instance level.
• Wait statistics - aggregated waits by type, to identify the dominant bottleneck category.
• Query statistics - top queries by CPU, duration, and IO, sourced from Query Store when available.
• Blocking and deadlocks - active blocking chains and deadlock occurrences.
• Configuration snapshots - server/database configuration, database files, and sizing.

Because the collection sets are built-in, you avoid the maintenance burden of custom DMV scripts (which break when DMV schema changes, when targets move, or when new versions add new columns). The tradeoff is flexibility: if you need a metric the built-in sets do not cover, you fall back to custom diagnostics or DMV queries alongside the watcher.

When to Choose Database Watcher

The decision pattern the exam tests:

The key advantage of database watcher over the retired Log Analytics solutions is that it performs its own scheduled collection rather than depending on each target's diagnostic settings being configured correctly; you configure the watcher once and it covers all its targets.

Limitations and Preview Status

Because Database Watcher is in preview, the exam expects you to know the practical implications:

• No production SLA; the service may have outages and breaking changes between releases.
• Regional availability is limited; you can only create watchers in a subset of Azure regions, although a watcher in one region can monitor targets in another.
• Limits are subject to change during preview; today they are 100 SQL targets per watcher and 20 watchers per subscription.
• Watchers and dashboards themselves are free. The cost sits in the data store - an Azure Data Explorer cluster or Fabric capacity - plus alert rules and any cross-region bandwidth.
• If a monitored database, pool, or instance sits near 100% CPU, collection queries can be starved and leave gaps in the collected data.

Operational guidance: use Database Watcher for new fleet-wide monitoring designs where the preview limitations are acceptable, but do not retire existing diagnostic-settings-based monitoring or DMV scripts until the service reaches GA and you have validated that the built-in collection sets cover your needs. Keep at least one target on the older pipeline as a parallel-run control.