代码拉取完成，页面将自动刷新
/proc/net/dev (all network interfaces for all their values)/proc/diskstats (all disks for all their values)/proc/mdstat (status of RAID arrays)/proc/net/snmp (total IPv4, TCP and UDP usage)/proc/net/snmp6 (total IPv6 usage)/proc/net/netstat (more IPv4 usage)/proc/net/stat/nf_conntrack (connection tracking performance)/proc/net/stat/synproxy (synproxy performance)/proc/net/ip_vs/stats (IPVS connection statistics)/proc/stat (CPU utilization and attributes)/proc/meminfo (memory information)/proc/vmstat (system performance)/proc/net/rpc/nfsd (NFS server statistics for both v3 and v4 NFS servers)/sys/fs/cgroup (Control Groups - Linux Containers)/proc/self/mountinfo (mount points)/proc/interrupts (total and per core hardware interrupts)/proc/softirqs (total and per core software interrupts)/proc/loadavg (system load and total processes running)/proc/sys/kernel/random/entropy_avail (random numbers pool availability - used in cryptography)/sys/class/power_supply (power supply properties)ipc (IPC semaphores and message queues)ksm Kernel Same-Page Merging performance (several files under /sys/kernel/mm/ksm).netdata (internal Netdata resources utilization)Live demo of disk monitoring at: http://london.netdata.rocks
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.
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.
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.
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.
Netdata categorizes all block devices in 3 categories:
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.
You can get the running Netdata configuration using this:
cd /etc/netdata
curl "http://localhost:19999/netdata.conf" >netdata.conf.new
mv netdata.conf.new netdata.conf
Then edit netdata.conf and find the following section. This is the basic plugin configuration.
[plugin:proc:/proc/diskstats]
# enable new disks detected at runtime = yes
# performance metrics for physical disks = auto
# performance metrics for virtual disks = auto
# performance metrics for partitions = no
# bandwidth for all disks = auto
# operations for all disks = auto
# merged operations for all disks = auto
# i/o time for all disks = auto
# queued operations for all disks = auto
# utilization percentage for all disks = auto
# backlog for all disks = auto
# bcache for all disks = auto
# bcache priority stats update every = 0
# remove charts of removed disks = yes
# path to get block device = /sys/block/%s
# path to get block device bcache = /sys/block/%s/bcache
# path to get virtual block device = /sys/devices/virtual/block/%s
# path to get block device infos = /sys/dev/block/%lu:%lu/%s
# path to device mapper = /dev/mapper
# path to /dev/disk/by-label = /dev/disk/by-label
# path to /dev/disk/by-id = /dev/disk/by-id
# path to /dev/vx/dsk = /dev/vx/dsk
# name disks by id = no
# preferred disk ids = *
# exclude disks = loop* ram*
# filename to monitor = /proc/diskstats
# performance metrics for disks with major 8 = yes
For each virtual disk, physical disk and partition you will have a section like this:
[plugin:proc:/proc/diskstats:sda]
# enable = yes
# enable performance metrics = auto
# bandwidth = auto
# operations = auto
# merged operations = auto
# i/o time = auto
# queued operations = auto
# utilization percentage = auto
# backlog = auto
For all configuration options:
auto = enable monitoring if the collected values are not zeroyes = enable monitoringno = disable monitoringOf course, to set options, you will have to uncomment them. The comments show the internal defaults.
After saving /etc/netdata/netdata.conf, restart your Netdata to apply them.
You can pretty easy disable performance metrics for individual device, for ex.:
[plugin:proc:/proc/diskstats:sda]
enable performance metrics = no
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.:
7 0 loop0 1651 0 3452 168 0 0 0 0 0 8 168
7 1 loop1 4955 0 11924 880 0 0 0 0 0 64 880
7 2 loop2 36 0 216 4 0 0 0 0 0 4 4
7 6 loop6 0 0 0 0 0 0 0 0 0 0 0
7 7 loop7 0 0 0 0 0 0 0 0 0 0 0
251 2 zram2 27487 0 219896 188 79953 0 639624 1640 0 1828 1828
251 3 zram3 27348 0 218784 152 79952 0 639616 1960 0 2060 2104
All zram devices starts with 251 number and all loop devices starts with 7.
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.
[plugin:proc:/proc/diskstats]
performance metrics for disks with major 7 = no
Health Number of failed disks in every array (aggregate chart).
Disks stats
[plugin:proc:/proc/mdstat]
# faulty devices = yes
# nonredundant arrays availability = yes
# mismatch count = auto
# disk stats = yes
# operation status = yes
# make charts obsolete = yes
# filename to monitor = /proc/mdstat
# mismatch_cnt filename to monitor = /sys/block/%s/md/mismatch_cnt
The /proc/stat module monitors CPU utilization, interrupts, context switches, processes started/running, thermal throttling, frequency, and idle states. It gathers this information from multiple files.
If more than 50 cores are present in a system then CPU thermal throttling, frequency, and idle state charts are disabled.
keep per core files open option in the [plugin:proc:/proc/stat] configuration section allows reducing the number of file operations on multiple files.
The module shows the current CPU frequency as set by the cpufreq kernel
module.
Requirement:
You need to have CONFIG_CPU_FREQ and (optionally) CONFIG_CPU_FREQ_STAT
enabled in your kernel.
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.
It produces one chart with multiple lines (one line per core).
scaling_cur_freq filename to monitor and time_in_state filename to monitor in the [plugin:proc:/proc/stat] configuration section
The module monitors the usage of CPU idle states.
Requirement:
Your kernel needs to have CONFIG_CPU_IDLE enabled.
It produces one stacked chart per CPU, showing the percentage of time spent in each state.
schedstat filename to monitor, cpuidle name filename to monitor, and cpuidle time filename to monitor in the [plugin:proc:/proc/stat] configuration section
Physical Network Interfaces Aggregated Bandwidth (kilobits/s) 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.
Bandwidth (kilobits/s) The amount of data received and sent through the interface.
Packets (packets/s) The number of packets received, packets sent, and multicast packets transmitted through the interface.
Interface Errors (errors/s) The number of errors for the inbound and outbound traffic on the interface.
Interface Drops (drops/s) The number of packets dropped for the inbound and outbound traffic on the interface.
Interface FIFO Buffer Errors (errors/s) The number of FIFO buffer errors encountered while receiving and transmitting data through the interface.
Compressed Packets (packets/s) The number of compressed packets transmitted or received by the device driver.
Network Interface Events (events/s) The number of packet framing errors, collisions detected on the interface, and carrier losses detected by the device driver.
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).
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 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.
Module configuration:
[plugin:proc:/proc/net/dev]
# filename to monitor = /proc/net/dev
# path to get virtual interfaces = /sys/devices/virtual/net/%s
# path to get net device speed = /sys/class/net/%s/speed
# enable new interfaces detected at runtime = auto
# bandwidth for all interfaces = auto
# packets for all interfaces = auto
# errors for all interfaces = auto
# drops for all interfaces = auto
# fifo for all interfaces = auto
# compressed packets for all interfaces = auto
# frames, collisions, carrier counters for all interfaces = auto
# disable by default interfaces matching = lo fireqos* *-ifb
# refresh interface speed every seconds = 10
Per interface configuration:
[plugin:proc:/proc/net/dev:enp0s3]
# enabled = yes
# virtual = no
# bandwidth = auto
# packets = auto
# errors = auto
# drops = auto
# fifo = auto
# compressed = auto
# events = auto
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.
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.
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.
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, which, is a firewall manager for iptables. FireHOL can configure SYNPROXY using the following setup guides:
Netdata is able to monitor in real-time (per second updates) the operation of the Linux Anti-DDoS protection.
It visualizes 4 charts:
Example image:
See Linux Anti-DDoS in action at: Netdata demo site (with SYNPROXY enabled)
This module monitors various metrics reported by power supply drivers on Linux. This allows tracking and alerting on things like remaining battery capacity.
Depending on the underlying driver, it may provide the following charts and metrics:
Capacity: The power supply capacity expressed as a percentage.
Charge: The charge for the power supply, expressed as amphours.
Energy: The energy for the power supply, expressed as watthours.
Voltage: The voltage for the power supply, expressed as volts.
[plugin:proc:/sys/class/power_supply]
# battery capacity = yes
# battery charge = no
# battery energy = no
# power supply voltage = no
# keep files open = auto
# directory to monitor = /sys/class/power_supply
Most drivers provide at least the first chart. Battery powered ACPI compliant systems (like most laptops) provide all but the third, but do not provide all of the metrics for each chart.
Current, energy, and voltages are reported with a very high precision by the power_supply framework. Usually, this is far higher than the actual hardware supports reporting, so expect to see changes in these charts jump instead of scaling smoothly.
If max or full attribute is defined by the driver, but not a
corresponding min or empty attribute, then Netdata will still provide
the corresponding min or empty, which will then always read as zero.
This way, alerts which match on these will still work.
As far as the message queue charts are dynamic, sane limits are applied for the number of dimensions per chart (the limit is configurable).
[plugin:proc:ipc]
# message queues = yes
# semaphore totals = yes
# shared memory totals = yes
# msg filename to monitor = /proc/sysvipc/msg
# shm filename to monitor = /proc/sysvipc/shm
# max dimensions in memory allowed = 50
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。