这是一个创建于 2270 天前的主题，其中的信息可能已经有所发展或是发生改变。
一直在找一款任意形式可以查看 Linux 端口流量消耗统计程序。
有个大前提：
- 不能基于 iptables （别问为什么，业务如此）
- 支持 CentOS 7
然后前前后后翻遍了谷歌各种关键字，github 也翻了好几遍，目前能找到最接近的是 2 款。
其一、Ntopng
这款在线监控可以很容易部署网页版，但是只提供端口流量占用排行，不提供具体流量统计，而且除此之外的功能全部用不上，并且实际测试发现不是很稳定，重启或者崩溃后历史数据全部丢失。
其二、Flowmon
这款也是在线监控，目前还不支持部署到 KVM 机器中，但是提供了端口流量占用及排序，完全符合需求。 有兴趣可以看一下官网的 demo。
https://demo.flowmon.com/fmc/analysis/
账号密码都是：demo
想请教各位大佬，有没有能满足这个需求的解决方案？
 |
1
sbw 2018-08-23 16:39:04 +08:00
换个桌子啊，nftables （
|
 |
2
DearTanker OP @sbw #1 忘了说，只能用 Firewalld 呢。。。
|
 |
3
innoink 2018-08-23 16:47:42 +08:00 via Android
借楼问一问，有没有能统计本地各进程网速流量的工具？
|
|
4
DearTanker OP 忘了补充了，不是 iptraf 这种实时统计的指令，这些网络监控指令大大小小基本全都试过了，没办法让后台运行进行统计。。
|
|
5
DearTanker OP @innoink #3 貌似这种的还是很多的。。支持 windows。
|
|
6
innoink 2018-08-23 16:52:08 +08:00 via Android
@DearTanker linux 里面好像还没见过
|
 |
7
xiaoz 2018-08-23 16:59:13 +08:00
和楼主有相同的需求，google 和 github 搜了几遍，试了好几个都达不到效果。
|
|
8
DearTanker OP @innoink #6 实时的有大把，统计的我也没见过。
|
|
9
DearTanker OP @xiaoz #7 目前为止，清一色的基于 iptables。。
|
 |
10
jasonyang9 2018-08-23 17:05:47 +08:00
firewalld 不就是 iptable 套了个壳么
|
|
11
DearTanker OP @jasonyang9 #10 但是并没有办法支持统计流量的对应参数。翻过文档了。
|
 |
12
Phant0m 2018-08-23 17:16:04 +08:00
FakeNet-NG 了解一下？
|
|
13
DearTanker OP @Phant0m #12 貌似只能一个个端口添加到配置文件中，这样如果端口有几百个。。。。
|
|
14
Phant0m 2018-08-23 17:33:51 +08:00
@DearTanker 可以找找基于 PF_RING 的一些网络监控工具
|
 |
15
angryRabbit 2018-08-23 19:11:58 +08:00  3
其实我也找这个工具很久了，一直没有发现。大多数都是进程自己统计自己流量，比如 apache 有这个功能。能不能进程外统计呢？
我有个思路，可以自己实现试一下。 + 自己实现一个进程，叫 confiner。confiner 监听 80、443 等端口。 + confiner 将流量转发到 60080、60443 端口。confiner 可以进行流量统计、流量监听。 + 其实这就是 iptables 的 user-space 版。区别是：iptables 工作在网络层，这个程序工作在传输层。 + 实现难易度：容易。易用性：不易用 思路 2： + 为什么 kernel 可以统计每一个 eth interface 的流量？就是因为 kernel 的计数单位是 eth interface。 + 给每一个要监控的进程都创建一个 eth interface，就可以了。 + 但是，eth interface 可能收到广播，广播不能算发送给进程的数据包。所以 interface rx 肯定大于实际用量 + 实现难易度：容易。易用性：不易用 楼主的问题是“所有进程”。这个问题就有点困难了，感觉必须要改动 kernel 的源码，可以看看现在的 android 是怎么实现的。经过冥思苦想，又想到了下一个思路： 思路 3： + 实现自定义的 glibc，然后覆盖系统提供的 glibc。在 glibc 中修改可以一次性把所有进程都改了。 + 原理：socket 是 system call。system call 是内核实现的，但怎么从 user-space 切换为 kernel-space 呢？肯定需要配置 cpu stack、然后执行某个 CPU instruction，而 libc 已经做好了这一切。所以调用 system call 实际调用的都是 libc。 + 每次收到数据包都先记录在内存中，当 rx 或 tx 超过 10KB 写入到一个文件，然后 user-space 进程取读取这个文件。 + 实现难易度：容易。易用性：易用 |
 |
