Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[network] Tag sockets states with process name #2375

Closed
mausch opened this issue Mar 22, 2016 · 3 comments
Closed

[network] Tag sockets states with process name #2375

mausch opened this issue Mar 22, 2016 · 3 comments
Labels
Milestone

Comments

@mausch
Copy link

mausch commented Mar 22, 2016

It would be great if we could tag sockets with the PID / process name of their owner. This would make it easier to track down socket leaks. At the moment we only get system-wide socket usage which means we can see a socket leak but we don't have the information to pinpoint which process is causing it.

In Windows, you can get process information by adding the -b flag to netstat (that is, after you apply #2352)

In Linux, both ss and netstat support the -p flag to get process info.

No idea about the other platforms but I'm guessing they have similar flags.

@olivielpeau olivielpeau added this to the Triage milestone Apr 29, 2016
@olivielpeau
Copy link
Member

Hi @mausch, and thanks for opening this issue!

On Linux, one problem I'd see with pulling the PID from netstat/ss is that the agent would need to use them as root to collect the PIDs of processes not owned by the dd-agent user.

That said we'll assess what could be done to work around this limitation.

@olivielpeau
Copy link
Member

Also, tagging metrics by PID or process name wouldn't scale well. A better solution would be to have the process check collect the number of open sockets for the processes that it monitors.

The issue of the permissions needed to collect the information would remain. Maybe an approach similar to what's described in #853 would work.

@remh
Copy link
Contributor

remh commented Jun 24, 2016

Yes, it's unlikely we'll implement this for the reasons described by @olivielpeau so i'm going to close this issue for now.

@remh remh closed this as completed Jun 24, 2016
@remh remh added the wontfix label Jun 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants