Spike Network Viewer

[thiagoftsm]

Feature idea summary

After the meet up I began to work again with libpcap to monitor outgoing Network packages, the first part of this spike was already done and I could get all the packages moving from a specific host, now it is necessary to create the rules automatic for libpcap only delivers results when the destination package is another host of the network.

Expected behavior

When this is done, we will have conditions to detect all the hosts that a specific host is communicating inside the network.

[thiagoftsm]

After to read some papers and a talk with @ktsaou , I am discarding the libpcap as a possibility to monitor the sockets and to do Network Viewer based on it.

I am also discarding the possibility to parse /proc/net/tcp and /proc/net/tcp6, due two important motives, the first is the fact that the official documentation ( https://www.kernel.org/doc/Documentation/networking/proc_net_tcp.txt ) says that it is deprecated the second and no less important is an old paper ( https://kristrev.github.io/2013/07/26/passive-monitoring-of-sockets-on-linux ) where the writer had to do something near we will do in Netdata. The author argues correctly that is a problem to work with servers with a big number of sockets opened.

A good example of the tcp_diag interface is the software ss(https://www.cyberciti.biz/files/ss.html) , that uses the same sockets that were described in the links of the previous paragraph.

On FreeBSD it looks like that sockstat is analogous to ss.

[thiagoftsm]

Hi @ilyam8 ,

Did you already work with a software different of ss to monitor opened sockets on Linux?

Best Regards!

[amoss]

Some comments from the meeting about the Network Viewer, I'll leave them here although the issue is closed as a record - they may apply to the work in PR#6958.

1. There are several different technical decisions to make about how to send the network socket status to the cloud. But these decisions depend largely on the target use-cases for the Network Viewer. Working on refining the use-cases for the Network Viewer first (user stories?) would be useful to guide these technical decisions.
2. The decisions about what data to send, how to send it (e.g. should it be polled every second and send a view of currently established sockets, or should it send open/close events to match the interface in the AF_NETLINK) can be better decided with a view of the target interface to the cloud (e.g. it comes up in the Groom on Friday).
3. Sending the raw binary socket info is not guaranteed to be stable across all nodes - and the ntop() calls are inexpensive. If bandwidth is a concern then the connection could be compressed (e.g. zlib).