Regenerate integrations docs (#21453)
Co-authored-by: ilyam8 <22274335+ilyam8@users.noreply.github.com>
Netdata bot committed
Dec 11, 2025 at 21:16 UTC
592a6e5e04fe93d19c75871e05a3869a961b4bc1
4 files changed
+107
-3
src/collectors/ebpf.plugin/integrations/ebpf_oomkill.md
+3
-3
@@ -160,14 +160,14 @@ There are no configuration examples.
160
161
### update every
162
163
-
163
+Data collection frequency.
164
165
### ebpf load mode
166
167
-
167
+Define whether plugin will monitor the call (`entry`) for the functions or it will also monitor the return (`return`).
168
169
### lifetime
170
171
-
171
+Set default lifetime for thread when enabled by cloud.
172
173
src/collectors/freeipmi.plugin/integrations/intelligent_platform_management_interface_ipmi.md
+35
@@ -273,10 +273,45 @@ ID | Name | Type | State | Reading | Unit
273
274
### Debug Mode
275
276
+You can run `freeipmi.plugin` with the debug option enabled, to troubleshoot issues with it. The output should give you clues as to why the collector isn't working.
277
+
278
+- Navigate to the `plugins.d` directory, usually at `/usr/libexec/netdata/plugins.d/`. If that's not the case on your system, open `netdata.conf` and look for the `plugins` setting under `[directories]`.
279
+
280
+ ```bash
281
+ cd /usr/libexec/netdata/plugins.d/
282
+ ```
283
+
284
+- Switch to the `netdata` user.
285
+
286
+ ```bash
287
+ sudo -u netdata -s
288
+ ```
289
+
290
+- Run the `freeipmi.plugin` in debug mode:
291
+
292
+ ```bash
293
+ ./freeipmi.plugin 5 debug
294
+ ```
295
296
297
### kimpi0 CPU usage
298
299
+There have been reports that kipmi is showing increased CPU when the IPMI is queried. To lower the CPU consumption of the system you can issue this command:
300
+
301
+```sh
302
+echo 10 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us
303
+```
304
+
305
+You can also permanently set the above setting by creating the file `/etc/modprobe.d/ipmi.conf` with this content:
306
+
307
+```sh
308
+# prevent kipmi from consuming 100% CPU
309
+options ipmi_si kipmid_max_busy_us=10
310
+```
311
+
312
+This instructs the kernel IPMI module to pause for a tick between checking IPMI. Querying IPMI will be a lot slower now (e.g. several seconds for IPMI to respond), but `kipmi` will not use any noticeable CPU.
313
+
314
+You can also use a higher number (this is the number of microseconds to poll IPMI for a response, before waiting for a tick).
315
316
317
src/collectors/perf.plugin/integrations/cpu_performance.md
+19
@@ -194,6 +194,25 @@ Monitor CPU cycles.
194
195
### Debug Mode
196
197
+You can run `perf.plugin` with the debug option enabled to troubleshoot issues with it. The output should give you clues as to why the collector isn't working.
198
+
199
+- Navigate to the `plugins.d` directory, usually at `/usr/libexec/netdata/plugins.d/`. If that's not the case on your system, open `netdata.conf` and look for the `plugins` setting under `[directories]`.
200
+
201
+ ```bash
202
+ cd /usr/libexec/netdata/plugins.d/
203
+ ```
204
+
205
+- Switch to the `netdata` user.
206
+
207
+ ```bash
208
+ sudo -u netdata -s
209
+ ```
210
+
211
+- Run the `perf.plugin` in debug mode:
212
+
213
+ ```bash
214
+ ./perf.plugin 1 all debug
215
+ ```
216
217
218
src/go/plugin/go.d/collector/snmp/integrations/snmp_devices.md
+50
@@ -404,4 +404,54 @@ If your Netdata runs in a Docker container named "netdata" (replace if different
404
docker logs netdata 2>&1 | grep snmp
405
```
406
407
+### Debugging Gaps on Charts
408
+
409
+If your SNMP charts show gaps, it means the collector could not finish metric collection before the next scheduled run. This usually happens when SNMP tables take longer to collect than your configured `update_every`.
410
+
411
+These gaps do *not* mean the device stopped exporting SNMP metrics — only that the collector had to skip cycles.
412
+
413
+**Step 1: Check the Logs**
414
+
415
+[Look for messages](#getting-logs) like:
416
+
417
+```text
418
+level=warn msg="skipping data collection: previous run is still in progress for 4s (skipped 4 times in a row, interval 1s)" collector=snmp job=your_device
419
+level=info msg="data collection resumed after 4.36s (skipped 4 times)" collector=snmp job=your_device
420
+```
421
+
422
+The “resumed after” message shows how long the previous collection actually took.
423
+For example, if a run needs ~4.4 seconds and `update_every` is 1 second, 4 cycles will be skipped.
424
+
425
+
426
+**Step 2: Check Collection Timings**
427
+
428
+Open **SNMP → Internal → Stats** in the dashboard.
429
+The **SNMP profile collection timings** chart shows how long each part of the SNMP polling takes.
430
+Table metrics are usually the slowest and often determine the total collection time.
431
+
432
+**Step 3: Increase the data collection interval**
433
+
434
+[Set `update_every`](#setup) to a value **higher than your slowest collection time**, with some extra buffer for network variability.
435
+
436
+| Typical Collection Time | Recommended `update_every` |
437
+|-------------------------|-----------------------------|
438
+| < 2 seconds | 2 seconds |
439
+| 2–5 seconds | 5 seconds |
440
+| 5–10 seconds | 10 seconds |
441
+| > 10 seconds | collection_time × 2 |
442
+
443
+:::info
444
+
445
+- **Rule of thumb:** `update_every` should be at least 2× your slowest table collection time.
446
+- The default `update_every: 10` works well in most environments.
447
+- Only reduce it if your device consistently responds fast enough.
448
+
449
+:::
450
+
451
+**Quick Checklist**
452
+1. Do logs show “skipping data collection”?
453
+2. Does *Internal → Stats* show collection time > `update_every`?
454
+3. Increase `update_every` until skips disappear.
455
+
456
+
457