Inserted 'NaN' values are stored as zero in samples_v3

[mat3733]

To reproduce:

in your promwrite.sh test script :
go run main.go -u http://localhost:3100/api/v1/prom/remote/write -t name:foobar -d $dd,NaN

The 'NaN' string is properly parsed into Float64 by the promremotecli go client
but still ended up as a zero value in samples_v3.

[lmangani]

Thanks for the report @mat3733 we'll look into after this and find a solution

[akvlad]

@mat3733
qryn 3.0.28 will filter out all the NaN values. feel free to update.

[mat3733]

Thanks for your quick reactivity but actually, you have done the exact opposite of what we need.
My issue description was not clear, I'm sorry for this.

For our needs, 'NaN' values are very important to be kept in our metrics database.
It means that the device we're collecting metrics from has been down.

In the initial issue, I was complaining that the 'NaN' values were converted to zero values (which can be a real value for a metric).
I think it would be more useful if the 'NaN' values were properly inserted in the Clickhouse database (which supports them for a Float64 value).

[mat3733]

Closed by mistake. Please consider previous message.

[akvlad]

Well, NaN values are questionable about how to work further.
max_over_time(metric_with_NaNs[10m]) how to process this kind of metrics
how to represent NaNs in a chart.

If a device stops producing anything, you can figure it out with absent_over_time function. I need some investigation of how to treat NaN values correctly.

[mat3733]

Indeed, our specific usage of NaN may be doubtful but still : inserting 0 instead of 'NaN' or ignoring inserts with NaN is kind of a bug.

[akvlad]

@mat3733
qryn 3.0.29 will write the NaN values as NaN into the samples_v3 table. Feel free to update

[mat3733]

I've tested version 3.0.29 and it works as intended, 'NaN' appears in the Clickhouse DB.
Thanks a lot for your listening and reactivity.

[akvlad]

Closing the issue then.
Thanks for the participation.