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

Support a native ping #2833

Closed
phemmer opened this issue May 20, 2017 · 5 comments · Fixed by #6050
Closed

Support a native ping #2833

phemmer opened this issue May 20, 2017 · 5 comments · Fixed by #6050
Assignees
Labels
feature request Requests for new plugin and for new features to existing plugins
Milestone

Comments

@phemmer
Copy link
Contributor

phemmer commented May 20, 2017

Feature Request

Proposal:

It would be nice if telegraf could perform a ping natively instead of having to call out to the external ping utility. This could be accomplished by using either CAP_NET_RAW or ICMP sockets. Telegraf could do a one-time probe at start to determine whether either of the two are functional, and fall back to external ping if not.

CAP_NET_RAW has the advantage that it can be set by the package during installation, and not require manual setup by the user. The disadvantage is that it's limited to Linux.

ICMP sockets are functional on Linux & FreeBSD, but require manual setup by the user on Linux (not sure about FreeBSD).

Current behavior:

Telegraf calls external ping utlity.

Desired behavior:

Telegraf sends ICMP echo request & reads ICMP echo response itself.

Use case:

For systems which send a large number of pings, such as probing a large number of devices, or sending pings at a high rate, or both, the external ping utility can be a drain on resources.

@phemmer
Copy link
Contributor Author

phemmer commented May 20, 2017

Continuing from discussion here: #2830 (comment)

What are the drawbacks of the setcap approach? I don't really have a problem with requiring the user to do this before using it. How would things work on BSD, Mac, Windows? Is setcap sufficient if you are using apparmor, selinux, etc?

We must have thought about this before: https://github.com/sparrc/go-ping

Well as long as we keep external ping an option, the only drawback I see is having 2 code paths.
Capabilities are limited to linux, so they're not portable. But one major benefit is that the capabilties can be set on the telegraf binary by the package. Meaning the user would not have to do it.
I'm not sure about selinux, but I assume it will interfere. But I can't see how it would even be possible to have an selinux policy enforcing on telegraf, at least not a generic one. It does so much probing of the system, and so much behavior is defined by the user, that it's just not feasible. If anyone does have a policy, then it's something they've built by hand, and as they would expect, any time they upgrade telegraf, or change the config, they'd have to adjust the policy.

@danielnelson
Copy link
Contributor

Adding support for an internal ping sounds fine.

What if we got rid of external ping, is it even a possiblility? Managing the differences between platforms is quite difficult.

@sparrc Do you think it would make sense to use your library?

@sparrc
Copy link
Contributor

sparrc commented May 21, 2017

You could do it but I don't think it's ever been tested on windows, and requires additional configuration on linux.

The ping binary comes with setuid bits set which gives it permission to bind raw ICMP sockets without using root. So users would need to understand this and give the telegraf binary cap_net_raw capabilities (or use setuid) like here: https://github.com/sparrc/go-ping#note-on-linux-support.

That, or you could potentially give telegraf that capability by default, although I'm not sure what the other consequences of that would be.

@efficks
Copy link
Contributor

efficks commented Feb 9, 2018

An other problem is the current implementation does not support internationalisation. It only works on English OS, Windows and Linux included.

@danielnelson
Copy link
Contributor

That's a good point, maybe we could run ping with LANG=C as a stopgap?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Requests for new plugin and for new features to existing plugins
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants