Monitoring Azure SQL Database Service

The Azure SQL Database Service sensor is automatically deployed and installed after you install the Instana agent.

Learn about the other supported Azure services with our Azure documentation.

Supported information
- Supported client-side tracing
Configuration
Metrics collection

Supported information

Supported client-side tracing

For this technology, Instana supports client-side tracing for the following languages and runtimes:

Starting from version 3.2.0, Instana Node.js Tracer supports tedious for connecting to Azure SQL Database.

Configuration

Azure SQL Database sensor can be disabled, filtered by tags and resource groups and replica databases can be filtered also. It is possible to configure Azure SQL Database sensor via agent configuration in <agentinstall_dir>/etc/instana/configuration.yaml by:

com.instana.plugin.azure.sqldb:
  # Valid values: true, false
  enabled: false # enabled (true) by default
  # Valid values: true, false
  enable_replica_monitoring: true # disabled (false) by default
  # Comma separated list of tags in key:value format
  include_tags:
  # Comma separated list of tags in key:value format
  exclude_tags:
  # Comma separated list of resource groups
  include_resource_groups:
  # Comma separated list of resource groups
  exclude_resource_groups:

Azure SQL Database sensor can be disabled. To disable monitoring of the Azure SQL Database services use the following configuration:

com.instana.plugin.azure.sqldb:
  enabled: false

Azure SQL Database sensor does not monitor replica databases by default. To enable monitoring of the Azure SQL replica databases use the following configuration:

com.instana.plugin.azure.sqldb:
  enable_replica_monitoring: true

Multiple tags and resource groups can be defined, separated by a comma. Tags should be provided as a key-value pair separated by :. In order to make configuration easier, it is possible to define which tags and resource groups you want to include in discovery or exclude from discovery. In case of defining tag or resource group in both lists (include and exclude), exclude list has higher priority. If there is no need for services filtering, the configuration should not be defined. It's not mandatory to define all values in order to enable filtering.

To include services by tags into discovery use following configuration:

com.instana.plugin.azure.sqldb:
  include_tags: # Comma separated list of tags in key:value format (e.g. env:prod,env:staging)

To exclude services by tags from discovery use following configuration:

com.instana.plugin.azure.sqldb:
  exclude_tags: # Comma separated list of tags in key:value format (e.g. env:dev,env:test)

To include services by resource groups into discovery use following configuration:

com.instana.plugin.azure.sqldb:
  include_resource_groups: # Comma separated list of resource groups (e.g. rg_prod,rg_staging)

To exclude services by resource groups from discovery use following configuration:

com.instana.plugin.azure.sqldb:
  exclude_resource_groups: # Comma separated list of resource groups (e.g. rg_dev,rg_test)

Discovery filtering can be configured on the global level for all Azure services. In case of defining filters for Azure API SQL Database service, global filters will be overridden. For more details about global Azure service discovery filtering visit Azure Configuration.

Metrics collection

To view the metrics, select Infrastructure in the sidebar of the Instana User interface, click a specific monitored host, and then you can see a host dashboard with all the collected metrics and monitored processes.

Metrics are pulled every minute, which is the resolution Azure provides for monitoring of these services.

Configuration data

Database Details	Description
Name	Database name
Resource Group	The resource group of the database
Location	Database location
Subscription Id	The subscription ID of the database
Max Size	The max size of the database expressed in bytes
Status	The status of the database
Zone Redundant	Whether or not the database is zone redundant, which means the replicas of the database will be spread across multiple availability zones
SKU	Pricing tier (SKU)

Performance metrics

Metric	Unit	Aggregation	Description
DTU
DTU Limit	Count	Average	Total DTU utilization of the database
DTU Used	Count	Average	DTU utilization of the database
DTU Percentage	Percent	Average	DTU utilization percentage
CPU
CPU Percentage	Percent	Average	CPU resources consumed by all database sessions
Connections
Successful Connections	Count	Total	Total number of successful connections
Failed Connections	Count	Total	Total number of failed connections
Blocked By Firewall	Count	Total	Total number of connections blocked by the firewall
Deadlock
Deadlocks	Count	Total	Deadlocks
Storage
Storage	Bytes	Maximum	Total database size
Storage Percentage	Percent	Maximum	Database size percentage
IO
Data IO	Percent	Average	Data I/O utilization
Log IO	Percent	Average	Log I/O utilization
Other
Workers	Percent	Average	Concurrent workers (requests) of the database’s service tier limit by the Microsoft Azure SQL Database
Sessions	Percent	Average	Concurrent sessions of the database’s service tier limit
In-memory OLTP Storage	Percent	Average	In-memory OLTP Storage (XTP Storage)
vCore
vCore Limit	Percent	Average	Total number of available vCores
vCore Used	Percent	Average	Used vCores

* DTU metrics are available only for DTU-based resources

** vCore metrics are available only for vCore-based resources

Health signatures

For each sensor, there is a curated knowledgebase of health signatures that are evaluated continuously against the incoming metrics and are used to raise issues or incidents depending on user impact.

Built-in events trigger issues or incidents based on failing health signatures on entities, and custom events trigger issues or incidents based on the thresholds of an individual metric of any given entity.

For information about built-events for Azure SQL Database Service sensor, see the Built-in events reference.