Azure metrics data for Connections metrics in Dedicated SQL Pool is unavailable while fetching through Function App

Hello Arpita Das,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Azure metrics data for Connections metrics in Dedicated SQL Pool is unavailable while fetching through Function App.

To save time with best practices, follow the below steps to resolve the issue:

1. Treat “Connections” as login attempts/min (not active users) for Synapse dedicated SQL pools it’s the count of total logins, so read it as a rate, not concurrency supported metrics; monitoring ref. Using this bash command: az monitor metrics list --resource <sqlPoolResourceId> --metric Connections --interval PT1M
2. Measure real concurrency with DMVs query live sessions (for an example, sys.dm_pdw_exec_sessions) instead of relying on the Connections metric DMV doc; DW DMV monitoring. SELECT COUNT(*) AS active_sessions FROM sys.dm_pdw_exec_sessions WHERE status='ACTIVE';
3. Interpret spikes as connect/disconnect churn by using audit logs to chart login rate and check pooling/retry patterns SQL audit log format SQLSecurityAuditEvents; ADO.NET pooling. AzureDiagnostics | where Category=="SQLSecurityAuditEvents" and action_name_s has "LOGIN" | summarize logins=count() by bin(TimeGenerated,1m)
4. Get failure reasons from platform logs for Azure SQL DB, sys.event_log shows firewall/auth errors with messages and counts (sys.event_log). SELECT * FROM sys.event_log WHERE event_type='connection_failed' ORDER BY end_time DESC;
5. Correlate metrics + DMVs + logs in one view by use Metrics (trend), DMVs (live), sys.event_log (failures), and Log Analytics audit events to stitch the picture using kusto Monitor Synapse; audit schema fields. AzureDiagnostics | where Category=="SQLSecurityAuditEvents" and action_name_s contains "AUTHENTICATION"
6. Enable auditing to Log Analytics (as this is mandatory for traceability) to send SQLSecurityAuditEvents via Diagnostic Settings so you can query all logins and failures centrally Auditing setup; Diagnostic settings. Using thios bash command:az monitor diagnostic-settings create --resource <dbId> --name sqlaudit --workspace <lawId> --logs '[{"category":"SQLSecurityAuditEvents","enabled":true}]'
7. Fix app behavior if spikes persist, turn on pooling and tame retries (keep connections short‑lived but reused; cap pool size) to avoid “retry storms” ADO.NET pooling knobs; TechCommunity guidance. In C#: var cs="Server=tcp:...;Database=...;Pooling=true;Max Pool Size=200;"; using var c=new SqlConnection(cs); await c.OpenAsync();

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Hi @Arpita Das ,

Thanks for reaching out to Microsoft Q&A.

Here are the most common reasons & things to try:

1. Verify you’re targeting the right resource and metric namespace
   • For a dedicated SQL Pool under Synapse, the resourceId should look like: /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Synapse/workspaces/{ws}/sqlPools/{pool}
   • If you accidentally point at the “Microsoft.Sql/servers/databases” namespace (or the Function App itself), you won’t get the dedicated pool’s Connections metric.
   • Quick test: call the Metric Definitions API in your Function and log the list of metric names to see if “Connections” actually shows up.
2. Check your API version / SDK version
   • The Azure Monitor REST API version you use can change which metrics are exposed. Locally you might have v1.0.0 of the Python SDK (or an explicit api_version=2018-01-01) but your Function App’s deployed package could be on an older library that defaults to v2017.
   • Make sure in your Function you either specify api_version=2018-01-01 (or later) when you call metrics.list() or upgrade your azure-mgmt-monitor package to the same version you have locally.
3. Confirm your Function App’s outbound networking + identity
   • If your Function is in a VNet with restricted NSGs or Service Endpoints, it might not be able to reach the Azure Monitor endpoint correctly and you’ll get back empty / “n/a” values.
   • Also check that the identity you’re using in Azure (Managed Identity or Service Principal) has at least Monitoring Reader on that SQL Pool resource. A permissions issue sometimes surfaces as empty payloads rather than 403 errors, depending on how you catch exceptions.
4. Capture the raw HTTP response
   • Add a little debug around your HTTP call (or SDK call) that dumps the full JSON response from /metrics. That will tell you definitively whether the Connections metric “exists” but just has no data, or if the service didn’t even list it.

Hope this helps!

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.