A VM-level CPU or memory alert that fires every time the host is busy isn't telling you anything about that specific VM.
A VM pinned at 100% CPU because the host is oversubscribed is a capacity-planning issue; a single VM spiking to 100% while its host has headroom is an application issue. Use different thresholds and routing for each.
On memory-overcommitted hosts, a VM's reported usage can look normal while it's actually being throttled through ballooning or swapping. Where the hypervisor exposes it, alert on balloon/swap activity as its own signal.
If VMs are tagged by team or application, route their resource alerts accordingly. Otherwise every VM alert lands on whoever owns the underlying host, whether or not it's their workload.