diff options
Diffstat (limited to 'collectors/tc.plugin')
| l---------[-rw-r--r--] | collectors/tc.plugin/README.md | 210 | ||||
| -rw-r--r-- | collectors/tc.plugin/integrations/tc_qos_classes.md | 170 | ||||
| -rw-r--r-- | collectors/tc.plugin/metadata.yaml | 37 | ||||
| -rwxr-xr-x | collectors/tc.plugin/tc-qos-helper.sh.in | 2 |
4 files changed, 207 insertions, 212 deletions
diff --git a/collectors/tc.plugin/README.md b/collectors/tc.plugin/README.md index de5fd474..2a20ff26 100644..120000 --- a/collectors/tc.plugin/README.md +++ b/collectors/tc.plugin/README.md @@ -1,209 +1 @@ -<!-- -title: "tc.plugin" -custom_edit_url: "https://github.com/netdata/netdata/edit/master/collectors/tc.plugin/README.md" -sidebar_label: "tc.plugin" -learn_status: "Published" -learn_topic_type: "References" -learn_rel_path: "Integrations/Monitor/Networking" ---> - -# tc.plugin - -Live demo - **[see it in action here](https://registry.my-netdata.io/#menu_tc)** ! - - - -Netdata monitors `tc` QoS classes for all interfaces. - -If you also use [FireQOS](http://firehol.org/tutorial/fireqos-new-user/) it will collect interface and class names. - -There is a [shell helper](https://raw.githubusercontent.com/netdata/netdata/master/collectors/tc.plugin/tc-qos-helper.sh.in) for this (all parsing is done by the plugin in `C` code - this shell script is just a configuration for the command to run to get `tc` output). - -The source of the tc plugin is [here](https://raw.githubusercontent.com/netdata/netdata/master/collectors/tc.plugin/plugin_tc.c). It is somewhat complex, because a state machine was needed to keep track of all the `tc` classes, including the pseudo classes tc dynamically creates. - -## Motivation - -One category of metrics missing in Linux monitoring, is bandwidth consumption for each open socket (inbound and outbound traffic). So, you cannot tell how much bandwidth your web server, your database server, your backup, your ssh sessions, etc are using. - -To solve this problem, the most *adventurous* Linux monitoring tools install kernel modules to capture all traffic, analyze it and provide reports per application. A lot of work, CPU intensive and with a great degree of risk (due to the kernel modules involved which might affect the stability of the whole system). Not to mention that such solutions are probably better suited for a core linux router in your network. - -Others use NFACCT, the netfilter accounting module which is already part of the Linux firewall. However, this would require configuring a firewall on every system you want to measure bandwidth (just FYI, I do install a firewall on every server - and I strongly advise you to do so too - but configuring accounting on all servers seems overkill when you don't really need it for billing purposes). - -**There is however a much simpler approach**. - -## QoS - -One of the features the Linux kernel has, but it is rarely used, is its ability to **apply QoS on traffic**. Even most interesting is that it can apply QoS to **both inbound and outbound traffic**. - -QoS is about 2 features: - -1. **Classify traffic** - - Classification is the process of organizing traffic in groups, called **classes**. Classification can evaluate every aspect of network packets, like source and destination ports, source and destination IPs, netfilter marks, etc. - - When you classify traffic, you just assign a label to it. Of course classes have some properties themselves (like queuing mechanisms), but let's say it is that simple: **a label**. For example **I call `web server` traffic, the traffic from my server's tcp/80, tcp/443 and to my server's tcp/80, tcp/443, while I call `web surfing` all other tcp/80 and tcp/443 traffic**. You can use any combinations you like. There is no limit. - -2. **Apply traffic shaping rules to these classes** - - Traffic shaping is used to control how network interface bandwidth should be shared among the classes. Normally, you need to do this, when there is not enough bandwidth to satisfy all the demand, or when you want to control the supply of bandwidth to certain services. Of course classification is sufficient for monitoring traffic, but traffic shaping is also quite important, as we will explain in the next section. - -## Why you want QoS - -1. **Monitoring the bandwidth used by services** - - Netdata provides wonderful real-time charts, like this one (wait to see the orange `rsync` part): - -  - -2. **Ensure sensitive administrative tasks will not starve for bandwidth** - - Have you tried to ssh to a server when the network is congested? If you have, you already know it does not work very well. QoS can guarantee that services like ssh, dns, ntp, etc will always have a small supply of bandwidth. So, no matter what happens, you will be able to ssh to your server and DNS will always work. - -3. **Ensure administrative tasks will not monopolize all the bandwidth** - - Services like backups, file copies, database dumps, etc can easily monopolize all the available bandwidth. It is common for example a nightly backup, or a huge file transfer to negatively influence the end-user experience. QoS can fix that. - -4. **Ensure each end-user connection will get a fair cut of the available bandwidth.** - - Several QoS queuing disciplines in Linux do this automatically, without any configuration from you. The result is that new sockets are favored over older ones, so that users will get a snappier experience, while others are transferring large amounts of traffic. - -5. **Protect the servers from DDoS attacks.** - - When your system is under a DDoS attack, it will get a lot more bandwidth compared to the one it can handle and probably your applications will crash. Setting a limit on the inbound traffic using QoS, will protect your servers (throttle the requests) and depending on the size of the attack may allow your legitimate users to access the server, while the attack is taking place. - - Using QoS together with a [SYNPROXY](https://github.com/netdata/netdata/blob/master/collectors/proc.plugin/README.md) will provide a great degree of protection against most DDoS attacks. Actually when I wrote that article, a few folks tried to DDoS the Netdata demo site to see in real-time the SYNPROXY operation. They did not do it right, but anyway a great deal of requests reached the Netdata server. What saved Netdata was QoS. The Netdata demo server has QoS installed, so the requests were throttled and the server did not even reach the point of resource starvation. Read about it [here](https://github.com/netdata/netdata/blob/master/collectors/proc.plugin/README.md). - -On top of all these, QoS is extremely light. You will configure it once, and this is it. It will not bother you again and it will not use any noticeable CPU resources, especially on application and database servers. - -``` -- ensure administrative tasks (like ssh, dns, etc) will always have a small but guaranteed bandwidth. So, no matter what happens, I will be able to ssh to my server and DNS will work. - -- ensure other administrative tasks will not monopolize all the available bandwidth. So, my nightly backup will not hurt my users, a developer that is copying files over the net will not get all the available bandwidth, etc. - -- ensure each end-user connection will get a fair cut of the available bandwidth. -``` - -Once **traffic classification** is applied, we can use **[netdata](https://github.com/netdata/netdata)** to visualize the bandwidth consumption per class in real-time (no configuration is needed for Netdata - it will figure it out). - -QoS, is extremely light. You will configure it once, and this is it. It will not bother you again and it will not use any noticeable CPU resources, especially on application and database servers. - -This is QoS from a home linux router. Check these features: - -1. It is real-time (per second updates) -2. QoS really works in Linux - check that the `background` traffic is squeezed when `surfing` needs it. - - - ---- - -## QoS in Linux? - -Of course, `tc` is probably **the most undocumented, complicated and unfriendly** command in Linux. - -For example, do you know that for matching a simple port range in `tc`, e.g. all the high ports, from 1025 to 65535 inclusive, you have to match these: - -``` -1025/0xffff -1026/0xfffe -1028/0xfffc -1032/0xfff8 -1040/0xfff0 -1056/0xffe0 -1088/0xffc0 -1152/0xff80 -1280/0xff00 -1536/0xfe00 -2048/0xf800 -4096/0xf000 -8192/0xe000 -16384/0xc000 -32768/0x8000 -``` - -To do it the hard way, you can go through the [tc configuration steps](#qos-configuration-with-tc). An easier way is to use **[FireQOS](https://firehol.org/tutorial/fireqos-new-user/)**, a tool that simplifies QoS management in Linux. - -## Qos Configuration with FireHOL - -The **[FireHOL](https://firehol.org/)** package already distributes **[FireQOS](https://firehol.org/tutorial/fireqos-new-user/)**. Check the **[FireQOS tutorial](https://firehol.org/tutorial/fireqos-new-user/)** to learn how to write your own QoS configuration. - -With **[FireQOS](https://firehol.org/tutorial/fireqos-new-user/)**, it is **really simple for everyone to use QoS in Linux**. Just install the package `firehol`. It should already be available for your distribution. If not, check the **[FireHOL Installation Guide](https://firehol.org/installing/)**. After that, you will have the `fireqos` command which uses a configuration like the following `/etc/firehol/fireqos.conf`, used at the Netdata demo site: - -```sh - # configure the Netdata ports - server_netdata_ports="tcp/19999" - - interface eth0 world bidirectional ethernet balanced rate 50Mbit - class arp - match arp - - class icmp - match icmp - - class dns commit 1Mbit - server dns - client dns - - class ntp - server ntp - client ntp - - class ssh commit 2Mbit - server ssh - client ssh - - class rsync commit 2Mbit max 10Mbit - server rsync - client rsync - - class web_server commit 40Mbit - server http - server netdata - - class client - client surfing - - class nms commit 1Mbit - match input src 10.2.3.5 -``` - -Nothing more is needed. You just run `fireqos start` to apply this configuration, restart Netdata and you have real-time visualization of the bandwidth consumption of your applications. FireQOS is not a daemon. It will just convert the configuration to `tc` commands. It will run them and it will exit. - -**IMPORTANT**: If you copy this configuration to apply it to your system, please adapt the speeds - experiment in non-production environments to learn the tool, before applying it on your servers. - -And this is what you are going to get: - - - -## QoS Configuration with tc - -First, setup the tc rules in rc.local using commands to assign different QoS markings to different classids. You can see one such example in [github issue #4563](https://github.com/netdata/netdata/issues/4563#issuecomment-455711973). - -Then, map the classids to names by creating `/etc/iproute2/tc_cls`. For example: - -``` -2:1 Standard -2:8 LowPriorityData -2:10 HighThroughputData -2:16 OAM -2:18 LowLatencyData -2:24 BroadcastVideo -2:26 MultimediaStreaming -2:32 RealTimeInteractive -2:34 MultimediaConferencing -2:40 Signalling -2:46 Telephony -2:48 NetworkControl -``` - -Add the following configuration option in `/etc/netdata.conf`: - -```\[plugin:tc] - enable show all classes and qdiscs for all interfaces = yes -``` - -Finally, create `/etc/netdata/tc-qos-helper.conf` with this content: -`tc_show="class"` - -Please note, that 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. - - +integrations/tc_qos_classes.md
\ No newline at end of file diff --git a/collectors/tc.plugin/integrations/tc_qos_classes.md b/collectors/tc.plugin/integrations/tc_qos_classes.md new file mode 100644 index 00000000..2e013fc0 --- /dev/null +++ b/collectors/tc.plugin/integrations/tc_qos_classes.md @@ -0,0 +1,170 @@ +<!--startmeta +custom_edit_url: "https://github.com/netdata/netdata/edit/master/collectors/tc.plugin/README.md" +meta_yaml: "https://github.com/netdata/netdata/edit/master/collectors/tc.plugin/metadata.yaml" +sidebar_label: "tc QoS classes" +learn_status: "Published" +learn_rel_path: "Data Collection/Linux Systems/Network" +message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE COLLECTOR'S metadata.yaml FILE" +endmeta--> + +# tc QoS classes + + +<img src="https://netdata.cloud/img/netdata.png" width="150"/> + + +Plugin: tc.plugin +Module: tc.plugin + +<img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> + +## Overview + +Examine tc metrics to gain insights into Linux traffic control operations. Study packet flow rates, queue lengths, and drop rates to optimize network traffic flow. + +The plugin uses `tc` command to collect information about Traffic control. + +This collector is only supported on the following platforms: + +- Linux + +This collector supports collecting metrics from multiple instances of this integration, including remote instances. + +The plugin needs to access command `tc` to get the necessary metrics. To achieve this netdata modifies permission of file `/usr/libexec/netdata/plugins.d/tc-qos-helper.sh`. + +### Default Behavior + +#### Auto-Detection + +This integration doesn't support auto-detection. + +#### Limits + +The default configuration for this integration does not impose any limits on data collection. + +#### Performance Impact + +The default configuration for this integration is not expected to impose a significant performance impact on the system. + + +## Metrics + +Metrics grouped by *scope*. + +The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels. + + + +### Per network device direction + +Metrics related to QoS network device directions. Each direction (in/out) produces its own set of the following metrics. + +Labels: + +| Label | Description | +|:-----------|:----------------| +| device | The network interface. | +| device_name | The network interface name | +| group | The device family | + +Metrics: + +| Metric | Dimensions | Unit | +|:------|:----------|:----| +| tc.qos | a dimension per class | kilobits/s | +| tc.qos_packets | a dimension per class | packets/s | +| tc.qos_dropped | a dimension per class | packets/s | +| tc.qos_tokens | a dimension per class | tokens | +| tc.qos_ctokens | a dimension per class | ctokens | + + + +## Alerts + +There are no alerts configured by default for this integration. + + +## Setup + +### Prerequisites + +#### Create `tc-qos-helper.conf` + +In order to view tc classes, you need to create the file `/etc/netdata/tc-qos-helper.conf` with content: + +```conf +tc_show="class" +``` + + + +### Configuration + +#### File + +The configuration file name for this integration is `netdata.conf`. +Configuration for this specific integration is located in the `[plugin:tc]` section within that file. + +The file format is a modified INI syntax. The general structure is: + +```ini +[section1] + option1 = some value + option2 = some other value + +[section2] + option3 = some third value +``` +You can edit the configuration file using the `edit-config` script from the +Netdata [config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory). + +```bash +cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata +sudo ./edit-config netdata.conf +``` +#### Options + + + +<details><summary>Config option</summary> + +| Name | Description | Default | Required | +|:----|:-----------|:-------|:--------:| +| script to run to get tc values | Path to script `tc-qos-helper.sh` | usr/libexec/netdata/plugins.d/tc-qos-helper.s | False | +| enable show all classes and qdiscs for all interfaces | yes/no flag to control what data is presented. | yes | False | + +</details> + +#### Examples + +##### Basic + +A basic example configuration using classes defined in `/etc/iproute2/tc_cls`. + +An example of class IDs mapped to names in that file can be: + +```conf +2:1 Standard +2:8 LowPriorityData +2:10 HighThroughputData +2:16 OAM +2:18 LowLatencyData +2:24 BroadcastVideo +2:26 MultimediaStreaming +2:32 RealTimeInteractive +2:34 MultimediaConferencing +2:40 Signalling +2:46 Telephony +2:48 NetworkControl +``` + +You can read more about setting up the tc rules in rc.local in this [GitHub issue](https://github.com/netdata/netdata/issues/4563#issuecomment-455711973). + + +```yaml +[plugin:tc] + script to run to get tc values = /usr/libexec/netdata/plugins.d/tc-qos-helper.sh + enable show all classes and qdiscs for all interfaces = yes + +``` + diff --git a/collectors/tc.plugin/metadata.yaml b/collectors/tc.plugin/metadata.yaml index dcd03e47..f4039a8c 100644 --- a/collectors/tc.plugin/metadata.yaml +++ b/collectors/tc.plugin/metadata.yaml @@ -36,7 +36,14 @@ modules: description: "" setup: prerequisites: - list: [] + list: + - title: Create `tc-qos-helper.conf` + description: | + In order to view tc classes, you need to create the file `/etc/netdata/tc-qos-helper.conf` with content: + + ```conf + tc_show="class" + ``` configuration: file: name: "netdata.conf" @@ -52,16 +59,42 @@ modules: description: Path to script `tc-qos-helper.sh` default_value: "usr/libexec/netdata/plugins.d/tc-qos-helper.s" required: false + - name: enable show all classes and qdiscs for all interfaces + description: yes/no flag to control what data is presented. + default_value: "yes" + required: false examples: folding: enabled: false title: "Config" list: - name: Basic - description: A basic example configuration. + description: | + A basic example configuration using classes defined in `/etc/iproute2/tc_cls`. + + An example of class IDs mapped to names in that file can be: + + ```conf + 2:1 Standard + 2:8 LowPriorityData + 2:10 HighThroughputData + 2:16 OAM + 2:18 LowLatencyData + 2:24 BroadcastVideo + 2:26 MultimediaStreaming + 2:32 RealTimeInteractive + 2:34 MultimediaConferencing + 2:40 Signalling + 2:46 Telephony + 2:48 NetworkControl + ``` + + You can read more about setting up the tc rules in rc.local in this [GitHub issue](https://github.com/netdata/netdata/issues/4563#issuecomment-455711973). + config: | [plugin:tc] script to run to get tc values = /usr/libexec/netdata/plugins.d/tc-qos-helper.sh + enable show all classes and qdiscs for all interfaces = yes troubleshooting: problems: list: [] diff --git a/collectors/tc.plugin/tc-qos-helper.sh.in b/collectors/tc.plugin/tc-qos-helper.sh.in index 97d4d016..0fab69ee 100755 --- a/collectors/tc.plugin/tc-qos-helper.sh.in +++ b/collectors/tc.plugin/tc-qos-helper.sh.in @@ -291,7 +291,7 @@ while true; do echo "WORKTIME ${LOOPSLEEPMS_LASTWORK}" || exit - loopsleepms ${update_every} + loopsleepms "${update_every}" [ ${gc} -gt ${exit_after} ] && exit 0 done |