Building a Power BI Semantic Model from Azure Log Analytics

Most Australian businesses running anything serious on Azure are sitting on a pile of operational data they've paid to collect and then never really use. It's in Log Analytics - application traces, performance counters, sign-in logs, request telemetry, custom events your developers thoughtfully instrumented and then forgot about. The data is there, it's detailed, and the only people who ever touch it are engineers writing one-off KQL queries during an incident. The moment the incident is over, it goes back to being an expensive write-only store.

Connecting Log Analytics to a Power BI semantic model is how that changes. Instead of the data being reachable only by someone fluent in Kusto Query Language during a fire, you build a proper model on top of it and put the answers in front of the people who actually need them - on a dashboard, refreshed on a schedule, in language a business audience understands. The create a semantic model from Log Analytics capability is the bridge, and it's one of those integrations that sounds niche until you realise how much value is trapped on the other side of it.

Why this is worth doing

Log Analytics is brilliant at what it's for: storing huge volumes of operational telemetry and letting engineers query it fast with KQL. What it's not is a place non-technical people go to answer questions. Nobody in operations, finance or the leadership team is going to open Log Analytics and write a Kusto query to find out how the platform performed last month. So all that data, however rich, only ever serves the handful of people who speak KQL, and only when they specifically go looking.

Power BI flips that. Once the operational data lives in a semantic model, the whole business can build reports on it without touching a query. A support manager can watch error rates trend over the week. An account team can see the usage patterns of a specific customer. Leadership can get platform health on the same dashboard as everything else they look at, refreshed automatically, in plain terms. The technical data becomes a business asset instead of an engineering-only tool.

We've seen this land hardest in a few specific spots. Application performance and reliability reporting, where you want error rates, response times and availability trended over time and visible to people who'll never open Azure Monitor. Usage and adoption analytics, turning raw request and event logs into a picture of who's using what and how much. And security and audit reporting, where sign-in and audit logs become something a compliance person can actually read rather than something only the security team can extract. In every case the pattern is identical: valuable data that was locked behind KQL becomes something the wider organisation can self-serve.

How the connection works, and the one thing to get right early

The mechanism is a connector. Power BI connects to your Log Analytics workspace, you provide a KQL query that shapes and returns the data you want, and that result feeds the semantic model. So the engineering skill doesn't disappear - it moves. Somebody still writes the Kusto, but they write it once, well, at the point of building the model, and from then on everyone downstream consumes the result without needing to know Kusto exists. You're not eliminating the query, you're doing it properly one time so that dozens of people don't each have to.

That shifts where the real work sits, and it's worth being clear-eyed about it. The value and the difficulty are both in the query design, not the clicking. A well-built model on Log Analytics comes from a well-built KQL query that returns clean, appropriately shaped, appropriately aggregated data. A bad model comes from a query that drags back raw, unaggregated logs and hopes Power BI sorts it out. It won't. If you take one thing from this, take that: the quality of the whole thing is decided by the query, so spend your effort there.

The honest cautions, because this one has sharp edges

I'm genuinely enthusiastic about this integration, but it has more traps than most, and they all come back to one thing: Log Analytics can hold an enormous amount of data, and Power BI is not the tool for hauling all of it around.

Volume will hurt you if you let it. This is the mistake everyone makes first. They point Power BI at the raw logs and try to pull everything, and either the query times out, the refresh crawls, or they blow past limits and the whole thing falls over. Log Analytics can hold billions of records. You do not query billions of records into a Power BI model. You aggregate in KQL first - summarise to the grain you actually need, roll up to hourly or daily buckets, filter to the relevant time window - and pull back a sane, pre-summarised result. Do the heavy lifting in Kusto where it belongs, and let Power BI receive something already shaped for reporting. Almost every performance problem people hit with this comes from ignoring that and trying to make Power BI do work that should have happened in the query.

Data retention is a real constraint. Log Analytics ages data out based on your retention settings. If your workspace only keeps 30 or 90 days, that's the horizon of what you can report on, full stop. For operational dashboards showing recent health, that's usually fine. For any kind of long-term trending or year-on-year comparison, you either extend retention, which costs money, or you build a pipeline that snapshots the aggregated data into somewhere more permanent on a schedule. Decide which of those you need before you promise anyone a twelve-month trend, because the data simply won't be there otherwise.

Refresh and cost move together. Every scheduled refresh runs your KQL query against the workspace, and Log Analytics queries have cost and performance implications, particularly on large volumes. A heavy query refreshing every fifteen minutes is a bill and a load you want to notice before it surprises you, not after. Match the refresh frequency to how fresh the data genuinely needs to be. Most operational reporting is perfectly happy on hourly or daily refreshes, and that keeps both the cost and the query load sensible.

The through-line on all three is the same principle: aggregate early, pull back little, refresh sensibly. Get that right and this is a clean, reliable integration. Get it wrong and it's slow, expensive and fragile. It's not a difficult integration, but it is an unforgiving one if you treat Power BI like it can swallow raw logs.

How I'd build it

Start from the question, not the data. Work out what the dashboard actually needs to answer - error rate by day, top endpoints by volume, sign-ins by location, whatever it is - and write the KQL to return exactly that, aggregated to the right grain, and nothing more. Resist the instinct to pull extra columns "in case they're useful later". Every extra field is more data moving and more model to maintain, and the useful-later stuff rarely gets used. Build narrow and extend when there's a real reason.

Get the KQL genuinely right before you touch Power BI. Tune the query in Log Analytics directly - check it's fast, check the volume it returns is reasonable, check the aggregation is at the grain you want - and only then wire it into the model. Debugging a slow refresh is far nastier than debugging a slow query in the place the query lives. Sort it out at the source.

And think about where this lives in your wider setup. Operational telemetry in Power BI is often most powerful sitting alongside your business data - platform health next to the business metrics it affects, usage data next to revenue. That combination is where the interesting questions get answered, and it's the kind of thing our Power BI consultants and Azure AI consulting practice put together for clients who want their operational and business data telling one coherent story instead of living in separate worlds.

The bigger picture is that a lot of Australian businesses are already paying to collect operational data they barely use, and turning it into something the whole organisation can see is one of the higher-return, lower-effort wins available in a mature Azure setup. The data's already there. You've already bought it. Getting it in front of the right people is mostly a matter of doing the query well and refreshing it sensibly. If you've got a Log Analytics workspace quietly filling up with data nobody outside engineering ever sees, have a chat with us about putting it to work.