On 7/9/21 4:27 am, jacraig@vcu.edu wrote:

I am currently out of the office, but plan to return to my desk on Tuesday, September 7, 2021 at 7am. ...

Hmm - Simon predicted this would happen not too long ago!!!

@Simon, please share that crystal ball!

On Mon, 6 Sept 2021 at 14:24, Anand Buddhdev anandb@ripe.net

...

On 06/09/2021 19:35, Kaushal Shriyan wrote:

Hi Kaushal,

...

I am running CentOS Linux release 7.9.2009 (Core). Is there a way to find out which process consumed network bandwidth during a specific time period?

For example, the Nginx process consumed how much network traffic on Sept 01, 2021.

As far as I know, such accounting isn't done in a standard CentOS system, so there's no way to determine such information about a past event

Kaushal,

While you probably can't recover such information for past events, going forward, iptables can help you figure this out. Putting an IPtables rule in the OUTPUT table prior to ACCEPTing the packets can help, e.g.:

iptables -A OUTPUT -p tcp -m owner --uid-owner nginx -j ACCEPT

because now "iptables -L" will display a count of the packets that matched each rule and the number of bytes. By comparing with the total packets and bytes for a given time period, you can work out the share for nginx. You can also estimate packet and byte counts by IP and port using this method. You could run an hourly cronjob to log the stats.

See "man iptables-extensions" and "man iptables". I don't know how this works with firewall-cmd, but I imagine firewalld "just" manages iptables?

Good luck!

On 9/13/21 18:47, MRob wrote:

While you probably can't recover such information for past events,

...

going forward, iptables can help you figure this out. Putting an IPtables rule in the OUTPUT table prior to ACCEPTing the packets can help, e.g.:

iptables -A OUTPUT -p tcp -m owner --uid-owner nginx -j ACCEPT

OUTPUT and "-m owner" are only going to work for outgoing connections, initiated by nginx, which probably isn't much for most systems that aren't reverse proxies.

Most of the time, if you want iptables to track the amount of traffic for a specific service, you'll need one or more rules inserted at the beginning of the INPUT chain, before the typical first rule that allows RELATED and ESTABLISHED packets.  You could have one rule that allows all traffic to the service port (a stateless rule), or you could have one rule that allows ESTABLISHED traffic to the service port and one that allows NEW,UNTRACKED traffic to the port (stateful rules)

That is nice solution! Why do you add a new output rule rather you can look at the existing port rule:

# iptables -v -L | grep https xxx yyy ACCEPT     tcp  --  any    any     anywhere anywhere             tcp dpt:https ctstate NEW,UNTRACKED

xxx is number packets, yyy is number bytes. If adding OUTPUT rule, what is gained?

Because the rule you're looking at only matches NEW and UNTRACKED packets, so it's usually only a record of the TCP SYN packets that initiated connections.  If you want a byte count of the traffic for that service, this rule won't provide that.  The nginx logs are the most detailed and usually the most useful record of traffic used, but accounting through iptables is also an option.

Though, if you're interested in the sort of less detailed logs that you'll get from iptables, then I'd suggest what you want might be NetFlow data: https://www.linuxnetflow.com/