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

http_listener service plugin does not respect precision #2637

Closed
kostasb opened this issue Apr 7, 2017 · 4 comments
Closed

http_listener service plugin does not respect precision #2637

kostasb opened this issue Apr 7, 2017 · 4 comments

Comments

@kostasb
Copy link

kostasb commented Apr 7, 2017

Telegraf v1.2.1

Issue: the http_listener plugin does not accept configurable precision, only assumes ns.
Also, outputs.influxdb only writes ns.

The result is that points with a precision other than ns writen through inputs.http_listener land in the wrong time.

Repro case:

-Setup a telegraf agent applying the following config:

[[inputs.http_listener]]
   service_address = ":8186"
   read_timeout = "10s"
   write_timeout = "10s"
   max_body_size = 0
   max_line_size = 0

[outputs.influxdb]]
  urls = ["http://localhost:8086"] # required
  database = "telegraf" # required
  retention_policy = ""
  write_consistency = "any"
  timeout = "5s"

-Submit a point with precision other than ns to Telegraf's http input listener:

curl -v "http://localhost:8186/write?db=test&precision=ms" --data-binary "test value=1i 1491601527552"

-Check the timestamp written for this point in InfluxDB:

> select * from test
name: test
time                           host   value
----                           ----   -----
1970-01-01T00:24:51.601527552Z ubuntu 1
@kostasb
Copy link
Author

kostasb commented Apr 7, 2017

Related to and subset of: #1589

@danielnelson
Copy link
Contributor

danielnelson commented Apr 7, 2017

Found this as well #2359

I don't agree though with the conclusion on that ticket, http_listener is very specific to InfluxDB so I see no reason not to support precision.

@danielnelson
Copy link
Contributor

We don't support the db parameter here either, this probably shouldn't change because the output defines it.

@danielnelson
Copy link
Contributor

Implemented in #2644

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

No branches or pull requests

2 participants