Graylog2 / Graylog2/graylog2-server
NodeMetricPeriodical / CpuLoadGauge should honor `disable_native_system_stats_collector`
- Dominant language
- Java
- Stars
- 8.1k
- Forks
- 1.1k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 217
Description
## Summary
Config setting `disable_native_system_stats_collector` is documented as *"Disable the use of a native system stats collector (currently OSHI)"* and routes `SystemStatsModule` to the JMX probe implementations. However, `NodeMetricPeriodical` and its `CpuLoadGauge` are a second, independent OSHI consumer that ignore this flag entirely and always attempt to read CPU load via OSHI native code.
An operator on a `noexec` host who sets `disable_native_system_stats_collector = true` (a legitimate remedy for the OSHI/JNA native-load problem) still gets `CpuLoadGauge` attempting OSHI on the first `update()`, hitting the `LinkageError` guard added in #26608, and logging the "disabling CPU-load metric" warning on every boot for something they explicitly disabled.
## Proposed change
- Inject `Configuration` into `NodeMetricPeriodical` (as `ContentPackLoaderPeriodical` and `LeaderPresenceCheckPeriodical` already do) and, when `isDisableNativeSystemStatsCollector()` is `true`, skip registering the gauge and skip `update()`. The metric is then simply absent, consistent with the rest of the stats subsystem under this flag.
- Once the flag is honored, extend the `CpuLoadGauge` warning to name `disable_native_system_stats_collector = true` as an alternative to `jna.tmpdir`.
## Behavior change / compatibility note
This is a deliberate behavior change for existing flag users: anyone currently running with `disable_native_system_stats_collector = true` still receives the `org.graylog2.system.cpu.percent` metric today (because `CpuLoadGauge` ignores the flag). After this change the metric will be absent for them, which matches the flag's stated intent but should be called out in the changelog.
## Context
- Flag: `BaseConfiguration.java` (`disable_native_system_stats_collector`, default `false`)
- Consumed by: `SystemStatsModule` (OSHI vs JMX probe binding)
- The independent OSHI consumer: `NodeMetricPeriodical` -> `CpuLoadGauge`
- Related: #26608, #26471
Contributor guide
Research direction
Start with NodeMetricPeriodical and CpuLoadGauge, then read the disable_native_system_stats_collector definition in BaseConfiguration and its handling in SystemStatsModule. Done means the flag prevents the gauge from being registered and updated, the CpuLoadGauge warning names the flag as an alternative to jna.tmpdir, and the behavior change is called out in the changelog.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- observability-sre
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100