Skip to content

configs.monitoring: OOMKill ignores data gaps - #112

Merged
lassulus merged 1 commit into
masterfrom
oomkill-gap
Oct 19, 2026
Merged

lassulus merged 1 commit into
masterfrom
oomkill-gap

Conversation

@lassulus

Copy link
Copy Markdown
Owner

After styx was without power, its VictoriaMetrics had a gap and increase() returned the whole OOM counter of coaxmetal (5), firing OOMKill. Guard with present_over_time before the window; same for NvmeMediaErrors. Tested with vmalert-tool unittest and live against styx's data.

When VictoriaMetrics has no sample shortly before the increase() window
(the monitoring server was down, or the series is new), MetricsQL's
increase() treats the first sample in the window as an increase from 0 and
returns the whole counter. After styx lost power for ~9 minutes, OOMKill
fired for coaxmetal with all 5 OOM kills since its boot 49 days ago,
although the counter never moved.

Only alert when the series has a sample in the minute before the window
(two minutes for the 60s smartctl scrape). Then increase() has a real
previous value, and still handles counter resets on a monitored host's
reboot. increase_pure() does not help: it assumes counters start at 0
and so counts the whole value as well.

NvmeMediaErrors uses increase() on a counter the same way and would
fire for any drive with past media errors after a gap, so it gets the
same guard. MemoryPressure's rate() is not affected: rate() does not
count the first sample in the window as an increase.
@lassulus
lassulus enabled auto-merge (rebase) October 19, 2026 17:23
@lassulus
lassulus merged commit 2de6c64 into master Oct 19, 2026
9 checks passed
@lassulus
lassulus deleted the oomkill-gap branch October 19, 2026 17:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant