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).

We recommend using database watcher as a managed monitoring solution that provides low data ingestion latency, estate-level monitoring, comprehensive monitoring data including query-level details, and support for advanced analytics on collected monitoring data. For more information about the older monitoring solutions, see the preview announcement.

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. The watcher and its data store can be in different subscriptions in the same Microsoft Entra ID tenant, or in different tenants.

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. A system-assigned managed identity is automatically assigned to a watcher when it is created, and is deleted when a watcher is deleted. Grant access to this managed 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. For planned improvements to database watcher, see the roadmap section in the database watcher preview announcement.

Not at this time. 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 on the watcher, resource group, or subscription.

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. 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 can be 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