¿Cómo detecto el tráfico de red por proceso y por conexión en Linux?

No hay una respuesta fácil aquí.

Puede mirar la salida de ‘ netstat -penet ‘ para aprender algo de lo que tal vez quiera saber.

La columna 7 tiene el ID de usuario. ‘ netstat -peet ‘ y verás el nombre de usuario. Sin embargo, no recomiendo omitir -n porque sin él su netstat incurre en una sobrecarga de búsqueda de DNS, que puede ser considerablemente especial cuando la IP no tiene nombre.

La columna final, 9, tiene el PID / Nombre del proceso; lamentablemente, no veo una manera de obtener solo el PID. Entonces tendrías que usar, por ejemplo,

netstat -penet | grep 2219 /

… para ver las conexiones para el proceso ID 2219.

Sin embargo … lo anterior no te llevará demasiado lejos. Puede ver cuántas conexiones hay y de dónde provienen, pero no cuántos datos están moviendo.

Por defecto, Linux no mantiene muchas estadísticas que involucran una sobrecarga de paquete por paquete, ya que estas incurrirían en demasiada sobrecarga dentro de la pila TCP / IP. Además … para muchos de los paquetes, la “respuesta correcta” sobre qué registrar / acumular variaría la opinión del usuario final por la opinión del usuario final. ¿Están interesados ​​los usuarios finales en rastrear el tamaño del paquete completo o solo la porción de datos? ¿Qué tal los paquetes duplicados? ¿Contarlos dos veces o no? ¿Qué tal para los paquetes que se caen por la pila? ¿Cuentan o no? Etc.

Como tal, no hay datos de “tráfico total para este proceso”, ni datos de “tráfico total para este usuario”, ni datos de “tráfico total para esta conexión de red” que se están registrando.

A menudo, los firewalls pueden rastrear la cantidad de veces que las ACL particulares permiten que los paquetes pasen a un puerto en particular. Entonces, si tiene un firewall de hardware frente al servidor, es posible que desee ver cómo puede hacer que rastree el tráfico total a un puerto en particular para usted.

Del mismo modo, PUEDE hacerse a través de iptables, pero no me pregunte cómo.

Nada en Linux básico está rastreando el rendimiento por puerto – “velocidad de transferencia” – para usted. Tendría que instrumentar eso directamente dentro del servicio web (<- MI RECOMENDACIÓN), o usar algo como tcpdump o alguna otra monitorización intrusiva de la red para generar datos a partir de los cuales pueda calcular las estadísticas.

No recomendaría seguir la ruta de “monitoreo intrusivo de la red” a menos que el servidor SOLO entregue este servicio en particular, ya que afectará la calidad del servicio para todos los servicios de red en el servidor cuando se ejecute.

Y … si ese es el caso (el único servicio de red en el servidor es el que está ejecutando), entonces puede “engañar” y usar los números RX / TX totales de eth0.

[correo electrónico protegido] : ~ # echo -n `fecha`; netstat -i | grep eth0 | awk ‘{print” “$ 4” “$ 8}’
Jue 28 feb 17:24:39 CST 2013 315225 122047
[correo electrónico protegido] : ~ # echo -n `fecha`; netstat -i | grep eth0 | awk ‘{print” “$ 4” “$ 8}’
Jue 28 feb 17:24:48 CST 2013 315242 122052
[correo electrónico protegido] : ~ # echo -n `fecha`; netstat -i | grep eth0 | awk ‘{print” “$ 4” “$ 8}’
Jue 28 feb 17:24:51 CST 2013 315250 122056

Con un trabajo cron que descarga el tiempo, RX y TX cuentan los registros en un archivo de registro, siempre que conozca el tamaño del paquete de su aplicación, puede calcular de manera bastante confiable sus rendimientos actuales. O puede obtener bytes reales usando ‘ cat / proc / net / dev ‘ pero el grepping / awking es un poco más complejo allí ya que no hay espacio después del primero: (cat el archivo para ver a qué me refiero)

TAMBIÉN – “sar” (si lo tiene instalado) puede estar rastreando sus interfaces rx y paquetes de tx por segundo, pero nuevamente eso no es por puerto.

“iftop” (tendría que instalarlo) muestra, como “top”, las estadísticas de tráfico de la red; sin embargo, puede que no sea trivial extraer esas estadísticas mediante programación.
iftop: muestra el uso de ancho de banda en una interfaz

También he escuchado cosas buenas sobre iptraf-ng pero no lo he usado yo mismo. Todavía.

netstat es una gran herramienta, pero con mayor frecuencia termino usando lsof que enumera todos los descriptores de archivos abiertos, y también muestra los sockets de red y el destino remoto.

Realmente no conozco las API del kernel para detectar y contabilizar el socket de red, aparte de usar iptables, estoy bastante seguro de que puedes contabilizar un proceso específico. Pero el de coures requiere acceso de root.

Otra forma es usar algunas pruebas de kernel, como systemtap pero lo mismo de nuevo, requiere root.

Es posible conectarse al kernel de la misma manera que strace (o gdb), conectándose a un sistema de llamadas pid y tapping realizado por esta aplicación. Intenta usar strace y podrás ver qué información podrás tocar. No estoy seguro si esto necesita root o no. En los núcleos reenviados solo se permite en la misma “sesión” que la aplicación.

Otra solución es hacerlo en el espacio de usuario y crear una biblioteca probe.so shared, cárguela antes de que su aplicación use
$ env LD_PRELOAD =. / probe.so ./my-app

En esta biblioteca, anulará libc accept, send, recv, close y otros que guardan estadísticas antes de enviarlo a libc. Entonces es posible agregar un hilo / fork con memoria compartida que será consultada por su herramienta.

Las aplicaciones como iptraf hacen lo que quieres, monitorea los sockets abiertos, no sé realmente qué api usa a continuación, pero strace iptraf podría darte una idea. No estoy seguro de que pueda conectar esos sockets abiertos al proceso en ejecución o no …

Espero que esto responda tu pregunta.

/Palanqueta

Vincula tu servicio a una interfaz de red específica, donde ese servicio es el único proceso que se ejecuta en esa interfaz. Debería poder usar un iface virtual como eth0: 1.

Luego puede obtener estadísticas desde arriba o desde ifconfig.

Alternativamente, si está usando Apache para servir el servicio como proxy, puede escribir un complemento en C y registrar las estadísticas que necesite en un rrd o algo así.

O podría escribir un proxy directo (como inetd) que representa el tráfico de su servicio y registrar lo que necesite. Me sorprendería si inetd no tiene lo que necesita sin demasiado trabajo.