Numerical Precision in Metrics

[duesser]

I have data of the following structure in Kafka.

{"id": "ABC", "name": "lukas", "timestamp": 1775567475, "payload": 372998479107735.188677, "status": "ok"}

I get it into Splunk using the log2metric_json sourcetype and a HEC Connector via Splunk Connect for Kafka.

When reading the docs about metrices i read about metric indices that it supports precision between 15 and 17 decimal digits. I only seem to be getting 2 however and I can not find anything in props or limits.conf regarding this. Even using "| mpreview" I can verify this.

[tscroggins]

Hi @duesser,

The links in the other responses may cover the detail, but in short, 372998479107735.188677 is outside the precision of a double-precision floating point value when converted to binary:

372998479107735.188677

to binary =>

0100001011110101001100111101011110011101100101010110100101110011

back to decimal =>

372998479107735.1875

The easiest way to maintain precision is probably to store the value as a string and then at search time, perform calculations using custom search commands that reference, e.g., Python decimal or gmpy modules.

[duesser]

Thanks for the reply, this is a very helpful response. Unfortunately, the data is coming in as a metric, so the first command will have to be mstats, where we will loose the precission. I will accept as the correct solution anyways, since i guess this would be the only way to actually handle numbers of such precission.

[bowesmana]

I suspect it's because the number itself has 15+6 digits and the limit applies to the entire string, not just the right hand side. You can see the effect of the number of digits here in this search

| makeresults 
| eval _raw="{\"id\": \"ABC\", \"name\": \"lukas\", \"timestamp\": 1775567475, \"payload\": 372998479107735.188677, \"status\": \"ok\"}"
| spath
| eval len=len(payload)
| foreach 22 21 20 19 18 17 16 15 14 [ eval payload_<<FIELD>>=substr(payload, len - <<FIELD>> + 1) ]
| fields payload_*
| transpose 0 column_name=length
| where match(length, "payload")
| rename "row 1" as payload
| foreach 1 10 100 1000 10000 [ eval mul_<<FIELD>>=round(payload * <<FIELD>>, 6) ]

This creates a number of substrings of your original and then multiplies them by 1, 10, 100, 1000. You can clearly see that multiply by 1 works when the total string length is 16 or below, but above, you start to see loss of precision

[duesser]

I can reproduce the finding by running your query on my instance. I can also confirm, that if i force my data to be "shorter" I do observe higher floating point precission.

Do you also happen to know the root cause and a solution?

[bowesmana]

I recall some info on the Splunk Slack channels referring to the max number supported as 2^53 - 1 - This is IEEE 754 floating point

https://en.wikipedia.org/wiki/IEEE_754

and there is a comment here in item 10

https://help.splunk.com/en/splunk-enterprise/search/spl-search-reference/9.0/search-commands/eval#10...

So, it's very likely your issue.  

Why is it you need such precision on such large numbers and are the numbers to the right of the DP significant in the context of the payload value itself?

I think your solution needs to be a modification of the value in whatever form is practical.

The Slack conversation is here

https://splunkcommunity.slack.com/archives/CD8B6F65Q/p1660068986075899

and there are some possibly explanations there.

[kknairr]

@duesser I guess this has nothing to do with props or limits configuration. Potentially, Add-on could be truncating it. This can be identified from debug logs for the add-on. If not enabled, you could enable it and troubleshoot it further. Particularly, you may look for the serialization errors which could point to this issue. If confirmed, please report this as bug to Splunk itself via support case as this can be fixed in the upcoming version releases.

Ref: Troubleshoot issues with Splunk Connect for Kafka | Splunk Enterprise, Splunk Cloud Platform (last u...

>>

If this post addressed your question, you can:

• Give it karma to show appreciation 👍
• Mark it as the solution if it solved your issue ✔️
• Add a comment if you’d like more details ✏️

Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise.

>>

[duesser]

Researching the other answer i played around with different length numbers and was able to get data with higher precission into splunk. Also i did search through the logs and did not find any serialization issues. Thank you for the input though 🙂