* Procstat: don't cache PIDs
Changed the procstat input plugin to not cache PIDs. Solves #1636.
The logic of creating a process by pid was moved from `procstat.go` to
`spec_processor.go`.
* Procstat: go fmt
* procstat: modify changelog for #2206
* Procstat: don't cache PIDs
Changed the procstat input plugin to not cache PIDs. Solves #1636.
The logic of creating a process by pid was moved from `procstat.go` to
`spec_processor.go`.
* Procstat: go fmt
* procstat: modify changelog for #2206
* ceph: maps are already refs, no need to use a pointer
* ceph: pgmap_states are represented in a single metric "count", differenciated by tag
* Update CHANGELOG
* ceph: maps are already refs, no need to use a pointer
* ceph: pgmap_states are represented in a single metric "count", differenciated by tag
* Update CHANGELOG
* Add in support for looking for substring in response
* Add note to CHANGELOG.md
* Switch from substring match to regex match
* Requested code changes
* Make requested changes and refactor to avoid nested if-else.
* Convert tabs to space and compile regex once
* Add in support for looking for substring in response
* Add note to CHANGELOG.md
* Switch from substring match to regex match
* Requested code changes
* Make requested changes and refactor to avoid nested if-else.
* Convert tabs to space and compile regex once
* Make Logparser Plugin Check For New Files
Check in the Gather metric to see if any new files matching the glob
have appeared. If so, start tailing them from the beginning.
* changelog update for #2141
* Make Logparser Plugin Check For New Files
Check in the Gather metric to see if any new files matching the glob
have appeared. If so, start tailing them from the beginning.
* changelog update for #2141
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.
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
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
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
