Log Analytics Workspace metric "% Used Space" split by computer and instance name shows only the root partition

Your AMA/DCR collection is working—the proof is that every mount point is present in Perf. The workspace's Log Analytics standard metrics view is a metric projection, not a complete rendering of the table, so the missing instances cannot be recovered by changing the chart split.

Create a log-search alert scoped to the workspace instead:

Perf

| where ObjectName == "Logical Disk"

| where CounterName == "% Used Space"

| where InstanceName !in ("_Total", "total")

| summarize UsedPct=max(CounterValue) by Computer, InstanceName, _ResourceId

Set the measurement to UsedPct, choose your threshold (for example, greater than 80), and split by Computer and InstanceName. This evaluates each filesystem independently and identifies the exact VM and mount point in the fired alert. Add an explicit mount-point allow-list, or exclude transient mounts such as /run, if you want alerts only for persistent data disks.

Hello Arnaud de Bossoreille,

The AMA agent and DCR are collecting the data correctly, which is confirmed by the fact that all mount points (/, /mnt, /run, and your custom data disks) are visible in the Perf table. The behavior you're seeing is specific to the Log** Analytics standard **metrics namespace and not an issue with data collection.

The**%**** Used **Space metric exposed in the Metrics blade is generated through a metric projection of selected Perf data rather than a direct representation of everything stored in the Perf table. Due to this limitation, the metric namespace commonly exposes only the root (/) filesystem as an available InstanceName dimension, while additional mount points and custom data disks are not surfaced even though their data exists in Log Analytics.

Since the complete disk utilization data is already available in the Perf table, the recommended approach is to create a Log** Search **Alert against the workspace and evaluate each filesystem independently:

Perf table:

Perf
| where ObjectName == "Logical Disk" and CounterName == "% Used Space"
| summarize AggregatedValue = avg(CounterValue)
    by bin(TimeGenerated, 5m), Computer, InstanceName

When creating the alert rule:

• Scope the rule to your Log** Analytics **Workspace.
• Use the query above as a Custom** Log **Search condition.
• Configure AggregatedValue as the measurement and set the required threshold (for example, >85%).
• Split the alert by Computer and InstanceName so that each VM and mount point is evaluated separately.
• Associate your existing Action** **Group for notifications.

This method provides full visibility and alerting for all collected filesystems, including custom data disks, and avoids the limitations of the Log** Analytics standard **metrics namespace. If required, you can first run the following query to verify the exact object, counter, and instance names available in your environment:

Perf | distinct ObjectName, CounterName, InstanceName

This will ensure the alert targets the correct disk instances and provides per-filesystem monitoring across all mounted volumes.

https://learn.microsoft.com/en-in/azure/azure-monitor/alerts/alerts-metric-logs

https://learn.microsoft.com/en-in/azure/azure-monitor/reference/supported-metrics/microsoft-operationalinsights-workspaces-metrics

Arnaud de Bossoreille I’m following up on my previous comment as I haven’t received a response. Please let me know if you need any additional information or assistance from my side.

Thank you all for this very useful information.

While ingesting it, I linked it to something I don't fully understand how to handle it. Let me elaborate...

I use terraform to set up alerts, I recall I used to have only a azurerm_monitor_metric_alert and saw it "not" working. I fixed it not thanks to documentation I had found, but thanks to browser network inspection on the portal when creating an alert. This is when I realized I had to create a azurerm_monitor_scheduled_query_rules_log as well. To my understanding, the 2 items match what the portal calls "Metric alert rule" and "Log Search alert rule", both being created in one go in the "Alert rules" section.

Side note: the "Log Search alert rule" seems to only be accessible by typing its name in the search box. However, it leads to a constant error "can't access property "toLowerCase", e.opertaor is undefined".

So, back to the point, my log search alert rule was projecting on "Computer" = "*" and "InstanceName" = "/", and my metric alert rule was configured the same.

Thanks to your information, I realized I could project on all instances in the log search, and alert only on selected instances. So this is how I fixed it.

Now, I am very frustrated by not being able to see the log search alert rule in the portal, see error above. I wish somebody able to fix it were reading this message.

I am also very frustrated by not being able to find the KQL query used by metrics described in https://learn.microsoft.com/en-in/azure/azure-monitor/reference/supported-metrics/microsoft-operationalinsights-workspaces-metrics. That would help setting up things manually like described in your answers. Anyway, now I think I don't need to do that.

Arnaud de Bossoreille Thank you for the detailed update, and I'm glad to hear the disk monitoring requirement is now working as expected.

Your implementation of projecting all InstanceName values from the Perf table and then selectively alerting on the required mount points is the recommended approach when full filesystem visibility is needed. Since the data is already available in Log Analytics, this method provides much greater flexibility than relying solely on the %`` ``Used`` ``Space metric exposed through the Log Analytics standard metrics namespace.

Regarding the portal error:

can't access property "toLowerCase", e.operator is undefined

For long-term maintainability, it may be worth reviewing whether the alert rules can be migrated to the current Azure Monitor Scheduled Query Rules model, as Microsoft recommends using the newer Scheduled Query Rules API for log search alerts. Microsoft has also announced retirement of the legacy Log Analytics Alert API.

https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-log-api-switch?tabs=cli

Regarding the KQL behind the %`` ``Used`` ``Space metric, there is currently no customer-accessible query that exposes the internal metric projection logic. The metric is generated by the Azure Monitor platform from collected log data, which explains why the values surfaced in Metrics Explorer do not always match every instance visible in the Perf table.

Ultimately, your current solution using the Perf table as the source of truth is the most flexible and scalable approach for per-filesystem monitoring and alerting, especially when custom mount points and data disks must be monitored independently.

Thank you again for sharing your findings. I'm sure the additional Terraform and alerting details will be valuable for others who encounter a similar scenario.