Function app in Flex consumption plan not showing worker count in Azure portal diagnostic chart

[anandsowm]

For the Function apps that are in Flex Consumption plan , in the Diagnose and solve problems blade, for the 'HTTP functions Scaling' chart is not showing the worker instances count. However, in the corresponding AppInsights resource, for the direct kusto query as below, the instance count is correctly reported.

traces
| summarize dcount(cloud_RoleInstance) by bin(timestamp,30sec)
| render timechart

Region: West US 2

Expected behavior:

The instance count should be shown in the chart under the 'Diagnose and solve problem'

Actual behavior

As seen below, the instance count is not displayed.

[bhagyshricompany]

Hi @anandsowm Thanks for reporting please share the all steps for repro.

[anandsowm]

Here are the steps for repro :

1. Create a function app in Flex Consumption plan, with always ready instance as 1
2. Deploy code for the function app with Http trigger, from Azure pipeline [in my case it is C#, .net8 isolated]
3. Run the JMeter script that calls the Http trigger from multiple threads, duration of test can be 30min - 1hr
4. Open the "HTTP functions scaling" chart from Diagnose and Resolve problems blade in Azure portal
5. Notice that the "Number of workers allotted" trend is not reflecting the real number of worker instances launched during the above test run
6. Open the App Insights resource associated with the function app, execute the kusto query mentioned in the issue, notice that the worker instances launched during the test run is correctly captured in 'traces' table.

[fabiocav]

@nzthiago can you please help triage?

[nzthiago]

@anandsowm - thank you for reporting this. @FinVamp1 FYI to comment, who has been working to update those Diagnose and Resolve detectors to have values for Flex Consumption apps.

We're also working to have the Azure Monitor metric called "Automatic Scaling Instance Count" to be populated in the next few months.

[FinVamp1]

@anandsowm we're working on this and I will update the thread when the work is done.

[cveld]

@FinVamp1 Any news? We are exploring the load testing feature and all three metrics are reporting 0 continuously.

[nzthiago]

@ninallam FYI on the Azure Load Testing - the metrics that show for a Flex Consumption load test need to be updated.

@cveld, @anandsowm the following metrics are the only ones compatible with Flex Consumption, and they're already available (except for CPU Percentage that's still rolling out):

• Automatic Scaling Instance Count - The number of instances on which this app is running. Note that this is emitted every 30 seconds, and given Flex Consumption scales out and in fast the number will be an aggregate of all new instances the app used in this time period. Make sure to change the aggregation to the minimum possible in the graph and the aggregation to "count".
• Memory working set - The current amount of memory used by the app, in MiB. Can be further filtered for each instance of the app.
• Average memory working set - The average amount of memory used by the app, in megabytes (MiB). Can be further filtered for each instance of the app.
• CPU Percentage - The average percentage of CPU being used. Can be further filtered for each instance of the app. (this is currently rolling out and might not be available for apps in all regions yet)
• On Demand Function Execution Count - the number of function executions in on demand instances. This relates to the On Demand Total Executions pricing meter.
• On Demand Function Execution Units - the memory units for on demand instances used by the app, measured in MB-milliseconds. To convert to GB-seconds, divide by 1024000. This relates to the On Demand Execution Time pricing meter.
• Always Ready Function Execution Count - the number of function executions in Always Ready instances instances. This will relate to the Always Ready Total Executions pricing meter.
• Always Ready Function Execution Units - the memory units for always ready instances when active, measured in MB-milliseconds. To convert to GB-seconds, divide by 1024000. This will relate to the Always Ready Execution Time pricing meter.
• Always Ready Units - the memory units for always ready instances assigned to the app, measured in MB-milliseconds. To convert to GB-seconds, divide by 1024000. This relates to the Always Ready Baseline pricing meter.

I hope this helps you review the instance count of the app - we plan to add a version of this to the documentation soon. We also have some planned detector updates which will address the original question about Diagnose and solve problem detectors. Will keep this open until those detectors are updated.