master
md 637 lines 25.6 KB
Rendered Raw
1 # OS provided metrics (proc.plugin)
2
3 `proc.plugin` gathers metrics from the /proc and /sys folders in Linux systems, along with a few other endpoints, and is responsible for the bulk of the system metrics collected and visualized by Netdata.
4
5 This plugin is not an external plugin, but one of Netdata's threads.
6
7 In detail, it collects metrics from:
8
9 - `/proc/net/dev` (all network interfaces for all their values)
10 - `/proc/diskstats` (all disks for all their values)
11 - `/proc/mdstat` (status of RAID arrays)
12 - `/proc/net/snmp` (total IPv4, TCP and UDP usage)
13 - `/proc/net/snmp6` (total IPv6 usage)
14 - `/proc/net/netstat` (more IPv4 usage)
15 - `/proc/net/wireless` (wireless extension)
16 - `/proc/net/stat/nf_conntrack` (connection tracking performance)
17 - `/proc/net/stat/synproxy` (synproxy performance)
18 - `/proc/net/ip_vs/stats` (IPVS connection statistics)
19 - `/proc/stat` (CPU utilization and attributes)
20 - `/proc/meminfo` (memory information)
21 - `/proc/vmstat` (system performance)
22 - `/proc/net/rpc/nfsd` (NFS server statistics for both v3 and v4 NFS servers)
23 - `/sys/fs/cgroup` (Control Groups - Linux Containers)
24 - `/proc/self/mountinfo` (mount points)
25 - `/proc/interrupts` (total and per core hardware interrupts)
26 - `/proc/softirqs` (total and per core software interrupts)
27 - `/proc/loadavg` (system load and total processes running)
28 - `/proc/pressure/{cpu,memory,io}` (pressure stall information)
29 - `/proc/sys/kernel/random/entropy_avail` (random numbers pool availability - used in cryptography)
30 - `/proc/spl/kstat/zfs/arcstats` (status of ZFS adaptive replacement cache)
31 - `/proc/spl/kstat/zfs/pool/state` (state of ZFS pools)
32 - `/sys/class/power_supply` (power supply properties)
33 - `/sys/class/infiniband` (infiniband interconnect)
34 - `/sys/class/drm` (AMD GPUs)
35 - `ipc` (IPC semaphores and message queues)
36 - `ksm` Kernel Same-Page Merging performance (several files under `/sys/kernel/mm/ksm`).
37 - `netdata` (internal Netdata resources utilization)
38
39 - - -
40
41 ## Monitoring Disks
42
43 > Live demo of disk monitoring at: **[http://london.netdata.rocks](https://registry.my-netdata.io/#menu_disk)**
44
45 Performance monitoring for Linux disks is quite complicated. The main reason is the plethora of disk technologies available. There are many different hardware disk technologies, but there are even more **virtual disk** technologies that can provide additional storage features.
46
47 Hopefully, the Linux kernel provides many metrics that can provide deep insights of what our disks our doing. The kernel measures all these metrics on all layers of storage: **virtual disks**, **physical disks** and **partitions of disks**.
48
49 ### Monitored disk metrics
50
51 - **I/O bandwidth/s (kb/s)**
52 The amount of data transferred from and to the disk.
53 - **Amount of discarded data (kb/s)**
54 - **I/O operations/s**
55 The number of I/O operations completed.
56 - **Extended I/O operations/s**
57 The number of extended I/O operations completed.
58 - **Queued I/O operations**
59 The number of currently queued I/O operations. For traditional disks that execute commands one after another, one of them is being run by the disk and the rest are just waiting in a queue.
60 - **Backlog size (time in ms)**
61 The expected duration of the currently queued I/O operations.
62 - **Utilization (time percentage)**
63 The percentage of time the disk was busy with something. This is a very interesting metric, since for most disks, that execute commands sequentially, **this is the key indication of congestion**. A sequential disk that is 100% of the available time busy, has no time to do anything more, so even if the bandwidth or the number of operations executed by the disk is low, its capacity has been reached.
64 Of course, for newer disk technologies (like fusion cards) that are capable to execute multiple commands in parallel, this metric is just meaningless.
65 - **Average I/O operation time (ms)**
66 The average time for I/O requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them.
67 - **Average I/O operation time for extended operations (ms)**
68 The average time for extended I/O requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them.
69 - **Average I/O operation size (kb)**
70 The average amount of data of the completed I/O operations.
71 - **Average amount of discarded data (kb)**
72 The average amount of data of the completed discard operations.
73 - **Average Service Time (ms)**
74 The average service time for completed I/O operations. This metric is calculated using the total busy time of the disk and the number of completed operations. If the disk is able to execute multiple parallel operations the reporting average service time will be misleading.
75 - **Average Service Time for extended I/O operations (ms)**
76 The average service time for completed extended I/O operations.
77 - **Merged I/O operations/s**
78 The Linux kernel is capable of merging I/O operations. So, if two requests to read data from the disk are adjacent, the Linux kernel may merge them to one before giving them to disk. This metric measures the number of operations that have been merged by the Linux kernel.
79 - **Merged discard operations/s**
80 - **Total I/O time**
81 The sum of the duration of all completed I/O operations. This number can exceed the interval if the disk is able to execute multiple I/O operations in parallel.
82 - **Space usage**
83 For mounted disks, Netdata will provide a chart for their space, with 3 dimensions:
84 1. free
85 2. used
86 3. reserved for root
87 - **inode usage**
88 For mounted disks, Netdata will provide a chart for their inodes (number of file and directories), with 3 dimensions:
89 1. free
90 2. used
91 3. reserved for root
92
93 ### disk names
94
95 Netdata will automatically set the name of disks on the dashboard, from the mount point they are mounted, of course only when they are mounted. Changes in mount points are not currently detected (you will have to restart Netdata to change the name of the disk). To use disk IDs provided by `/dev/disk/by-id`, the `name disks by id` option should be enabled. The `preferred disk ids` simple pattern allows choosing disk IDs to be used in the first place.
96
97 ### performance metrics
98
99 By default, Netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after Netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Set `yes` for a chart instead of `auto` to enable it permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
100
101 Netdata categorizes all block devices in 3 categories:
102
103 1. physical disks (i.e. block devices that do not have child devices and are not partitions)
104 2. virtual disks (i.e. block devices that have child devices - like RAID devices)
105 3. disk partitions (i.e. block devices that are part of a physical disk)
106
107 Performance metrics are enabled by default for all disk devices, except partitions and not-mounted virtual disks. Of course, you can enable/disable monitoring any block device by editing the Netdata configuration file.
108
109 ### Netdata configuration
110
111 You can get the running Netdata configuration using this:
112
113 ```sh
114 cd /etc/netdata
115 curl "http://localhost:19999/netdata.conf" >netdata.conf.new
116 mv netdata.conf.new netdata.conf
117 ```
118
119 Then edit `netdata.conf` and find the following section. This is the basic plugin configuration.
120
121 ```text
122 [plugin:proc:/proc/diskstats]
123 # enable new disks detected at runtime = yes
124 # performance metrics for physical disks = auto
125 # performance metrics for virtual disks = auto
126 # performance metrics for partitions = no
127 # bandwidth for all disks = auto
128 # operations for all disks = auto
129 # merged operations for all disks = auto
130 # i/o time for all disks = auto
131 # queued operations for all disks = auto
132 # utilization percentage for all disks = auto
133 # extended operations for all disks = auto
134 # backlog for all disks = auto
135 # bcache for all disks = auto
136 # bcache priority stats update every = off
137 # remove charts of removed disks = yes
138 # path to get block device = /sys/block/%s
139 # path to get block device bcache = /sys/block/%s/bcache
140 # path to get virtual block device = /sys/devices/virtual/block/%s
141 # path to get block device infos = /sys/dev/block/%lu:%lu/%s
142 # path to device mapper = /dev/mapper
143 # path to /dev/disk/by-label = /dev/disk/by-label
144 # path to /dev/disk/by-id = /dev/disk/by-id
145 # path to /dev/vx/dsk = /dev/vx/dsk
146 # name disks by id = no
147 # preferred disk ids = *
148 # exclude disks = loop* ram*
149 # filename to monitor = /proc/diskstats
150 # performance metrics for disks with major 8 = yes
151 ```
152
153 For each virtual disk, physical disk and partition you will have a section like this:
154
155 ```text
156 [plugin:proc:/proc/diskstats:sda]
157 # enable = yes
158 # enable performance metrics = auto
159 # bandwidth = auto
160 # operations = auto
161 # merged operations = auto
162 # i/o time = auto
163 # queued operations = auto
164 # utilization percentage = auto
165 # extended operations = auto
166 # backlog = auto
167 ```
168
169 For all configuration options:
170
171 - `auto` = enable monitoring if the collected values are not zero
172 - `yes` = enable monitoring
173 - `no` = disable monitoring
174
175 Of course, to set options, you will have to uncomment them. The comments show the internal defaults.
176
177 After saving `/etc/netdata/netdata.conf`, restart your Netdata to apply them.
178
179 #### Disabling performance metrics for individual device and to multiple devices by device type
180
181 You can pretty easy disable performance metrics for individual device, for ex.:
182
183 ```text
184 [plugin:proc:/proc/diskstats:sda]
185 enable performance metrics = no
186 ```
187
188 But sometimes you need disable performance metrics for all devices with the same type, to do it you need to figure out device type from `/proc/diskstats` for ex.:
189
190 ```text
191 7 0 loop0 1651 0 3452 168 0 0 0 0 0 8 168
192 7 1 loop1 4955 0 11924 880 0 0 0 0 0 64 880
193 7 2 loop2 36 0 216 4 0 0 0 0 0 4 4
194 7 6 loop6 0 0 0 0 0 0 0 0 0 0 0
195 7 7 loop7 0 0 0 0 0 0 0 0 0 0 0
196 251 2 zram2 27487 0 219896 188 79953 0 639624 1640 0 1828 1828
197 251 3 zram3 27348 0 218784 152 79952 0 639616 1960 0 2060 2104
198 ```
199
200 All zram devices starts with `251` number and all loop devices starts with `7`.
201 So, to disable performance metrics for all loop devices you could add `performance metrics for disks with major 7 = no` to `[plugin:proc:/proc/diskstats]` section.
202
203 ```text
204 [plugin:proc:/proc/diskstats]
205 performance metrics for disks with major 7 = no
206 ```
207
208 ## Monitoring RAID arrays
209
210 ### Monitored RAID array metrics
211
212 1. **Health** Number of failed disks in every array (aggregate chart).
213
214 2. **Disks stats**
215
216 - total (number of devices array ideally would have)
217 - inuse (number of devices currently are in use)
218
219 3. **Mismatch count**
220
221 - unsynchronized blocks
222
223 4. **Current status**
224
225 - resync in percent
226 - recovery in percent
227 - reshape in percent
228 - check in percent
229
230 5. **Operation status** (if resync/recovery/reshape/check is active)
231
232 - finish in minutes
233 - speed in megabytes/s
234
235 6. **Non-redundant array availability**
236
237 #### configuration
238
239 ```text
240 [plugin:proc:/proc/mdstat]
241 # faulty devices = yes
242 # nonredundant arrays availability = yes
243 # mismatch count = auto
244 # disk stats = yes
245 # operation status = yes
246 # make charts obsolete = yes
247 # filename to monitor = /proc/mdstat
248 # mismatch_cnt filename to monitor = /sys/block/%s/md/mismatch_cnt
249 ```
250
251 ## Monitoring CPUs
252
253 The `/proc/stat` module monitors CPU utilization, interrupts, context switches, processes started/running, thermal
254 throttling, frequency, and idle states. It gathers this information from multiple files.
255
256 If your system has more than 50 processors (`physical processors * cores per processor * threads per core`), the Agent
257 automatically disables CPU thermal throttling, frequency, and idle state charts. To override this default, see the next
258 section on configuration.
259
260 ### Configuration
261
262 The settings for monitoring CPUs is in the `[plugin:proc:/proc/stat]` of your `netdata.conf` file.
263
264 The `keep per core files open` option lets you reduce the number of file operations on multiple files.
265
266 If your system has more than 50 processors and you would like to see the CPU thermal throttling, frequency, and idle
267 state charts that are automatically disabled, you can set the following boolean options in the
268 `[plugin:proc:/proc/stat]` section.
269
270 ```text
271 keep per core files open = yes
272 keep cpuidle files open = yes
273 core_throttle_count = yes
274 package_throttle_count = yes
275 cpu frequency = yes
276 cpu idle states = yes
277 ```
278
279 ### CPU frequency
280
281 The module shows the current CPU frequency as set by the `cpufreq` kernel
282 module.
283
284 **Requirement:**
285 You need to have `CONFIG_CPU_FREQ` and (optionally) `CONFIG_CPU_FREQ_STAT`
286 enabled in your kernel.
287
288 `cpufreq` interface provides two different ways of getting the information through `/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq` and `/sys/devices/system/cpu/cpu*/cpufreq/stats/time_in_state` files. The latter is more accurate so it is preferred in the module. `scaling_cur_freq` represents only the current CPU frequency, and doesn't account for any state changes which happen between updates. The module switches back and forth between these two methods if governor is changed.
289
290 It produces one chart with multiple lines (one line per core).
291
292 #### configuration
293
294 `scaling_cur_freq filename to monitor` and `time_in_state filename to monitor` in the `[plugin:proc:/proc/stat]` configuration section
295
296 ### CPU idle states
297
298 The module monitors the usage of CPU idle states.
299
300 **Requirement:**
301 Your kernel needs to have `CONFIG_CPU_IDLE` enabled.
302
303 It produces one stacked chart per CPU, showing the percentage of time spent in
304 each state.
305
306 #### configuration
307
308 `schedstat filename to monitor`, `cpuidle name filename to monitor`, and `cpuidle time filename to monitor` in the `[plugin:proc:/proc/stat]` configuration section
309
310 ## Monitoring memory
311
312 ### Monitored memory metrics
313
314 - Amount of memory swapped in/out
315 - Amount of memory paged from/to disk
316 - Number of memory page faults
317 - Number of out of memory kills
318 - Number of NUMA events
319
320 ### Configuration
321
322 ```text
323 [plugin:proc:/proc/vmstat]
324 filename to monitor = /proc/vmstat
325 swap i/o = auto
326 disk i/o = yes
327 memory page faults = yes
328 out of memory kills = yes
329 system-wide numa metric summary = auto
330 ```
331
332 ## Monitoring Network Interfaces
333
334 ### Monitored network interface metrics
335
336 - **Physical Network Interfaces Aggregated Bandwidth (kilobits/s)**
337 The amount of data received and sent through all physical interfaces in the system. This is the source of data for the Net Inbound and Net Outbound dials in the System Overview section.
338
339 - **Bandwidth (kilobits/s)**
340 The amount of data received and sent through the interface.
341
342 - **Packets (packets/s)**
343 The number of packets received, packets sent, and multicast packets transmitted through the interface.
344
345 - **Interface Errors (errors/s)**
346 The number of errors for the inbound and outbound traffic on the interface.
347
348 - **Interface Drops (drops/s)**
349 The number of packets dropped for the inbound and outbound traffic on the interface.
350
351 - **Interface FIFO Buffer Errors (errors/s)**
352 The number of FIFO buffer errors encountered while receiving and transmitting data through the interface.
353
354 - **Compressed Packets (packets/s)**
355 The number of compressed packets transmitted or received by the device driver.
356
357 - **Network Interface Events (events/s)**
358 The number of packet framing errors, collisions detected on the interface, and carrier losses detected by the device driver.
359
360 By default Netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after Netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though).
361
362 ### Monitoring wireless network interfaces
363
364 The settings for monitoring wireless is in the `[plugin:proc:/proc/net/wireless]` section of your `netdata.conf` file.
365
366 ```text
367 status for all interfaces = yes
368 quality for all interfaces = yes
369 discarded packets for all interfaces = yes
370 missed beacon for all interface = yes
371 ```
372
373 You can set the following values for each configuration option:
374
375 - `auto` = enable monitoring if the collected values are not zero
376 - `yes` = enable monitoring
377 - `no` = disable monitoring
378
379 #### Monitored wireless interface metrics
380
381 - **Status**
382 The current state of the interface. This is a device-dependent option.
383
384 - **Link**
385 Overall quality of the link.
386
387 - **Level**
388 Received signal strength (RSSI), which indicates how strong the received signal is.
389
390 - **Noise**
391 Background noise level.
392
393 - **Discarded packets**
394 Discarded packets for: Number of packets received with a different NWID or ESSID (`nwid`), unable to decrypt (`crypt`), hardware was not able to properly re-assemble the link layer fragments (`frag`), packets failed to deliver (`retry`), and packets lost in relation with specific wireless operations (`misc`).
395
396 - **Missed beacon**
397 Number of periodic beacons from the cell or the access point the interface has missed.
398
399 #### Wireless configuration
400
401 #### alerts
402
403 There are several alerts defined in `health.d/net.conf`.
404
405 The tricky ones are `inbound packets dropped` and `inbound packets dropped ratio`. They have quite a strict policy so that they warn users about possible issues. These alerts can be annoying for some network configurations. It is especially true for some bonding configurations if an interface is a child or a bonding interface itself. If it is expected to have a certain number of drops on an interface for a certain network configuration, a separate alert with different triggering thresholds can be created or the existing one can be disabled for this specific interface. It can be done with the help of the families line in the alert configuration. For example, if you want to disable the `inbound packets dropped` alert for `eth0`, set `families: !eth0 *` in the alert definition for `template: inbound_packets_dropped`.
406
407 #### configuration
408
409 Module configuration:
410
411 ```text
412 [plugin:proc:/proc/net/dev]
413 # filename to monitor = /proc/net/dev
414 # path to get virtual interfaces = /sys/devices/virtual/net/%s
415 # path to get net device speed = /sys/class/net/%s/speed
416 # enable new interfaces detected at runtime = auto
417 # bandwidth for all interfaces = auto
418 # packets for all interfaces = auto
419 # errors for all interfaces = auto
420 # drops for all interfaces = auto
421 # fifo for all interfaces = auto
422 # compressed packets for all interfaces = auto
423 # frames, collisions, carrier counters for all interfaces = auto
424 # disable by default interfaces matching = lo fireqos* *-ifb
425 # refresh interface speed every seconds = 10
426 ```
427
428 Per interface configuration:
429
430 ```text
431 [plugin:proc:/proc/net/dev:enp0s3]
432 # enabled = yes
433 # virtual = no
434 # bandwidth = auto
435 # packets = auto
436 # errors = auto
437 # drops = auto
438 # fifo = auto
439 # compressed = auto
440 # events = auto
441 ```
442
443 ## Linux Anti-DDoS
444
445 ![image6](https://cloud.githubusercontent.com/assets/2662304/14253733/53550b16-fa95-11e5-8d9d-4ed171df4735.gif)
446
447 SYNPROXY is a TCP SYN packets proxy. It can be used to protect any TCP server (like a web server) from SYN floods and similar DDos attacks.
448
449 SYNPROXY is a netfilter module, in the Linux kernel (since version 3.12). It is optimized to handle millions of packets per second utilizing all CPUs available without any concurrency locking between the connections.
450
451 The net effect of this, is that the real servers will not notice any change during the attack. The valid TCP connections will pass through and served, while the attack will be stopped at the firewall.
452
453 Netdata does not enable SYNPROXY. It just uses the SYNPROXY metrics exposed by your kernel, so you will first need to configure it. The hard way is to run iptables SYNPROXY commands directly on the console. An easier way is to use [FireHOL](https://firehol.org/), which, is a firewall manager for iptables. FireHOL can configure SYNPROXY using the following setup guides:
454
455 - **[Working with SYNPROXY](https://github.com/firehol/firehol/wiki/Working-with-SYNPROXY)**
456 - **[Working with SYNPROXY and traps](https://github.com/firehol/firehol/wiki/Working-with-SYNPROXY-and-traps)**
457
458 ### Real-time monitoring of Linux Anti-DDoS
459
460 Netdata is able to monitor in real-time (per second updates) the operation of the Linux Anti-DDoS protection.
461
462 It visualizes 4 charts:
463
464 1. TCP SYN Packets received on ports operated by SYNPROXY
465 2. TCP Cookies (valid, invalid, retransmits)
466 3. Connections Reopened
467 4. Entries used
468
469 Example image:
470
471 ![ddos](https://cloud.githubusercontent.com/assets/2662304/14398891/6016e3fc-fdf0-11e5-942b-55de6a52cb66.gif)
472
473 See Linux Anti-DDoS in action at: **[Netdata demo site (with SYNPROXY enabled)](https://registry.my-netdata.io/#menu_netfilter_submenu_synproxy)**
474
475 ## Linux power supply
476
477 This module monitors various metrics reported by power supply drivers
478 on Linux. This allows tracking and alerting on things like remaining
479 battery capacity.
480
481 Depending on the underlying driver, it may provide the following charts
482 and metrics:
483
484 1. Capacity: The power supply capacity expressed as a percentage.
485
486 - capacity_now
487
488 2. Charge: The charge for the power supply, expressed as amp-hours.
489
490 - charge_full_design
491 - charge_full
492 - charge_now
493 - charge_empty
494 - charge_empty_design
495
496 3. Energy: The energy for the power supply, expressed as watthours.
497
498 - energy_full_design
499 - energy_full
500 - energy_now
501 - energy_empty
502 - energy_empty_design
503
504 4. Voltage: The voltage for the power supply, expressed as volts.
505
506 - voltage_max_design
507 - voltage_max
508 - voltage_now
509 - voltage_min
510 - voltage_min_design
511
512 ### configuration
513
514 ```text
515 [plugin:proc:/sys/class/power_supply]
516 # battery capacity = yes
517 # battery charge = no
518 # battery energy = no
519 # battery power = yes
520 # power supply voltage = no
521 # keep files open = auto
522 # directory to monitor = /sys/class/power_supply
523 ```
524
525 ### notes
526
527 - Most drivers provide at least the first chart. Battery powered ACPI
528 compliant systems (like most laptops) provide all but the third, but do
529 not provide all of the metrics for each chart.
530
531 - Current, energy, and voltages are reported with a *very* high precision
532 by the power_supply framework. Usually, this is far higher than the
533 actual hardware supports reporting, so expect to see changes in these
534 charts jump instead of scaling smoothly.
535
536 - If `max` or `full` attribute is defined by the driver, but not a
537 corresponding `min` or `empty` attribute, then Netdata will still provide
538 the corresponding `min` or `empty`, which will then always read as zero.
539 This way, alerts which match on these will still work.
540
541 ## Infiniband interconnect
542
543 This module monitors every active Infiniband port. It provides generic counters statistics, and per-vendor hw-counters (if vendor is supported).
544
545 ### Monitored interface metrics
546
547 Each port will have its counters metrics monitored, grouped in the following charts:
548
549 - **Bandwidth usage**
550 Sent/Received data, in KB/s
551
552 - **Packets Statistics**
553 Sent/Received packets, in 3 categories: total, unicast and multicast.
554
555 - **Errors Statistics**
556 Many errors counters are provided, presenting statistics for:
557 - Packets: malformed, sent/received discarded by card/switch, missing resource
558 - Link: downed, recovered, integrity error, minor error
559 - Other events: Tick Wait to send, buffer overrun
560
561 If your vendor is supported, you'll also get HW-Counters statistics. These being vendor specific, please refer to their documentation.
562
563 - Mellanox: [see statistics documentation](https://community.mellanox.com/s/article/understanding-mlx5-linux-counters-and-status-parameters)
564
565 ### configuration
566
567 Default configuration will monitor only enabled infiniband ports, and refresh newly activated or created ports every 30 seconds
568
569 ```text
570 [plugin:proc:/sys/class/infiniband]
571 # dirname to monitor = /sys/class/infiniband
572 # bandwidth counters = yes
573 # packets counters = yes
574 # errors counters = yes
575 # hardware packets counters = auto
576 # hardware errors counters = auto
577 # monitor only ports being active = auto
578 # disable by default interfaces matching =
579 # refresh ports state every = 30s
580 ```
581
582 ## AMD GPUs
583
584 This module monitors every AMD GPU card discovered at Agent startup.
585
586 ### Monitored GPU metrics
587
588 The following charts will be provided:
589
590 - **GPU utilization**
591 - **GPU memory utilization**
592 - **GPU clock frequency**
593 - **GPU memory clock frequency**
594 - **VRAM memory usage percentage**
595 - **VRAM memory usage**
596 - **visible VRAM memory usage percentage**
597 - **visible VRAM memory usage**
598 - **GTT memory usage percentage**
599 - **GTT memory usage**
600
601 ### configuration
602
603 The `drm` path can be configured if it differs from the default:
604
605 ```text
606 [plugin:proc:/sys/class/drm]
607 # directory to monitor = /sys/class/drm
608 ```
609
610 > **Note**
611 >
612 > Temperature, fan speed, voltage and power metrics for AMD GPUs can be monitored using the [Sensors](/src/go/plugin/go.d/collector/sensors/README.md) plugin.
613
614 ## IPC
615
616 ### Monitored IPC metrics
617
618 - **number of messages in message queues**
619 - **amount of memory used by message queues**
620 - **number of semaphores**
621 - **number of semaphore arrays**
622 - **number of shared memory segments**
623 - **amount of memory used by shared memory segments**
624
625 As far as the message queue charts are dynamic, sane limits are applied for the number of dimensions per chart (the limit is configurable).
626
627 ### configuration
628
629 ```text
630 [plugin:proc:ipc]
631 # message queues = yes
632 # semaphore totals = yes
633 # shared memory totals = yes
634 # msg filename to monitor = /proc/sysvipc/msg
635 # shm filename to monitor = /proc/sysvipc/shm
636 # max dimensions in memory allowed = 50
637 ```