monitor qdisks /TrafficControl

[kecksk0enig]

Hi currently I am useing https://code.google.com/p/py-tc-probe/ to monitor my traffic shaping. For everything els i use monitorix and it is very useful.

Is it possible to include some kind of monitoring of qdisks in monitorix?

there are some other plugins avaible for munin http://munin-monitoring.org/browser/munin/plugins/node.d.debug/tc.in or standalone http://borg.uu3.net/traffic_shaping/monitoring.html http://www.docum.org/docum.org/monitor/

maybe some of this could be used by monitorix?

Thank you in advance!

[mikaku]

Hi kecksk0enig,

Some time ago I was thinking to implement a graph for traffic shaping monitoring but since it's something that I almost don't use I gave it up.

I'm currently so busy at work that is preventing me to put some time in Monitorix. Once things start being calming down again I'll take in consideration your request, which includes some interesting links that will indeed help me in its development.

Thank you very much for your feedback. Regards.

[mikaku]

As stated above, I don't use traffic control so it's a bit difficult for me to have real data. Can you please paste the output of your command tc -s qdisc?

Thanks

[kecksk0enig]

Hi! Sorry for the delay. here is an example output:

qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc htb 1: dev wlan1 root refcnt 5 r2q 10 default 20 direct_packets_stat 0 direct_qlen 1187
 Sent 60425504177 bytes 64520729 pkt (dropped 0, overlimits 58589506 requeues 1) 
 backlog 0b 0p requeues 1 
qdisc pfifo 20: dev wlan1 parent 1:20 limit 1187p
 Sent 1009588852 bytes 1649102 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc pfifo 21: dev wlan1 parent 1:21 limit 1187p
 Sent 54468345392 bytes 58940738 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc pfifo 22: dev wlan1 parent 1:22 limit 1187p
 Sent 4947569933 bytes 3930889 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

[mikaku]

kecksk0enig, thanks.

So, I guess you would be interested in the following queues of the wlan1 network interface:

• htb 1
• pfifo 20
• pfifo 21
• pfifo 22

If so, do you think that it would reasonable to define the network interface and the queue names in the monitorix configuration file?

[kecksk0enig]

totaly forgot about this: Yes. that would be perfectly reasonable. One schould also be able to rename the pfifos since pfifo 20 is no good of a name :)

[mikaku]

OK, more questions: what are the relevant values? I mean, how would you show these values in a consistent manner?

I can figure that 'Sent' bytes will be really easy to graph, but what about the others (dropped, overlimits, requeues, etc.) how they must be represented?

Any idea?

[kecksk0enig]

