Database watcher FAQ (preview)

Database watcher (preview) is a managed monitoring solution for database services in the Azure SQL family. It collects in-depth monitoring data from Azure SQL resources and ingests it into an Azure Data Explorer database, or into a Real-Time Analytics database in Microsoft Fabric. Estate and resource-level dashboards provide detailed data visualizations in the Azure portal. Customers retain full control over collected data and can query, analyze, export, visualize, and integrate it with downstream systems.

At this time, database watcher can monitor Azure SQL databases, elastic pools, and SQL managed instances. All service tiers, compute tiers, and purchasing models of Azure SQL Database and Azure SQL Managed Instance are supported.

Not at this time. For planned improvements to database watcher, see the roadmap section in the database watcher preview announcement. For more information about performance monitoring for Arc-enabled SQL Server, see Monitor SQL Server enabled by Azure Arc (preview).

Database watcher provides detailed visualizations using Azure Workbooks in the Azure portal. In addition, you can create dashboards in Azure Data Explorer or Real-Time Analytics, create visualizations in Power BI, Grafana, or use any other data visualization solution that supports connectivity to Azure Data Explorer or Real-Time Analytics.

Not at this time. For planned improvements to database watcher, see the roadmap section in the database watcher preview announcement.

See Database watcher price. There is no per-database or per-user cost, and no license cost.

Yes, at this time there is a limit on the number of watchers per subscription, and on the number of SQL targets per watcher. For more information, see Limits.

Yes. For more information, see Monitor large estates.

The watcher and the SQL targets it monitors can be in different subscriptions within the same Microsoft Entra ID tenant. Similarly, if the watcher is using a database on an Azure Data Explorer cluster as its data store, the cluster must be in any subscription within the same tenant as the watcher. If you want to monitor SQL targets in multiple tenants using a single data store, create a watcher in each tenant, and use a database in either Real-Time Analytics or on a free Azure Data Explorer cluster as the data store for all watchers. For more information, see Monitor large estates.

Yes. See Create a database watcher for an example you can customize to your needs.

Not at this time. You can create and configure watchers in the Azure portal, using Bicep and ARM templates, or using REST API. For planned improvements to database watcher, see the roadmap section in the database watcher preview announcement.

Yes. You can use either a system assigned or a user assigned managed identity. Grant access to this identity to allow a watcher to collect and ingest data. Revoke access at any time to stop collection of monitoring data.

Not at this time. Viewing the watcher resource requires the assignment of the Reader RBAC role. Operations such as creating, starting, stopping a watcher, or creating/removing targets and the data store require the assignment of Contributor or Owner Azure RBAC roles. Role assignments can be made at the watcher, resource group, subscription, or management group level.

To access dashboards, users require the assignment of the Reader RBAC role on the watcher resource or on a higher scope such as resource group, subscription, or management group. They also require the assignment of the Viewer RBAC role on the Azure Data Explorer or Real-Time Analytics database. These assignments can be made directly or via Microsoft Entra ID group membership.

You can use a database on an Azure Data Explorer cluster, on a free Azure Data Explorer cluster, or in Real-Time Analytics in Microsoft Fabric. To compare between these options, see What is the difference between Real-Time Analytics and Azure Data Explorer?

Yes, if streaming ingestion is enabled on this cluster. Create a new database and grant the managed identity of a watcher access to this database. For smaller cluster SKUs, and depending on the query and ingestion workloads already running, you might need to scale the cluster to support the additional load.

You can use Kusto Query Language (KQL) to query this data. See Use KQL to analyze monitoring data. KQL provides many advantages for analyzing telemetry data. However, you do not need to learn KQL to use database watcher. You can connect to the data store using SQL Server Management Studio, Azure Data Studio, or any other SQL client tool, and use T-SQL to query your SQL monitoring data.

Yes. You can execute a KQL query in a Log Analytics workspace that references tables in Azure Data Explorer. For more information, see Correlate data in Azure Data Explorer with data in a Log Analytics workspace.

Yes. For example, you can export data to Azure storage, a data lake, or a SQL Server or an Azure SQL database.

A remote data collection agent running on a Microsoft managed compute hosting platform connects to your Azure SQL resources, periodically executes T-SQL queries to collect monitoring data from SQL system views, and ingests this data into the data store.

This is unlikely. For details, see Data collection.

It depends on the dataset. For example, frequently changing data such as performance counters might be collected every 10 seconds. Mostly static data such as database properties is collected at longer intervals, for example every five minutes.

The typical data latency from collection to ingestion into the data store is in the 0.5-10 second range. Latency might be higher for large datasets such as Query runtime statistics. You can see current data ingestion latency using the Ingestion statistics link on dashboards.

Yes. All types of secondary replicas, including readable high availability replicas, geo-replicas, and Hyperscale named replicas are supported. If a Hyperscale database has more than one high availability replica, only one of these replicas is monitored at a given point in time.

Database watcher can use Azure Private Link to connect to monitoring targets. When configuring a watcher, create managed private endpoints for your Azure SQL resources. The resource owner must approve each private endpoint for database watcher to use it. Public connectivity is supported as well. For more information, see Network connectivity.

Both Microsoft Entra authentication (recommended) and SQL authentication are supported. If you use SQL authentication, additional configuration to store the login name and password as secrets in a key vault is required.

Data is collected from more than 70 dynamic management views (DMVs) and catalog views into datasets to enable detailed database engine and query performance monitoring.

Not at this time. For planned improvements to database watcher, see the roadmap section in the database watcher preview announcement.

Not at this time. Send us feedback if you find the existing datasets insufficient.

Not at this time. For planned improvements to database watcher, see the roadmap section in the database watcher preview announcement.

See Send feedback. For database watcher technical support, open a support case.

Related content

• Monitor Azure SQL workloads with database watcher
• Quickstart: Create a database watcher to monitor Azure SQL
• Create and configure a database watcher
• Database watcher data collection and datasets
• Analyze database watcher monitoring data