Support for floating point types are missing

[rolandjohann]

As far as I can see all metrics only provide Long arguments. Is there any reason for this?

[rolandjohann]

Yust to clarify things: Is there any maintainer on this project? I u derstand that issue solving takes time, but andwering to issues shouldn‘t take two weeks, though.

We really want to use Kamon for monitoring but not having double values is a blocker.

[ivantopo]

Hey @rolandjohann, the main reason for only having Long values has been the usage of the HdrHistogram internally since loong time ago. Additionally, most of the signals that we are tracking with Kamon can be successfully tracked with longs: Latency in nanoseconds, counts and queue sizes.. there have been a few situations in which it would be desirable to have double values, like when talking about CPU usage, load averages and maybe even user-defined metrics that make sense as floating point values, but this hasn't been a priority nor a problem to us nor to the majority of the community, I only recall this coming up a handful of times in the 4+ years that Kamon has been around.

May I ask what is your use case and why having floating point values is a blocker?

And, to address your other question: Yes, there are maintainers in this project, I am one of them. @dpsoft is another, and several people stay close to what we are doing here. We do the best we can with the time we have available to improve Kamon, reply to questions and keep the project moving forward, but things sometimes just slip through the cracks. In those cases I encourage you to drop a new message, mention Diego or me, or going to the gitter channel. It might take time to get a response since we work on Kamon during our free time, but if we didn't reply just insist and we will find the time.

[rolandjohann]

Thal you for the information. I‘ll take a closer look at the component you mentioned to get a clear understandig of this topic. We are dealing with sensor or financial data, and therefore with multiple units and currencies that dont share the same base. Converting them into longs at application level and back again to doubles at query time is an overhead and level of conplexity we want to avoid. Ivan Topolnjak <notifications@github.com> schrieb am So. 18. März 2018 um 01:37:

…

Hey @rolandjohann <https://github.com/rolandjohann>, the main reason for only having Long values has been the usage of the HdrHistogram internally since loong time ago. Additionally, most of the signals that we are tracking with Kamon can be successfully tracked with longs: Latency in nanoseconds, counts and queue sizes.. there have been a few situations in which it would be desirable to have double values, like when talking about CPU usage, load averages and maybe even user-defined metrics that make sense as floating point values, but this hasn't been a priority nor a problem to us nor to the majority of the community, I only recall this coming up a handful of times in the 4+ years that Kamon has been around. May I ask what is your use case and why having floating point values is a blocker? And, to address your other question: Yes, there are maintainers in this project, I am one of them. @dpsoft <https://github.com/dpsoft> is another, and several people stay close to what we are doing here. We do the best we can with the time we have available to improve Kamon, reply to questions and keep the project moving forward, but things sometimes just slip through the cracks. In those cases I encourage you to drop a new message, mention Diego or me, or going to the gitter channel <https://gitter.im/kamon-io/Kamon>. It might take time to get a response since we work on Kamon during our free time, but if we didn't reply just insist and we will find the time. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#519 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFddGuXitp4qZzh2VarN19yPo479wXiyks5tfaxZgaJpZM4Sal2f> .

[ivantopo]

I'm closing this issue because it is either too old to be relevant or stale. Stop by our Github Discussions section and drop a message if you need any additional help with the topic.

Have a nice day!