mirror of
https://github.com/prometheus-community/windows_exporter.git
synced 2026-10-17 10:09:05 +02:00
The alerts of the mixin now come in one rule group per collector area (windows-exporter, windows-cpu, windows-memory, windows-disk, windows-network, windows-service, windows-system, windows-active-directory, windows-time). Every alert names the collectors it reads and is generated only when _config.collectors enables them, the same switch the dashboard uses; enableActiveDirectory and enableTime set collectors.ad and collectors.time. _config.alerts switches single alerts off by name, and an unknown name fails the build. New alerts for the default collectors: WindowsCollectorTimeout, WindowsScrapeQueueTimeout, WindowsCPUSaturation (processor queue per core), WindowsMemoryPagingHigh, WindowsNetworkUtilizationHigh, WindowsNetworkInterfaceFlapping, WindowsServiceNotRunning (automatic services without triggers), WindowsServiceCrashLooping (processes per service in 15 minutes) and WindowsHostRebooted (info, fires once per reboot). WindowsNetworkErrors and WindowsNetworkDiscards compare the error and discard rates with the packet rate (networkErrorRatioThreshold and networkDiscardRatioThreshold, in percent) instead of an absolute packet rate. Threshold alerts set keep_firing_for from keepFiringFor (5m); the new infoSeverity and serviceSelector knobs follow the existing ones. New recordings: windows:cpu_queue_per_core:ratio, windows:net_received_packets:rate and windows:net_sent_packets:rate. Each new alert has a runbook, a README row and a unit test; tests/alerts.test.jsonnet checks the collector gating, the alert switches and the group layout. The runbook check renders the alerts of every collector. contrib/mixin/AGENTS.md documents the checklist for new alerts. Signed-off-by: Jan-Otto Kröpke <mail@jkroepke.de>
36 lines
1.4 KiB
Markdown
36 lines
1.4 KiB
Markdown
---
|
|
title: WindowsNetworkInterfaceFlapping
|
|
---
|
|
|
|
## Meaning
|
|
|
|
The operational status of the interface `nic` changed more than twice within
|
|
the rate window, and did so for two minutes. The alert counts the changes of
|
|
`windows_net_nic_operation_status{status="up"}` between `1` and `0`.
|
|
|
|
## Impact
|
|
|
|
Every transition drops the connections that use the interface and triggers
|
|
route, DHCP and DNS registration changes. A flapping uplink on a server causes
|
|
intermittent application failures that are hard to attribute.
|
|
|
|
## Diagnosis
|
|
|
|
1. Inspect `windows_net_nic_operation_status` for the interface to see the
|
|
status it flips to; `down` and `lower layer down` point at the link,
|
|
`dormant` at authentication such as 802.1X.
|
|
2. Check the System event log for NDIS, the adapter driver and
|
|
`Microsoft-Windows-NetworkProfile` events, and the switch port for link
|
|
state changes, errors and port security actions.
|
|
3. Check the cable, SFP, speed and duplex negotiation, and whether a teaming or
|
|
failover configuration switches between members.
|
|
4. On virtual machines, check the hypervisor for virtual switch changes, live
|
|
migrations, or a host adapter that flaps.
|
|
|
|
## Mitigation
|
|
|
|
Replace the cable or transceiver, fix the speed and duplex settings, update the
|
|
adapter driver, or correct the switch port and authentication configuration.
|
|
Exclude an interface that flaps by design, such as a Wi-Fi or VPN adapter,
|
|
with the `nicSelector`. Confirm the status stays `up`.
|