This changes the current use of the InfluxDB client to instead use a
baked-in client that uses the fasthttp library.
This allows for significantly smaller allocations, the re-use of http
body buffers, and the re-use of the actual bytes of the line-protocol
metric representations.
We were having problems with telegraf talking to
carbon-relay-ng using the graphite output. When
the carbon-relay-ng server restarted the connection
the telegraf side would go into CLOSE_WAIT but telegraf
would continue to send statistics through the connection.
Reading around it seems you need to a read from the connection
and see a EOF error. We've implemented this and added a test
that replicates roughly the error we were having.
Pair: @whpearson @joshmyers
If we write a batch of points and get a "field type conflict" error
message in return, we should drop the entire batch of points because
this indicates that one or more points have a type that doesnt match the
database.
These errors will never go away on their own, and InfluxDB will
successfully write the points that dont have a conflict.
closes#2245
doing this unblocks incoming metrics while waiting for a flush to take
place.
we have to create a semaphore so that we can
'skip' flushes that try to run while a flush is already running.
closes#2262
* Added GatherUserStatistics, row Uptime in gatherGlobalStatuses, and version fields & tags
* Updated README file
* pulling in latest from master
* ran go fmt to fix formatting
* fix unreachable code
* few fixes
* cleaning up and applying suggestions from sparrc
I don't like this behavior, but it's what InfluxDB accepts, so the
telegraf listener should be consistent with that.
I accidentally reverted this behavior when I refactored the telegraf
metric representation earlier in this release cycle.
* Fix for broken librato output
These errors are delightful, but I'd rather avoid them:
```
Error parsing /etc/telegraf/telegraf.conf, line 2: field corresponding to `api_user' is not defined in `*librato.Librato'
```
* Fixed bad format from last commit
this basically reverts #887
at some point we might want to do some special handling of reloading
plugins and keeping their state intact, but that will need to be done at
a higher level, and in a way that is thread-safe for multiple input
plugins of the same type.
Unfortunately this is a rather large feature that will not have a quick
fix available for it.
fixes#1975fixes#2102