the htb1 is kind of "grand total" so the summation of pfifo20 21 22 should match exactly the values of htb1. I would plot a graph with output (and then htb1 in the back and the queues in front of it (like in the processor plot) or something like: http://forums.cacti.net/about29651.html

personally I am mostly interested in the split of qdiscs (which one is using up the most data compared to the others)

[mikaku]

I'm playing in my devel Monitorix configuration file with something like this (based on your current tc configuration):

# TC graph
# -----------------------------------------------------------------------------
<tc>
        list = wlan1
        <desc>
                wlan1 = htb 1, pfifo 20, pfifo 21, pfifo 22
        </desc>
        rigid = 0, 0, 0
        limit = 1000, 1000, 1000
</tc>

This way you would be able to monitor as many network interfaces as you want, and as many queues as you want for each network interface. The order of the queues are important in order to let to know to Monitorix which one is the grant total; which is htb 1 in your case.

The graph layout would be the Monitorix classic with a big main-left graph and with two small graphs in the right. The main graph would include the bytes sent for each queue and the others two would include the rest of values (packets, dropped, overlimits and requeues).

Do you miss anything in that configuration?

[kecksk0enig]

No that seems very reasonable :+1:

[mikaku]

@kecksk0enig,

I've created a new Traffic Control graph which hopefully covers what is requested in this issue. The following is a screen shot of the final graph:

Please, download the new tc.pm module and update your current monitorix.conf with the latest version here, and let me know how it works for you.

Thanks.

[kecksk0enig]

Hi the graph looks very well, is there any option to "rename" a specific queue in the graph so that ther will no longer be a pfifo 20 but a cusom override for it?

[mikaku]

Yeah, I thought about this. The problem is that they mostly have some space character in their names and that makes impossible to use them as an option in the configuration file, like this:

<desc>
        eth0 = cbq 1, sfq 10, sfq 20, sfq 30, ingress ffff
</desc>
<map>
        cbq 1 = aaaaaaaa
</map>

So, I think that the only way to do this would be changing their names by the position number in the eth0 option. That is, 0 for cbq 1, 1 for sfq 10, and so on.

This way we would be able to configure it like this:

<desc>
        eth0 = cbq 1, sfq 10, sfq 20, sfq 30, ingress ffff
</desc>
<map>
        0 = aaaaaaaa
        1 = bbbbbbbbbbb
        2 = cccccccccc
</map>

[kecksk0enig]

If that would do the trick :+1:

[mikaku]

Can you make a screen shot of a real working graph? just to make sure that all values are showing correctly the data.

[kecksk0enig]

sure:

no requeus and dropped is also correct.

[mikaku]

Please, check the latest commit and let me know if it works as expected.

[mikaku]

The new <map> option should be configured as this (following the example above):

<desc>
        eth0 = cbq 1, sfq 10, sfq 20, sfq 30, ingress ffff
</desc>
<map>
        <eth0>
                0 = aaaaaaaa
        </eth0>
</map>

That is, you must specify the device group since the new tc.pm permits monitoring of unlimited number of queues.

[kecksk0enig]

hi, do I have to remove the old graphs in order to seethe change? I have switcht to the latest tc.pem my monitorix.conf

# TC graph
# -----------------------------------------------------------------------------
<tc>
        list = wlan1
        <desc>
                wlan1 = htb 1, pfifo 20, pfifo 21, pfifo 22
        </desc>
        <map>
                <wlan1>
                        0 = overall
                        1 = other
                        2 = torrelay
                        3 = transmission
                </wlan1>
        </map>
        rigid = 0, 0, 0
        limit = 1000, 1000, 1000
</tc>

but after a restart of monitoric the graphs still show htb1 pfifo 20 pfifo 21 pfifo 22

[mikaku]

Please, see my last message that includes an example of how define such values.

[kecksk0enig]

I see no differences between your example and mine? still it lists the raw names like pfifo21

[mikaku]

Make sure you downloaded the very last version because I did a last-second change that could lead the problems you are explaining.

[kecksk0enig]

yes thats it. Now working

[Darioits]

I install monitorix on Raspberry PI, but I'm not able to se any graph on session eth0 Traffic Control statistics

> # TC graph
> # -----------------------------------------------------------------------------
> <tc>
>         list = eth0
>         <desc>
>                 eth0 = cbq 1, sfq 10, sfq 20, sfq 30, ingress ffff
>         </desc>
>         <map>
>            <eth0>
>                  0 = Class Based Queueing
>                  1 = Stochastic Fairness Queueing 10
>            </eth0>
>         </map>
>         rigid = 0, 0, 0, 0
>         limit = 1000, 1000, 1000, 1000
> </tc>

TC command works fine pi@raspberrypi:~ $ tc -s qdisc qdisc noqueue 0: dev lo root refcnt 2 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 2666790 bytes 6620 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc pfifo_fast 0: dev wlan0 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0

[mikaku]

Run the command:

tc -s -d qdisc show dev eth0

and check if any of your queue disciplines (looks like the default ones) appear in the output.

I recommend you to configure Monitorix according with the qdiscs you plan to configure. Regards.

[Darioits]

Hi Jordy, this is the output of command:

tc -s -d qdisc show dev eth0

pi@raspberrypi:~ $ tc -s -d qdisc show dev eth0 qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 19975099 bytes 81628 pkt (dropped 0, overlimits 0 requeues 3) backlog 0b 0p requeues 3

I don't see any stats also other eth0 isnt' strange?

eth0 = cbq 1, sfq 10, sfq 20, sfq 30, ingress ffff

There's others config that I can check? Thank you in advance Dario

2018-04-19 13:20 GMT+02:00 Jordi Sanfeliu notifications@github.com:

Run the command:

tc -s -d qdisc show dev eth0

and check if any of your queue disciplines (looks like the default ones) appear in the output.

I recommend you to configure Monitorix according with the qdiscs you plan to configure. Regards.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mikaku/Monitorix/issues/74#issuecomment-382699332, or mute the thread https://github.com/notifications/unsubscribe-auth/AfXjjXMY5he3IWu2FcifewBK2vtJjAuDks5tqHL4gaJpZM4DT3ql .

[mikaku]

I don't see any stats also other eth0 isnt' strange?

Have you configured the qdiscs you defined in the configuration file?