-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Telegraf should log if InfluxDB returns a 400 #16386
Comments
It turns out the repo above isn't as helpful as intended. Although it generates a 400, the response body is different because it's complaining about not being able to parse the LP. In #16380 the response body was
The existing handling appears to be in support of Partial writes |
I was able to confirm in my testing of #16388 that telegraf is now logging the 400. See #16350 (comment):
To be extra sure, I modified the 'server' script:
To reproduce:
Using the telegraf binary from PR #16388, it now logs the 400:
|
Use Case
Upstream InfluxDB servers will return a
HTTP 400
status code if there some kind of issue with the request (usually, but not always) something to do with the format of the line protocol.In #16380 it wasn't clear that InfluxDB was rejecting the writes, because Telegraf claimed that the metrics had been written successfully
Note: Whilst trying to build an easy repro for this ticket I noticed that it also doesn't log if a 404 is returned (usually indicating the specified bucket doesn't exist)
As a somewhat contrived example for reproing, we can force a 400 by telling Telegraf to gzip the request body and then overriding the
Content-Encoding
header with an invalid valueThis will cause an InfluxDB2 upstream to return a 400:
Expected behavior
Telegraf should log that an error was received
Actual behavior
Telegraf reports that the batch was written
Additional info
No response
The text was updated successfully, but these errors were encountered: