Using Azure Log Analytics with Power BI - A Practical Guide for Australian Premium Tenants

Most Power BI customers I work with reach a point where they want to know what's actually happening inside their reports. Not the activity log version that tells you "Bob opened the sales report at 9.42am", but the deeper picture. Which queries are slow. Which semantic models are getting hammered. Whether that beautiful star schema is being abused by someone writing nested DAX that takes 90 seconds to render.

For Premium tenants, Azure Log Analytics integration is how you get that visibility. It's a feature that's been quietly maturing for a few years now and it doesn't get nearly the attention it deserves. I want to walk through what it does, what it's actually useful for, and the gotchas we've hit setting it up for clients across financial services, retail and government.

Microsoft has a decent overview article covering the basics. Worth reading as a starting point. This post adds what we've learned from doing it in real Australian environments.

What's actually being captured

The Power BI to Log Analytics pipeline exposes events from the Analysis Services engine. So we're talking about query-level telemetry. Things like which DAX queries ran, how long they took, which user triggered them, which tables and measures were touched, whether the query hit the cache.

If you've ever used SQL Server Profiler against an Analysis Services instance, the events will look familiar. That's because they're essentially the same events, just routed into a different storage system. Anyone who's worked with Azure Analysis Services will recognise the schema immediately.

The data shows up in Log Analytics roughly 5 minutes after it's generated. Not real-time. Not 30 seconds. Close to 5 minutes. Plan accordingly if you're trying to build any kind of live dashboard from it. Most of the time you don't need real-time anyway, but worth knowing.

Data ends up in a table called PowerBIDatasetsWorkspace. Notably, it does NOT go to PowerBIDatasetsTenant, even though that table exists. Microsoft made this choice to avoid duplicating telemetry in both places. So all your KQL queries need to target PowerBIDatasetsWorkspace. If you've written queries against the tenant table, they'll come back empty.

What we use it for

In our consulting work we use Power BI Log Analytics for three main things, in order of how often we reach for it.

Finding the slow stuff. When a client says "the report feels slow", that's the start of a conversation, not the end. Log Analytics lets us pull every query that ran against their semantic models, sorted by duration, with the actual DAX text attached. We can see whether the slowness is one massive query, lots of small queries, or a particular user pattern. Without this you're guessing.

Catching abuse. Premium capacity isn't infinite. When a workspace starts running hot, Log Analytics helps you find the cause. Sometimes it's a runaway scheduled refresh. Sometimes it's one Power BI Report Server user pinning every visual to update every 30 seconds. Sometimes it's an Excel analyst using the analyse-in-Excel feature to pull millions of rows. The logs show you who and what without anyone needing to confess.

Validating model changes. When you refactor a semantic model, you want to know whether your changes actually improved things. Capture a baseline of query performance before. Make your changes. Capture an after. The deltas tell you whether the work was worth it. Otherwise you're relying on people's perception of "yeah it feels faster" which is unreliable.

This kind of analysis is bread-and-butter work for our Power BI consulting team, and Log Analytics is one of the tools we lean on heavily for it.

Setup considerations

There's a separate configuration article from Microsoft for the actual steps. The TL;DR is you need a Log Analytics workspace in Azure, you need Premium Power BI workspaces, and you need someone with workspace admin rights to wire them together. Tenant admins set the overall policy. Workspace owners do the per-workspace enable.

A few patterns we use for which workspaces get sent to which Log Analytics destinations.

One workspace, one destination. Useful for high-sensitivity workloads. You isolate the telemetry so only the right people can query it. Common pattern for finance and HR data.

Many workspaces, one destination. Useful when you want to look at platform-wide patterns. Capacity admins love this view because they can write a single query that finds the slowest semantic model across the entire tenant.

Many workspaces, many destinations. Useful when different business units want their own observability. Finance gets finance logs. Sales gets sales logs. Each team can build their own dashboards without seeing each other's data. Bit more setup, but worth it for larger organisations.

We've done all three patterns in production. Choice depends on how your reporting estate is organised and who needs to see what.

The limitations that bite

The official limitations list is worth knowing because some of them are properly annoying.

Only Premium workspaces. If you've got a mix of Premium and Pro, only the Premium side gets logged. Pro workspace activity is invisible to Log Analytics. So if your strategy is "Premium for the big reports, Pro for everything else", you're flying blind on a chunk of your environment.

