Influxdb2Writer stores very small float perfdata values as 0

Icinga 2
1

Hi,

I’m running Icinga 2 r2.14.2-1 on Debian 11 with Influxdb2Writer sending perfdata to InfluxDB v2.

I have a custom check plugin (check_prometheus_timesync) that outputs perfdata with very small float values representing time offsets in seconds, for example:

OK: source=sfptpd offset=4.56ns | source_is_sfptpd=1 source_is_chrony=0 source_is_ntpd=0 offset_seconds_sfptpd=-0.000000004562;0.0000003;0.0000005 offset_seconds_chrony=0.000000269;0.3;0.5

The perfdata format is fully compliant with the Nagios Plugin Development Guidelines - Official Documentation :

  • Value uses only characters from [-0-9.] (no scientific notation)
  • UOM is s (seconds), which is one of the explicitly allowed units
  • No letters or special characters in the value itself

The Icinga2 API confirms the values are parsed correctly internally:

json

"performance_data": [
    "offset_seconds_sfptpd=-0.000000003375;0.0000003;0.0000005",
    "offset_seconds_chrony=0.000000315;0.3;0.5"
]

However, when querying InfluxDB, all offset values are stored as 0 (or -0):

offset_seconds_sfptpd = 0
offset_seconds_chrony = -0

I verified this is not a display/rounding issue in the InfluxDB Data Explorer by multiplying values by 1000000000000.0 in Flux - still 0.

What I’ve tried:

  • Originally used scientific notation (-1.1125e-08s) - Icinga UI showed 0.00, so I switched to fixed-point decimal (-0.000000011125)

  • Removed the s UOM suffix - thresholds now show correctly in Icinga UI, but values still stored as 0 in InfluxDB

The values are in the nanosecond range (1e-9 to 1e-5 seconds). It seems like Influxdb2Writer loses precision when serializing these to InfluxDB line protocol.

Questions:

  1. Is this a known limitation of Influxdb2Writer with very small floats?

  2. Is there a workaround other than scaling values to a larger unit?

Thanks

2

Exactly. Just open icinga2 console and enter your 0.000000315. It will round it to 0.000000.

3

I see, thank you for the confirmation.
I assume there is no plan to change this behaviour?
Fortunately, I have this data available in prometheus anyway.