Yes. The Azure Monitor collector connects to the Azure Monitor Metrics API and discovers your Azure resources automatically across subscriptions — VMs, SQL databases, load balancers, AKS clusters, storage accounts, and 30+ other services. Netdata Agents on your Azure Local cluster nodes collect OS-level metrics, Hyper-V VM performance, Storage Spaces Direct health, and application metrics. Both data sources land in the same Netdata Cloud dashboard on the same timeline.

Host OS metrics at per-second granularity (CPU per core, memory pressure, disk I/O and latency per device, network throughput per interface), Hyper-V virtual machine performance (per-VM CPU, memory, disk, network), Storage Spaces Direct health, capacity, and performance, and any applications running on guest workloads through 800+ collector integrations. Every metric gets ML-based anomaly detection automatically.

Unified visibility across source and destination is exactly the thing teams need most during cutover. Netdata puts the same workload on Azure and on Azure Local side by side — same metrics, same timeline, same alerting — so you can compare SQL throughput, response times, disk I/O directly. Per-second granularity means you spot issues during the cutover window, not after. If something goes wrong, you have the data to decide quickly whether to roll back or push forward.

Netdata Agents typically run at under 1% CPU per node and 150-200 MB RAM. The agent does collection, storage, and ML training locally — independently validated as the most energy-efficient monitoring solution (University of Amsterdam ICSOC 2023). On Azure Local hardware that’s sized for production workloads, this means monitoring doesn’t compete with your VMs for resources.

No. The setup you used during migration becomes your ongoing monitoring for the Azure Local environment. The agents are already installed on cluster nodes, dashboards are already built, alerts are already configured. For workloads that remain in Azure (or for hybrid architectures), the Azure Monitor collector keeps running. Migration tool and production tool are the same tool.

The Azure Monitor collector supports multi-subscription discovery in a single collector job — common in enterprise setups where production, staging, and shared services live in separate subscriptions. You can scope discovery as broad or narrow as needed: monitor an entire tenant, or filter by subscription, resource group, region, or tags. Custom Azure Resource Graph KQL queries are supported for fine-grained control.

Yes, and that’s the typical setup during migration. The same Netdata collector — for SQL Server, IIS, Active Directory, containers, or any of 800+ integrations — runs against the cloud instance and against the on-prem instance. Both appear in Netdata Cloud with consistent metric names and dashboards, which makes direct comparison straightforward.

Yes. Metrics, logs and traces stay on your infrastructure. Netdata Cloud receives metadata (node names, chart titles, alert configurations) for unified dashboards but does not store the actual observability data. Queries are distributed to Agents and Parents in real time. For air-gapped Azure Local deployments, Netdata Cloud On-Premises is available as a Kubernetes deployment on your own cluster.

Predictable per-node pricing for infrastructure monitoring. Azure cloud VMs and Azure Local cluster nodes are billed on the same per-node basis. One Kubernetes node equals one billable node, with no per-pod charges. No charges for metrics volume, Logs Monitoring (querying logs in place), users, data retention or containers — Azure Local environments generate a lot of telemetry across cluster nodes, VMs, storage, and applications, and the bill doesn’t grow with that metric volume. See pricing for current plan details.

Azure Local is the current name for what Microsoft previously called Azure Stack HCI. The underlying technology and Netdata coverage are the same. If you’re running Azure Stack HCI today, the Netdata setup described here applies as-is — Hyper-V monitoring, Storage Spaces Direct monitoring, host OS metrics, and application collectors all work identically.

First operational dashboard takes about 60 seconds — install the agent on a node, point the Azure Monitor collector at a subscription, and you have data. For a production-ready deployment across an Azure Local cluster plus a meaningful slice of Azure resources, plan a few days for agent rollout, dashboard customization, and alert tuning. Considerably faster than spinning up parallel monitoring stacks for cloud and on-prem separately.

Get in touch if you’re planning or executing an Azure to Azure Local migration — we’re working with several organizations going through this transition and can share what’s worked well. Or start a free trial and install the agent on a single Azure Local node to see the dashboards before committing.