mirror of
https://github.com/prometheus-community/windows_exporter.git
synced 2026-10-17 18:19:04 +02:00
Jan-Otto Kröpke
d819362150
Every optional collector of the mixin now has alerts, generated only with that collector enabled in _config.collectors: clock source, disk drive status, page file usage, license status, scheduled task results, pending updates, Hyper-V WMI and replication health, failover cluster nodes, resources, groups and shared volumes, Storage Spaces pool and virtual disk health, DHCP scope exhaustion and DNS zone transfer failures. The alerts of the pagefile, diskdrive and license collectors join the memory, disk and system groups; the other collectors get a group of their own. New knobs: taskSelector, sharedVolumeSelector, pagefileUsageThreshold, dhcpScopeFreeWarningThreshold, dhcpScopeFreeCriticalThreshold and updatePendingDuration. The test configuration enables every optional collector and tests/optional.test.yaml covers the new alerts. Signed-off-by: Jan-Otto Kröpke <mail@jkroepke.de>
44 lines
1.8 KiB
Markdown
44 lines
1.8 KiB
Markdown
---
|
|
title: WindowsHyperVReplicationWarning
|
|
---
|
|
|
|
## Meaning
|
|
|
|
Hyper-V Replica reports warning health for the virtual machine `vm` for 15
|
|
minutes. Warning health means that some replication cycles missed their
|
|
interval, that more than a fifth of the cycles in the last hour failed, or
|
|
that the replication is waiting for an initial copy or a resynchronization.
|
|
The alert carries the `relationship` label and needs the `hyperv` collector
|
|
with its `replica_vm` subcollector. [WindowsHyperVReplicationCritical](../windowshypervreplicationcritical/)
|
|
follows when replication stops working.
|
|
|
|
## Impact
|
|
|
|
The replica lags behind the primary more than planned. The recovery point
|
|
objective is at risk, and a failover would lose more changes than expected.
|
|
|
|
## Diagnosis
|
|
|
|
1. Inspect `windows_hyperv_replica_vm_health`, `windows_hyperv_replica_vm_state`
|
|
and `windows_hyperv_replica_vm_replication_latency_seconds` for the
|
|
virtual machine, and `windows_hyperv_replica_vm_average_replication_size_bytes`
|
|
to see whether the change rate of the virtual machine has grown.
|
|
2. On the primary host, read the statistics of the last hour:
|
|
|
|
```powershell
|
|
Measure-VMReplication -VMName '<vm>' | Format-List *
|
|
Get-VMReplication -VMName '<vm>' | Format-List State, Health, LastReplicationTime, FrequencySec
|
|
```
|
|
|
|
3. Check the bandwidth between the hosts, the load on the replica storage,
|
|
and whether the replication interval is too short for the change rate of
|
|
the virtual machine.
|
|
|
|
## Mitigation
|
|
|
|
Relieve the bottleneck: more bandwidth, less load on the replica storage, or a
|
|
longer replication interval through `Set-VMReplication -ReplicationFrequencySec`.
|
|
Resume a waiting replication with `Resume-VMReplication`. Reset the statistics
|
|
with `Reset-VMReplicationStatistics` after the fix; the health is computed
|
|
over the last hour and takes up to an hour to return to normal.
|