Adds an update interval to the property and tag metrics

[jacomago]

They take some resources, so if your are querying a lot of properties this can timeout

[simon-ess]

This seems like a nice addition. However, if the 5 second interval actually a good one? It seems that switching to re-running this that often might just be hammering the service in a different way.

[jacomago]

This seems like a nice addition. However, if the 5 second interval actually a good one? It seems that switching to re-running this that often might just be hammering the service in a different way.

Its configurable.

[anderslindho]

5s default seems a bit overkill to me - is there any use case for that time precision?

[simon-ess]

Would it not be possible to update the atomic count every time a tag or a property is added or removed? Or is that perhaps a fool's errand?

(The point being of course that the number of tags or proprties will not change in the last $INTERVAL unless something has actually changed like someone manually adding a tag or some such)

[jacomago]

Would it not be possible to update the atomic count every time a tag or a property is added or removed? Or is that perhaps a fool's errand?

(The point being of course that the number of tags or proprties will not change in the last $INTERVAL unless something has actually changed like someone manually adding a tag or some such)

That is a separate metric, that isn't changed in this PR and it is tracked. CF_PROPERTY_COUNT and CF_TAG_COUNT in MetricsService.

[jacomago]

5s default seems a bit overkill to me - is there any use case for that time precision?

Updated to 10 seconds

[anderslindho]

Prometheus default scrape interval is 1m so we could do that or 30s to save CF resources 🔧

But otherwise LGTM

[simon-ess]

One other question: Does this actually have to be an AtomicLong? As near as I see it, we update these values every $INTERVAL seconds in a single place. What is the need for concurrency protection?

(I mean, other than if the update itself takes longer than the interval... 😄 )

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jacomago]

One other question: Does this actually have to be an AtomicLong? As near as I see it, we update these values every $INTERVAL seconds in a single place. What is the need for concurrency protection?

(I mean, other than if the update itself takes longer than the interval... 😄 )

I'm not sure if necessary when using the GaugeBuilder, but generally using Atomics is suggested in the documentation https://docs.micrometer.io/micrometer/reference/concepts/gauges.html