16
bobyang 2018-08-23 19:51:18 +08:00 via Android
谢谢，很不错啊！试试吧
|
|
17
DearTanker OP @angryRabbit #15 我应该说的是统计指定端口范围 /指定端口的流量，不是指某些进程。
其实 ntopng 可以做到统计端口流量的，只不过貌似这个工具的重心不在这边。 ntopng 是基于 tcpdump 中的 Libpcap 来进行包解析的，但是我通过 Libpcap 来查询相关的工具，也没有找到统计 tcp 端口流量的工具。 |
|
18
DearTanker OP @Phant0m #14 谢谢，找找看。
|
 |
19
phoenixlzx 2018-08-23 20:18:43 +08:00
我觉得已经猜到你要做什么了。
不过，你找的这些工具都是分析骨干网络流量的，不是分析系统流量的。Linux 系统内能实时看端口流量的比如 nethogs? 但是也没法生成统计报表。 所以建议你直接去把这功能做到你要用的程序里。 |
 |
20
hailinxyz 2018-08-23 20:25:09 +08:00 via Android
我前两天也在研究这个
我的是两个方案 iptables 和 tcpdump 比较了一下 好像还是 iptables 好 和 zabbix 出图还行 看端口速率和总流量 tcpdump 要一直监听所有包 占系统资源 不过通过 tcpdump 解析包来计数应该可以达到你的目的。 |
|
21
hailinxyz 2018-08-23 20:26:59 +08:00 via Android
@phoenixlzx 好思路
|
|
22
DearTanker OP @hailinxyz #20 有想过，就是按照这个找遍了天涯海角，也没看到相关链接。
|
|
23
innoink 2018-08-23 22:22:34 +08:00 via Android
@DearTanker 比如说 nethogs?但是这个是基于 pcap，容易吃 cpu
|
 |
24
Judoon 2018-08-23 22:58:20 +08:00 via Android
如果找不到好的工具，我觉得你的思路可以转变一下。用容器来隔离每个程序，然后统计每个容器的网络情况就行了。
说白了其实就是 k8s 配普罗米修斯那一套。 |
|
25
Judoon 2018-08-23 23:02:27 +08:00 via Android
ntopng 之前玩过，主要的应用场景是旁路布署在核心网络上，镜像转发所有流量过来后，能可视化整个网络的流量情况
|
 |
26
ksharp8 2018-08-23 23:07:25 +08:00
有基于 web 版的 cacti 或 zabbix
|
|
27
DearTanker OP @innoink #23 只能实时，没法用于统计吧。
|
|
28
DearTanker OP @ksharp8 #26 貌似这 2 款，如果要监控端口的话，必须一个个手动指定。
|
 |
29
liangzi 2018-08-24 05:20:53 +08:00 via Android
iftop 命令 试一下 指定接口加个输出参数写到指定文件里面后台运行。。。
|
 |
30
josephshen 2018-08-24 10:22:39 +08:00 via iPhone 1
angry rabbit 的思路三我觉得很好啊。hack libc，修改里面的 read 和 write 函数，记录下端口对应的句柄，而且可以针对特定的应用程序，在加载 libc 的之前选择是否是 hack 后的 libc，缺点是静态链接的程序就不行了。我记得前一段时间论坛里有一个给指定程序做代理的方案，就是在 Windows 下通过拦截读写函数的。
|
 |
31
Rehtt 2018-09-03 07:42:23 +08:00 via Android
读取 /proc/net/dev 文件呢
|
 |
32
fuge 2018-09-03 09:28:57 +08:00
netdata
|
|
33
DearTanker OP @Rehtt #31 你这个还是总流量啊。注意审题。。
|
 |
34
reus 2018-09-15 18:01:53 +08:00
systemtap，sysdig
|
Select Language