Only Workspace v2. Anyone still on classic workspaces needs to migrate them first. Not a huge deal in 2026 because most tenants have done this years ago, but I've seen a couple of old setups where this was a surprise.

No paginated report logging. This one catches people out. If you're using paginated reports for invoice generation, regulatory filings or any structured output, Log Analytics doesn't see those at all. You need to fall back to Azure audit logs for that side of things. Annoying inconsistency.

Shared semantic models need to be logged where they live. Say you publish a master semantic model in workspace A and then build reports against it in workspace B. Log Analytics needs to be configured on workspace A (where the model is), not workspace B (where the report is). The reverse seems intuitive but it's wrong. We've seen teams enable logging on the wrong workspace and wonder why nothing showed up.

Web-uploaded CSVs don't log. If someone uploaded a CSV file through the Power BI service and built reports on it, that activity won't appear in Log Analytics. Again, slightly inconsistent but real.

Tenant migration breaks it. If you're moving between tenants (acquisition, demerger, restructure), Azure Log Analytics integration doesn't follow you. You'll need to set it back up after the migration. Plan this into your cut-over checklist.

Sovereign cloud is limited. As of the current docs, sovereign cloud support extends to US DoD and US GCC High. So Australian government customers using a sovereign-flavoured tenant won't have this capability available. Worth checking your tenant's cloud assignment before pitching this internally.

The MFA confusion

There's a specific quirk worth flagging because it's caught me out more than once. If you have Multi-Factor Authentication enforced for Azure but your Power BI tenant doesn't have it, the configuration screens give weird Azure error messages that don't tell you what's wrong.

The fix is dumb but effective. Sign in to the Azure portal first in your browser, complete the MFA challenge, then go to Power BI in the same browser session. The MFA token carries over and the configuration screens work properly. We hit this trying to set up logging for a client and spent 30 minutes thinking something was broken before realising it was just an auth handshake issue.

Private links and the template app

If you've isolated your Log Analytics workspace behind a private endpoint or VNet, the data ingestion itself still works fine. Power BI's service-side connection to your Log Analytics workspace happens over the back-end network and isn't affected.

What breaks is the Log Analytics Template app Microsoft publishes for visualising the data. That app relies on a public endpoint to your Log Analytics workspace. When you've private-linked it, the template app can't reach it.

The workaround is to use the .pbit report template Microsoft publishes on GitHub instead. You open it in Power BI Desktop running on a machine inside your private network, point it at your private-linked Log Analytics workspace, refresh, and republish. Not as plug-and-play as the template app, but it works. We've done this for a few financial services clients where the private link was non-negotiable for security reasons.

Custom DNS mapping needs to be set up so the public-looking endpoint resolves to a private IP. Your network team will know how to handle this if they've done private endpoints before for other Azure services.

What to actually build with the telemetry

Once data is flowing into Log Analytics, what do you do with it? A few patterns we've found useful for clients.

A "slowest queries" dashboard that shows the top 50 longest-running queries in the last 7 days, grouped by semantic model and user. This is the single most useful thing. Whenever someone complains about performance, you start here.

A "capacity hot spots" report that shows query count per hour per workspace. Useful for capacity planning conversations with leadership. You can see when peaks happen and decide whether to upsize, autoscale, or push scheduled refreshes into quieter windows.

A "user behaviour" view that profiles what individual users are running. Not for surveillance, but for finding power users who'd benefit from extra training or analysts who keep building reports that timeout because they don't understand DAX query patterns.

An "abandoned semantic models" report. Anything that hasn't been queried in 90 days probably shouldn't be eating capacity. We use this to drive clean-up conversations with workspace owners.

All of these can be built in Power BI itself, ironically, by connecting back to your Log Analytics workspace with the Azure Data Explorer connector. Bit of a recursive setup but it works really well.

Is it worth turning on

Yes, for any Premium tenant of meaningful size. The setup is straightforward if you've got Azure already in your environment. The data is genuinely useful. The limitations are mostly minor unless you're doing one of the specific things they bite (paginated reports, mixed-cloud, etc).

The conversation we have with clients is usually about whether to set up Log Analytics yourself or have us do it. Either is fine. We tend to do the initial setup and the first round of dashboards as part of a Power BI consulting engagement, then hand it over to internal teams who understand their own usage patterns better than we ever will. The infrastructure is the easy part. Building the right view onto the data takes more knowledge of your business.

Reference: Using Azure Log Analytics in Power BI - Microsoft Learn