Blog Post

Fabric Updates Blog
3 MIN READ

Monitor your Eventstreams with Workspace Monitoring — Now with per-Eventstream control (Preview)

Anasheh's avatar
Anasheh
Icon for Microsoft Employee rankMicrosoft Employee
1 month ago

When a real-time data pipeline breaks, the first question is always the same: what went wrong, and where?

Eventstream observability in Microsoft Fabric brings that visibility directly into Workspace Monitoring, so you can track the health, performance, and errors of your eventstreams without leaving the Fabric portal or setting up external monitoring infrastructure.

With this update, eventstream observability returns with a redesigned approach that puts you in control — including a per-eventstream toggle that lets you decide exactly which eventstreams emit monitoring data and which don't.

Why observability matters for real-time pipelines

Real-time data pipelines operate continuously. Unlike batch jobs that run and finish, an eventstream can process data for days or weeks without anyone checking on it. When something goes wrong — a destination write error, or backlogged events — the problem often goes unnoticed until downstream consumers report stale or missing data.

Eventstream observability closes that gap. When enabled, each eventstream emits structured metrics and error data to your workspace's monitoring Eventhouse. This data lands in three dedicated KQL tables that you can query, alert on, and build dashboards against:

Table What it capturesEmission frequencyWhen to use it
EventStreamMetricsThroughput, event counts, ingress and egress rates ~1 minuteCapacity planning, data flow validation, throughput monitoring
EventStreamErrorMetricsError category, error code, severity, affected events~1 minuteTroubleshooting failures, identifying recurring error patterns
EventStreamNodeStatusNode state (running, stopped)~6 hoursHealth checks, topology status overview
 

Once monitoring is enabled for an eventstream, these tables appear in your workspace's monitoring KQL database alongside existing Eventhouse and other workload tables.

 

Figure: Eventstream monitoring tables in the Workspace Monitoring KQL database, showing EventStreamMetrics, EventStreamErrorMetrics, and EventStreamNodeStatus tables available for querying.

What changed: Per-eventstream control 

During the initial preview, eventstream observability was enabled globally for all eventstreams in a workspace. Based on customer feedback, the feature now provides granular control — you choose exactly which eventstreams emit monitoring data, giving you flexibility to focus observability on the pipelines that matter most.

The key changes:

  • Per-eventstream toggle. A new setting — Log Eventstream activity — appears in each eventstream's settings panel. You can enable or disable observability for each eventstream individually, so a workspace with ten eventstreams can monitor only the two or three that are most critical.
  • Default OFF. All eventstreams default to monitoring OFF. You choose which ones to enable. 

How to get started

Eventstream observability requires Workspace Monitoring to be enabled on your workspace. If you haven't set it up yet:

  1. Open your workspace settings.
  2. Navigate to the Monitoring section.
  3. Enable Workspace Monitoring and wait for the monitoring Eventhouse to provision.

Once Workspace Monitoring is active:

  1. Open any eventstream in your workspace.
  2. Select the Settings gear icon.
  3. Find the Log Eventstream activity toggle.
  4. Enable it.

Within a few minutes, data begins flowing into the eventstream tables in your monitoring KQL database. You can query them directly with KQL, build Real-Time Dashboards, or use KQL querysets for deeper analysis.

What comes next

This release covers performance metrics, error metrics, and node health — the foundation for operational observability. Additional capabilities are planned for future updates:

  • Diagnostic logs — Error logs from the ASA processing engine, providing deeper root-cause analysis for failures like deserialization errors, runtime query errors, and output write failures.
  • Expanded connector coverage — Monitoring support for connector-based sources is under investigation and will be added in a future phase.

Next steps

Updated 1 month ago
Version 1.0

1 Comment

  • erinfry6's avatar
    erinfry6
    Regular Visitor

    Hello!

    I'm curious if its possible to set an alert for any failure for an entire workspace? I would like the option for select * !

     

    Thank you,

    Erin