Domain 3 of 3 · Chapter 1 of 3

Monitor Fabric items

Unlock the complete study guide.

Bundled into the existing Implementing Data Engineering Solutions Using Microsoft Fabric premium course — no separate purchase.

14-day money-back guarantee — no questions asked.

Included in this chapter:

  • Four surfaces, chosen by the scope of the question
  • Reading the monitoring hub without over-trusting it
  • Monitoring data ingestion in pipeline runs
  • Gantt view for timing patterns across runs
  • Monitoring a Dataflow Gen2 refresh
  • Detailed dataflow logs and how to handle them
  • Monitoring Spark notebooks and job definitions
  • Spark run series and anomaly detection
  • Monitoring semantic model refresh
  • Capacity Metrics answers saturation, not correctness
  • Workspace monitoring as the queryable layer
  • Configuring alerts: three mechanisms, three reaches
  • Exam patterns and the traps behind them

Choosing the monitoring surface by the scope of the question

Decision factorMonitoring hubItem run viewCapacity Metrics appWorkspace monitoring
Question it answersWhat ran, and how did it end?Why did this one run behave this way?Was the capacity saturated?What is the trend, across many runs?
ScopeEvery permitted item, across workspacesOne item, one executionOne capacity and all items on itOne workspace, all logged items
History it reaches100 recent activities; 30 days per activity via Historical runsItem-specific, such as 50 Dataflow Gen2 refreshes or six monthsLast 14 days30 days of logs and metrics
Access neededPermission to view the itemPermission to view the itemCapacity administratorWorkspace Contributor or higher
Query languageNone, filters and search onlyNone, guided panesNone, report visualsKQL or SQL over the Eventhouse
Explains a functional errorSummary and error details onlyYes, this is where error detail livesNoYes, from logged status and error fields
Can drive an automated alertSchedule failure notifications onlyIn-pipeline Outlook or Teams activityNoYes, via an Activator rule on a KQL queryset

Decision tree

Do you know which run is at fault? Not yet, sweeping Yes, one run More than the last 100 activities? Does the symptom name an error? No, live sweep Yes, 30-day trend Yes, an error No, broad slowness Monitoring hub Status across every item you may view 100 activities, 30 days Workspace monitoring KQL over 30 days of logs and metrics Contributor role needed Item run view Activity Input, Output, error text, run detail Pipeline, Spark, dataflow Capacity Metrics app Capacity units, throttling over the last 14 days Capacity admin only Then make it come to you: alerting Schedule failure notification (scheduled runs) / Outlook or Teams activity (one activity) / Activator rule (any job event) Pick the narrowest surface that covers the scope of the question
Cheat sheet

Cheat sheet

  • The monitoring hub centralizes Fabric job health and outcomes
  • Pipeline activity input and output expose run-specific ingestion details
  • Pipeline Gantt view reveals delays, overlaps, and duration anomalies
  • Workspace monitoring separates pipeline job events from activity runs
  • Historical runs expose the complete 30-day activity history
  • Capacity Metrics identifies ingestion items that drive capacity load
  • Capacity-wide CU and throttling trends distinguish overload from one costly item
  • Dataflow refresh history is bounded by count and age
  • Dataflow table details track staged entities during transformation
  • Dataflow activity statistics quantify destination processing
  • Dataflow workspace status distinguishes refresh failures from validation failures
  • The monitoring hub aggregates Dataflow Gen2 refresh trends
  • Detailed Dataflow logs require controlled handling
  • Spark application details are reachable from item runs and Fabric Monitor
  • The Spark Jobs tab exposes stage and task execution work
  • Spark resource graphs show executor allocation and utilization
  • Spark run series detects anomalous recurring executions
  • Spark application logs separate driver, Livy, and prelaunch diagnostics
  • Item snapshots preserve the code and parameters used by a Spark run
  • Choose the Spark History Server tab that matches the suspected bottleneck
  • A pipeline semantic model refresh defaults to a full refresh
  • Semantic model refresh waits for completion by default
  • Semantic model refresh commit mode controls refresh atomicity
  • Pipeline output tracks orchestrated semantic model refreshes
  • Semantic model operation logs expose refresh processing steps
  • Semantic model refresh history provides attempt-level execution metrics
  • Direct Lake refresh reframes metadata instead of importing all data
  • Schedule failure notifications apply only to scheduled runs
  • Schedule failure alert management requires write access and tenant recipients
  • Activity-level pipeline alerts use dependent messaging activities
  • Activator handles rule-based pipeline event alerts
  • One KQL-triggered Activator rule can cover workspace-wide failures
  • Activator polling must be more frequent than the alert query window

Unlock with Premium — includes all practice exams and the complete study guide.

Also tested in

References

  1. Monitoring hub: View and track Fabric activity
  2. Capacity Metrics app compute page
  3. Workspace monitoring overview
  4. Monitor pipeline runs
  5. View Dataflow Gen2 refresh history and monitoring
  6. Understand Dataflow Gen2 detailed refresh logs
  7. Apache Spark application detail monitoring
  8. What is Spark run series analysis?
  9. Monitor Apache Spark run series
  10. Direct Lake overview
  11. Semantic model refresh activity in Data Factory for Microsoft Fabric
  12. Semantic model operation logs
  13. Monitor Fabric items with item job event logs
  14. Enable workspace monitoring in Microsoft Fabric
  15. Job Scheduler in Microsoft Fabric
  16. Create alerts for pipeline runs