# Java APM Agent Micrometer Integration not handling TimeGauge as desired **URL:** \ **Category:** APM\ **Tags:** java, server\ **Created:** [March 1, 2021, 4:28pm UTC](https://discuss.elastic.co/t/java-apm-agent-micrometer-integration-not-handling-timegauge-as-desired/265833 "2021-03-01T16:28:16Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![bplies](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bplies/32/81481_2.png) [@bplies](https://discuss.elastic.co/u/bplies)\ **Post date:** [March 1, 2021, 4:28pm UTC](https://discuss.elastic.co/t/java-apm-agent-micrometer-integration-not-handling-timegauge-as-desired/265833/1 "2021-03-01T16:28:16Z")
Kibana version: 7.10.0 Elasticsearch version: 7.10.0 APM Server version: 7.10.0 APM Agent language and version: Java 1.20.0 Browser version: N/A Original install method (e.g. download page, yum, deb, from source, etc.) and version: Elastic Cloud Is there anything special in your setup? No Description of the problem including expected versus actual behavior. Please include screenshots (if relevant): A Spring Boot Java application including Micrometer has a Gauge meter defined to monitor a timestamp. Gauges are correctly autodetected by the APM Agent, but are written to Elasticsearch as [Float](https://github.com/elastic/apm-agent-java/blob/master/apm-agent-plugins/apm-micrometer-plugin/src/main/java/co/elastic/apm/agent/micrometer/MicrometerMeterRegistrySerializer.java#L109) which becomes dynamically mapped into the apm-7.10.0-metric-\* indexed as a float and prevents using Date based functions on that field. For what it is worth, Micrometer does support a [TimeGauge](https://github.com/micrometer-metrics/micrometer/blob/master/micrometer-core/src/main/java/io/micrometer/core/instrument/TimeGauge.java) which APM could use to serialize the value as a Long instead but I do not believe that changing our metric to TimeGauge will have any difference because ` else if (meter instanceof Gauge)` will still end up writing it as a Float. **Steps to reproduce** : 1. Define a custom metric as Meter of type Gauge (or TimeGauge I presume) 2. Use that Meter to monitor a timestamp as an Epoch of type Long (`new Date().getTime()`) 3. Observe APM auto-maps the metric as a Float Errors in browser console (if relevant): N/A Provide logs and/or server output (if relevant): N/A ---
**Author:** ![Sylvain\_Juge](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sylvain_juge/32/55521_2.png) [@Sylvain\_Juge](https://discuss.elastic.co/u/Sylvain_Juge)\ **Post date:** [March 3, 2021, 8:51am UTC](https://discuss.elastic.co/t/java-apm-agent-micrometer-integration-not-handling-timegauge-as-desired/265833/2 "2021-03-03T08:51:55Z")
Hi @bplies , Do you have a bit more context on your usage of a timestamp as a metric ? - what does this timestamp value represents in your application ? - how do you use it (or plan to use it) on Kibana ? Our current definition of metrics does not really fit your usage here as metrics are captured as `float` for metric values and we also have a few metric fields like `count` that are mapped as `long`. We don't (as I am aware of) have a simple way to capture any raw `long` value and report it as a metric. Depending on your use-case, you might thus need to do the following: - transform your observed timestamp into an observable metric, for example if the timestamp represents the time of the last database update, you could track this as a metric that represents the number of database updates over a period of time. - build an [ingestion pipeline](https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest-processors.html) that will transform the received agent metric from `float` into a `long` to make it fit your use-case. ---
**Author:** ![bplies](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bplies/32/81481_2.png) [@bplies](https://discuss.elastic.co/u/bplies)\ **Post date:** [March 3, 2021, 4:43pm UTC](https://discuss.elastic.co/t/java-apm-agent-micrometer-integration-not-handling-timegauge-as-desired/265833/3 "2021-03-03T16:43:05Z")
Imagine from a dashboard perspective wanting a Gauge ("indicates the status of a metric") element that is simply a timestamp of when the next _something_ is scheduled to occur. A Counter won't make sense. Micrometer provides the `TimeGauge` for this purpose: > A specialized gauge that tracks a time value Although it monitors a `java.lang.Number` and its interface still only exposes it as a `double` My point is, if someone were to go through the trouble of using `TimeGauge` shouldn't the APM Agent be smarter and realize this metric has something to do with Time so the mappings are correct? In particular a [Date](https://www.elastic.co/guide/en/elasticsearch/reference/current/date.html#date) type because the value really is > a long number representing _milliseconds-since-the-epoch_ . I grant that a `TimeGauge` doesn't necessarily have to be a timestamp/instant and could simply be a measure of time. `nextProcessingStartTime: ` vs `lastProcessingDuration: ` But I'd argue that if one wanted `lastProcessingDuration` you wouldn't even need a `TimeGauge` but rather an ordinary `Gauge`. So `TimeGauge` would seem to me to be better suited for the timestamp. ---
**Author:** ![Sylvain\_Juge](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sylvain_juge/32/55521_2.png) [@Sylvain\_Juge](https://discuss.elastic.co/u/Sylvain_Juge)\ **Post date:** [March 11, 2021, 9:00am UTC](https://discuss.elastic.co/t/java-apm-agent-micrometer-integration-not-handling-timegauge-as-desired/265833/4 "2021-03-11T09:00:48Z")
Hi @bplies, While I understand your use-case, we hadn't had many requests for similar behavior so far, thus it's hard to conclude on what to do exactly. Also, changing this would likely be a breaking change as the metric would have a different mapping in the index, thus it makes it not really trivial. Also, I agree with you that mapping every `TimeGauge` to a `long` value would make sense, since it would cover both the `timestamp` and `time duration in milliseconds` use-cases, however doing so does not really fit our current metrics model. Here we probably lack a proper way have metrics that are just mapped as long, instead of having them always as double. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [April 1, 2021, 5:00am UTC](https://discuss.elastic.co/t/java-apm-agent-micrometer-integration-not-handling-timegauge-as-desired/265833/5 "2021-04-01T05:00:54Z")
This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.