Client-side skipping of NaN values

[piotrp]

A bit related to #537, but instead of validation I'd like to propose skipping NaNs to silence Telegraf/InfluxDB logs - they can't be reliably filtered, and some libraries (i.e. Kafka) use NaNs in their metric values.

Currently InfluxDB treats NaNs as invalid input, performs partial write and logs a warning. InfluxDB#write finishes with InfluxDBException.UnableToParseException.

I'd like to discuss having an option to silently drop invalid points during writes, or a clarification that clients shouldn't pass invalid values to points, so that logging in Apache Flink (apache/flink#8513) can be fixed in some way.

[afausti]

hey @Crack thanks for implementing this.

I think dropping fields that have 'NaN' or 'Inf' before writing to InfluxDB is the right thing to do. Valid fields in the same point are still recorded, and when we retrieve the data from the corresponding measurement InfluxDB will return None for the missing field.

I had this problem recently using Kafka + Landoop InfluxDB Sink connector.

org.influxdb.InfluxDBException$UnableToParseException: partial write: unable to parse 'lsst.sal.ATDome.logevent_azimuthCommandedState ATDomeID=1i,azimuth=\ufffd,commandedState=1i,priority=0i,private_host=1994757124i,private_kafkaStamp=1567888128.2887785,private_origin=32i,private_rcvStamp=1567888127.9708674,private_revCode=\"5544b90a\",private_seqNum=1i,private_sndStamp=1567887306.2843742 1567888091465571857': invalid boolean dropped=0

I think the Landoop InfluxDB Sink connector uses influxdb-java so I am about to test your fix ;)
Also, I found the invalid boolean message misleading.