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

OpenTSDB output plugin broken when host is given without scheme #2299

Closed
alfredkrohmer opened this issue Jan 23, 2017 · 4 comments
Closed

OpenTSDB output plugin broken when host is given without scheme #2299

alfredkrohmer opened this issue Jan 23, 2017 · 4 comments
Milestone

Comments

@alfredkrohmer
Copy link

alfredkrohmer commented Jan 23, 2017

In this code line, url.Parse is used to parse the given host string. If this string does not contain a scheme (e.g. google.com instead of tcp://google.com), u.Host is an empty string and the connect fails.

Bug report

Relevant telegraf.conf:

[[outputs.opentsdb]]
 prefix = "telegraf."
 host = "google.com"
 port = 4242

System info:

  • Telegraf version 1.1.2

Steps to reproduce:

Provide a host without a scheme to the OpenTSDB output plugin.

Expected behavior:

The plugin should be able connect to the host.

Actual behavior:

The connection fails with: Failed to connect to output opentsdb, retrying in 15s, error was 'OpenTSDB: Telnet connect fail'

@phemmer
Copy link
Contributor

phemmer commented Jan 23, 2017

On the larger scope of the issue, it would be really nice if telegraf were consistent in its naming of such parameters. Right now it's all over the place. Some parameters are called "url" and take a host, some parameters are called "host" and take a url. Others are called "address" and take a url, or host, etc.
Then you have other examples like this one, where they take a url, but parameters that are able to be placed in the url are instead configured separately (e.g. port).

@sparrc
Copy link
Contributor

sparrc commented Jan 23, 2017

@phemmer that would be better, but would also be a breaking change at this point :(

@sparrc sparrc added this to the 1.2.0 milestone Jan 23, 2017
sparrc added a commit that referenced this issue Jan 23, 2017
@alfredkrohmer
Copy link
Author

Also, the error message is not really helpful. Maybe the error returned from DialTCP can be returned instead of that generic error message?

@sparrc
Copy link
Contributor

sparrc commented Jan 23, 2017

I will add the error message in as well

sparrc added a commit that referenced this issue Jan 23, 2017
@sparrc sparrc closed this as completed in c15504c Jan 23, 2017
sparrc added a commit that referenced this issue Jan 23, 2017
njwhite pushed a commit to njwhite/telegraf that referenced this issue Jan 31, 2017
maxunt pushed a commit that referenced this issue Jun 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants