-
Notifications
You must be signed in to change notification settings - Fork 455
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
[query] influxdb write improvements #3373
[query] influxdb write improvements #3373
Conversation
074d0f8
to
5c534ad
Compare
Codecov Report
@@ Coverage Diff @@
## master #3373 +/- ##
==========================================
+ Coverage 56.8% 72.4% +15.5%
==========================================
Files 552 1101 +549
Lines 63077 102840 +39763
==========================================
+ Hits 35857 74498 +38641
+ Misses 24016 23229 -787
- Partials 3204 5113 +1909
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR has been approved for quite a while already. Would there be something required from me to get it merged? |
50dfd4b
to
155cc80
Compare
155cc80
to
3bc2f6c
Compare
What this PR does / why we need it:
For improved performance InfluxDB protocol suggest using
Content-Encoding: gzip
for the line protocol messages. At the moment, for example Telegraf sends InfluxDB output using gzip by default, influxdata/telegraf#8269. The current implementation of the M3 InfluxDB write handler did not support this. This PR adds this capability.Another fix included is specifying the timestamp precision for the timestamp included in the InfluxDB line protocol. InfluxDB client implementations send the precision along with the write requests and if this is not taken into account, the timestamp value is parsed with incorrect value due to the missing precision information.
Also, added fix for handling the case where the HTTP request body is empty.
Special notes for your reviewer:
Does this PR introduce a user-facing and/or backwards incompatible change?:
Does this PR require updating code package or user-facing documentation?: