diff options
author | Joel Hans <joel@netdata.cloud> | 2020-06-12 09:42:58 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2020-06-12 09:42:58 -0700 |
commit | 2c64795b7cc4e21a9382f863ae354b137b367b45 (patch) | |
tree | b714798283617f51e4e97a328beae1e9fbf46b0e /collectors/proc.plugin | |
parent | 68f1888227bac1602d8777742995e0276bf05510 (diff) |
Change streaming terminology to parent/child in docs (#9312)
* Intial pass through docs
* Dash instead of slash
* To parent/child
* Child nodes
* Change diagrams
* Allowlist
* Fixes for Andrew
* Remove from build_external
* Change in proc
Diffstat (limited to 'collectors/proc.plugin')
-rw-r--r-- | collectors/proc.plugin/README.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/collectors/proc.plugin/README.md b/collectors/proc.plugin/README.md index 1c295f7af3..fed7a76c0f 100644 --- a/collectors/proc.plugin/README.md +++ b/collectors/proc.plugin/README.md @@ -86,8 +86,8 @@ By default, Netdata will enable monitoring metrics only when they are not zero. Netdata categorizes all block devices in 3 categories: -1. physical disks (i.e. block devices that does not have slaves and are not partitions) -2. virtual disks (i.e. block devices that have slaves - like RAID devices) +1. physical disks (i.e. block devices that do not have child devices and are not partitions) +2. virtual disks (i.e. block devices that have child devices - like RAID devices) 3. disk partitions (i.e. block devices that are part of a physical disk) 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. @@ -325,7 +325,7 @@ By default Netdata will enable monitoring metrics only when they are not zero. I There are several alarms defined in `health.d/net.conf`. -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 alarms can be annoying for some network configurations. It is especially true for some bonding configurations if an interface is a slave 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 alarm 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](/health/REFERENCE.md#alarm-line-families) line in the alarm configuration. For example, if you want to disable the `inbound packets dropped` alarm for `eth0`, set `families: !eth0 *` in the alarm definition for `template: inbound_packets_dropped`. +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 alarms 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 alarm 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](/health/REFERENCE.md#alarm-line-families) line in the alarm configuration. For example, if you want to disable the `inbound packets dropped` alarm for `eth0`, set `families: !eth0 *` in the alarm definition for `template: inbound_packets_dropped`. #### configuration |