Metric gen_ai_client_estimated_cost_total uses obscure format

[fedinskiy]

Quarkus langchain4j generates some gen_ai usage metrics, including gen_ai_client_estimated_cost_total, which I would expect to contain estimated cost of calls in dollars (or cents). Unfortunately, it uses floating-point number to store/represent the value, which is known anti pattern[1] generally and makes output unclear in our particular use case.

Example (obtained from sample/chatbot module after adding quarkus-micrometer and quarkus-micrometer-registry-prometheusextensions):

gen_ai_client_estimated_cost_total{ai_service_class_name="io.quarkiverse.langchain4j.sample.chatbot.Bot",ai_service_method_name="chat",currency="USD",gen_ai_operation_name="completion",gen_ai_request_model="gpt-4o-mini",gen_ai_response_model="gpt-4o-mini-2024-07-18",gen_ai_token_type="output",} 8.67E-5

[1] eg https://dzone.com/articles/never-use-float-and-double-for-monetary-calculatio

[geoand]

We should definitely fix that

[geoand]

@brunobat we currently do

quarkus-langchain4j/core/runtime/src/main/java/io/quarkiverse/langchain4j/runtime/listeners/MetricsChatModelListener.java

Lines 141 to 142 in 94bbf98

	estimatedCost.withTags(tags.and("currency", costEstimate.currencyCode()))
	.increment(costEstimate.number().doubleValue());

So we don't really control how the counter is displayed. What's the best practice here?

[brunobat]

@geoand, as far as I know, there are no semantic conventions for money/currency.
Money should never be represented as a float/double but as a BigDecimal, which is not available on that Micrometer API. It only accepts double. I don't think we can fix or mitigate this. Maybe we can propose an API extension.

[geoand]

which is not available on that Micrometer API. It only accepts double

Yeah, that's why I originally used it

Maybe we can propose an API extension.

sounds reasonable to me

[brunobat]

There is no way around double. Checked with the Micrometer community that Prometheus will use double and the Micrometer API emulates it.
The scientific notation (8.67E-5) is not really a problem, however using double for money is. I think these systems were not engineered to measure monetary transactions, which is surprisingly weird.
I suggest we close this issue as won't fix.