Azure SQL DB gets no tempdb monitoring, and the reason recorded for that is not true #2512

Found by running the collector's own SQL against live Azure SQL Database, both service tiers.

The gate

// TempDbStatsCollector.cs:70
public override bool AppliesTo(CollectorTargetInfo target) => !target.IsAzureSqlDb;

Its doc comment explains why:

The second result set (sys.dm_db_session_space_usage, two-part and in-database) WOULD work on Azure SQL DB. Recovering that half needs an Azure-specific query variant rather than a gate … the immediate defect is a collector that can only ever fail

The premise is that the FIRST result set — the three-part tempdb.sys.dm_db_file_space_usage — cannot bind on Azure SQL Database.

It binds, and returns real data

The collector's SQL, verbatim, both result sets, run over an Entra token (2026-08-22):

General Purpose serverless (GP_S_Gen5_2, EngineEdition 5, 12.0.2000.8)

Hyperscale serverless (HS_S_Gen5_2, EngineEdition 5)

SELECT COUNT(*) FROM tempdb.sys.dm_db_file_space_usage returns 4 on both tiers.

So the collector does not "only ever fail" on Azure SQL Database. It works, on both tiers, with no query variant needed.

What this costs today

Every Azure SQL Database target — the whole tier, both GP and Hyperscale — collects no tempdb data at all. No get_tempdb_trend, no tempdb space alerting, nothing in the viewer's tempdb surfaces. On a platform where tempdb contention is a common and consequential problem, and where the customer cannot simply look at the box themselves.

Worse, after #2485 the reads will now explain that absence confidently and wrongly — see #2511.

What to check before flipping the gate

I have verified the SQL binds and returns plausible values. I have not:

• run it through the actual collector pipeline against an Azure target (payload composition, column typing, the RunsPerDatabase interaction);
• checked whether the numbers are meaningful on Azure SQL DB, as opposed to merely returned — tempdb on Azure SQL DB is per-replica and its size is tier-governed, so "unallocated_mb" may not mean what it means on a box. This matters more than the binding: a number that returns but describes something different is worse than a gap, and is precisely the trap this collector's own comment was trying to avoid;
• confirmed behaviour on Managed Instance is unchanged (the gate is IsAzureSqlDb specifically, so MI already collects).

So: flip the gate only after deciding what these figures MEAN on the tier, and say so in the doc comment. If they turn out to be misleading rather than merely available, the right fix is to keep the gate and correct the stated reason, because the current one is checkably false and will invite exactly this issue again.

Related

• On Azure SQL DB, twelve reads tell you to go start a capture that cannot exist there #2511 — the reads mis-explain permanent Azure gaps; this issue is a gap that should not exist in the first place.