Hello kethom-analytics / Gellért Gintli (@ggintli) ,
We are currently using Fabric Unified Admin Monitoring (FUAM) to monitor our Microsoft Fabric capacity and have noticed that FUAM itself can become a significant CU consumer, in particular the FUAM_Core_SM semantic model.
We have now analyzed the issue using FUAM's own Item Analyzer, Semantic Model Analyzer and Item Outlier Analysis.
Our capacity is an F64, currently containing approximately 56 workspaces and 538 active items. Average utilization of the capacity is relatively moderate:
- 11.92% over the last 14 days
- 13.77% over the last 30 days
- 15.40% over the last 90 days
However, FUAM itself periodically generates substantial CU consumption.
Some examples:
- 24 Aug 2026
- FUAM_Core_SM: 273,193 CUs
- FUAM_Lakehouse: 27,380 CUs
- 01_Transfer_CapacityMetricData_Timepoints_Unit: 23,874 CUs
- FUAM_Gateway_Monitoring_From_Files_SM: 21,426 CUs
- 02_Transfer_CapacityMetricData_ItemKind_Unit: 20,118 CUs
- FUAM Core Report - Customized: 19,311 CUs
- 03_Transfer_CapacityMetricData_ItemOperation_Unit: 17,905 CUs
On this day, FUAM reported a Max TimePoint CU utilization of 145.67% and 4 interactive-delay throttling events.
- 26 Aug 2026
- FUAM_Core_SM: 202,634 CUs
- FUAM_Lakehouse: 51,497 CUs
- 01_Transfer_CapacityMetricData_Timepoints_Unit: 25,385 CUs
- 02_Transfer_CapacityMetricData_ItemKind_Unit: 21,028 CUs
- 03_Transfer_CapacityMetricData_ItemOperation_Unit: 18,307 CUs
The FUAM Item Analyzer also shows that the main CU driver for FUAM_Core_SM is querying rather than refresh activity.
For the analyzed period, the semantic model consumed approximately 6.24 million CUs, distributed roughly as follows:
- Query: 4.38M CUs (~70%)
- Dataset Scheduled Refresh: 1.32M CUs (~21%)
- XMLA Read Operation: 542k CUs (~9%)
The activity statistics also show:
- 250 ConnectFromExternalApplication activities in the last 30 days
- only 2 users generating these item activities
- significant activity peaks, e.g. 105 external connection activities on one day
- more than 200 ViewReport activities against the FUAM Core Report
One factor in our environment is that the FUAM report has sometimes been kept open continuously on a shared monitoring screen using an AutoLogon account. We suspect that this may result in repeated queries against FUAM_Core_SM and contribute significantly to the CU consumption.
We are already using relatively conservative/default pipeline parameters:
- metric_days_in_scope = 2
- activity_days_in_scope = 2
- display_data = false
The main FUAM pipeline runs twice daily, while the Capacity Metrics pipeline runs every four hours.
Could you please advise on the following?
- Is this level of CU consumption for FUAM_Core_SM expected for an F64 environment of this size?
- Is it expected that Query operations account for approximately 70% of the semantic model CU usage?
- Is keeping the FUAM report continuously open on a monitoring/shared screen supported or recommended?
- Does the FUAM report perform any automatic polling, page refresh, visual refresh or reconnect behavior that could generate repeated queries while the report remains open?
- Are there particular FUAM report pages or visuals known to be more CU-intensive?
- Are there recommended settings to reduce the CU footprint of FUAM_Core_SM?
- Can the Load_Capacity_Metrics_E2E frequency safely be reduced from every four hours?
- Are there recommendations regarding the frequency of Load_FUAM_Data_E2E?
- Would you recommend hosting FUAM and/or the Fabric Capacity Metrics solution on a separate capacity from the workloads being monitored?
- Are there any specific recommendations for environments where FUAM is used primarily for operational monitoring rather than continuous interactive analysis?
- Are the Best Practice Analyzer findings against the delivered FUAM_Core_SM semantic model expected, or are semantic-model optimizations planned for future FUAM releases?
FUAM is very useful for us, but we would like to ensure that the monitoring solution itself does not create unnecessary capacity pressure or contribute to throttling of the workloads it is intended to monitor.
Any optimization guidance or recommended production configuration would be greatly appreciated.
PS.
PFA exported data from FUAM report related to FUAM items:
FUAM_Item_Analyzer_Report.pdf
FUAM_Semantic_Model_Analyzer.pdf
FUAM_Core_Report - Item Outlier Analysis - Aug 26th.pdf
FUAM_Core_Report - Item Outlier Analysis - Aug 24th.pdf
Best regards,
Jakub
Hello kethom-analytics / Gellért Gintli (@ggintli) ,
We are currently using Fabric Unified Admin Monitoring (FUAM) to monitor our Microsoft Fabric capacity and have noticed that FUAM itself can become a significant CU consumer, in particular the FUAM_Core_SM semantic model.
We have now analyzed the issue using FUAM's own Item Analyzer, Semantic Model Analyzer and Item Outlier Analysis.
Our capacity is an F64, currently containing approximately 56 workspaces and 538 active items. Average utilization of the capacity is relatively moderate:
However, FUAM itself periodically generates substantial CU consumption.
Some examples:
- 24 Aug 2026
On this day, FUAM reported a Max TimePoint CU utilization of 145.67% and 4 interactive-delay throttling events.
- 26 Aug 2026
The FUAM Item Analyzer also shows that the main CU driver for FUAM_Core_SM is querying rather than refresh activity.
For the analyzed period, the semantic model consumed approximately 6.24 million CUs, distributed roughly as follows:
The activity statistics also show:
One factor in our environment is that the FUAM report has sometimes been kept open continuously on a shared monitoring screen using an AutoLogon account. We suspect that this may result in repeated queries against FUAM_Core_SM and contribute significantly to the CU consumption.
We are already using relatively conservative/default pipeline parameters:
The main FUAM pipeline runs twice daily, while the Capacity Metrics pipeline runs every four hours.
Could you please advise on the following?
FUAM is very useful for us, but we would like to ensure that the monitoring solution itself does not create unnecessary capacity pressure or contribute to throttling of the workloads it is intended to monitor.
Any optimization guidance or recommended production configuration would be greatly appreciated.
PS.
PFA exported data from FUAM report related to FUAM items:
FUAM_Item_Analyzer_Report.pdf
FUAM_Semantic_Model_Analyzer.pdf
FUAM_Core_Report - Item Outlier Analysis - Aug 26th.pdf
FUAM_Core_Report - Item Outlier Analysis - Aug 24th.pdf
Best regards,
Jakub