OneLake Diagnostics in Microsoft Fabric: Who Accessed What, When, and How
Learn how OneLake diagnostics gives end-to-end visibility into data access across Microsoft Fabric — setup, event schema, immutable logs, and best practices.
A practical guide to OneLake diagnostics: what it logs, how to enable it, the event schema, immutability for tamper-proof audit trails, and the limitations to plan around.
OneLake diagnostics gives Microsoft Fabric administrators end-to-end visibility into data access across a workspace — answering the question every governance and security team eventually asks: who accessed what, when, and how? When enabled, it streams data access events as JSON logs into a designated lakehouse in the same capacity, covering everything from clicks in the Fabric UI to programmatic access via APIs, pipelines, and shortcuts.
What OneLake Diagnostics Monitors
Coverage spans every access path into OneLake data, not just the Fabric web experience:
For Fabric workload access (e.g. an engine reading a lakehouse), OneLake records that temporary access was granted — the engine's own logs provide the operation-level detail.
↑ back to topPrerequisites & Setup
- Create a lakehouse to store diagnostic events — it must sit in the same capacity as the workspaces being monitored (same virtual network too, if private links are in use).
- You need workspace admin on the monitored workspace and contributor on the target lakehouse.
- In workspace settings, open OneLake settings and toggle Add diagnostic events to a lakehouse to On, then select the target lakehouse.
Switching the target lakehouse later is non-destructive — use Replace lakehouse and the previous events simply stay put in the original one. Disabling the toggle keeps your settings so re-enabling picks up where you left off.
↑ back to topThe Diagnostic Event Schema
Events land as JSON under a predictable, hour-partitioned path:
| Property | What it tells you |
|---|---|
| operationName / operationCategory | The OneLake operation and whether it's a Read, Write, or Delete |
| executingPrincipalId / executingUPN | Who performed the operation (user or service principal) |
| Resource / itemId / itemType | What was accessed, relative to the workspace |
| accessStartTime / accessEndTime | When the operation happened (or when temp access was granted/ended) |
| isShortcut / accessedViaResource | How the data was reached — directly or via a shortcut |
| callerIPAddress | Caller IP (can be redacted tenant-wide) |
executingUPN and callerIpAddress from every event.Immutable Logs for Tamper-Proof Audit Trails
Diagnostic events can be made immutable (WORM — write once, read many) using Azure Blob Storage immutability, configured with a retention period in workspace settings.
| Cleanup pattern | How it works |
|---|---|
| Path-based age check | Use the y=/m=/d=/h= folder path to compute file age and delete anything past retention |
| Check immutability expiry | Call Get Blob Properties, read x-ms-immutability-policy-until-date, skip files not yet expired |
| Tolerant retry | Catch HTTP 409 (BlobImmutableDueToPolicy), log it, and retry on the next scheduled run |
A scheduled Fabric notebook, a data pipeline (Get Metadata + Delete), or a custom job against the OneLake/ADLS Gen2 APIs all work for this cleanup.
↑ back to topLimitations to Plan Around
- Workspace Outbound Access Protection (OAP): not compatible across workspaces — the workaround is to select a lakehouse in the same workspace.
- Private links: lakehouse selection honors your private-link configuration, but diagnostics won't automatically adjust if networking changes later — re-check the setting after any network change.
- Capacity moves: moving a workspace to a different capacity disables diagnostics; you'll need to re-enable and pick a lakehouse in the new capacity.
Leave a comments