[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/24/24 2:45 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Coming back to this now, _[if we use the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CacheMeterBinder.java],_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the [CaffeineCache|https://github.com/ben-manes/caffeine/blob/b4cedbc411130b8e78c51effdd527756bdf1ff55/caffeine/src/main/java/com/github/benmanes/caffeine/cache/Cache.java], I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision. [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] offers more detailed statistics than [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and it allows name prefixes. However, [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] needs to pass the meterRegistry to the builder Caffeine object {_}before the cache is built with the build() call{_}. There is no direct support to add a [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] to a Caffeine Cache after the cache is built. So if you use the [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] you might have to do something like call the [MetricsConfiguration|https://github.com/apache/activemq-artemis/blob/c47713454caeece82df29a0a7fd4a2a39000576b/artemis-server/src/main/java/org/apache/activemq/artemis/core/config/MetricsConfiguration.java] from the *[SecurityStoreImpl|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/security/impl/SecurityStoreImpl.java#L105-L108]* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class _(Couples the SecurityStoreImpl to the MetricsManager but maybe 2nd best option)_ * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] _(Seems like best option)_ * Create another concrete class (or maybe even extend the concrete class [CaffeineCacheMetric
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/24/24 3:00 AM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _[if we use the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CacheMeterBinder.java],_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the [CaffeineCache|https://github.com/ben-manes/caffeine/blob/b4cedbc411130b8e78c51effdd527756bdf1ff55/caffeine/src/main/java/com/github/benmanes/caffeine/cache/Cache.java], I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision. [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] offers more detailed statistics than [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and it allows name prefixes. However, [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] needs to pass the meterRegistry to the builder Caffeine object {_}before the cache is built with the build() call{_}. There is no direct support to add a [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] to a Caffeine Cache after the cache is built. So if you use the [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] you might have to do something like call the [MetricsConfiguration|https://github.com/apache/activemq-artemis/blob/c47713454caeece82df29a0a7fd4a2a39000576b/artemis-server/src/main/java/org/apache/activemq/artemis/core/config/MetricsConfiguration.java] from the *[SecurityStoreImpl|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/security/impl/SecurityStoreImpl.java#L105-L108]* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class _(Couples the SecurityStoreImpl to the MetricsManager but maybe 2nd best option)_ * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] _(Seems like best option)_ * Create another concrete class (or maybe even extend
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:39 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _[if we use the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CacheMeterBinder.java],_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the [CaffeineCache|https://github.com/ben-manes/caffeine/blob/b4cedbc411130b8e78c51effdd527756bdf1ff55/caffeine/src/main/java/com/github/benmanes/caffeine/cache/Cache.java], I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision. [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] offers more detailed statistics than [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and it allows name prefixes. However, [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] needs to have the meterRegistry already there {_}at the time the cache is built{_}. There is no direct support to add a [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] to a Caffeine Cache after the cache is built. So if you use the [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] you might have to do something like call the [MetricsConfiguration|https://github.com/apache/activemq-artemis/blob/c47713454caeece82df29a0a7fd4a2a39000576b/artemis-server/src/main/java/org/apache/activemq/artemis/core/config/MetricsConfiguration.java] from the *[SecurityStoreImpl|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/security/impl/SecurityStoreImpl.java#L105-L108]* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class _(Couples the SecurityStoreImpl to the MetricsManager but maybe 2nd best option)_ * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] _(Seems like best option)_ * Create another concrete class (or maybe even extend the concrete class [CaffeineCach
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:38 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _[if we use the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CacheMeterBinder.java],_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision. [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] offers more detailed statistics than [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and it allows name prefixes. However, [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] needs to have the meterRegistry already there {_}at the time the cache is built{_}. There is no direct support to add a [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] to a Caffeine Cache after the cache is built. So if you use the [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] you might have to do something like call the [MetricsConfiguration|https://github.com/apache/activemq-artemis/blob/c47713454caeece82df29a0a7fd4a2a39000576b/artemis-server/src/main/java/org/apache/activemq/artemis/core/config/MetricsConfiguration.java] from the *[SecurityStoreImpl|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/security/impl/SecurityStoreImpl.java#L105-L108]* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class _(Couples the SecurityStoreImpl to the MetricsManager but maybe 2nd best option)_ * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] _(Seems like best option)_ * Create another concrete class (or maybe even extend the concrete class [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/ins
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:32 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision. [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] offers more detailed statistics than [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and it allows name prefixes. However, [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] needs to have the meterRegistry already there {_}at the time the cache is built{_}. There is no direct support to add a [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] to a Caffeine Cache after the cache is built. So if you use the [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] you might have to do something like call the [MetricsConfiguration|https://github.com/apache/activemq-artemis/blob/c47713454caeece82df29a0a7fd4a2a39000576b/artemis-server/src/main/java/org/apache/activemq/artemis/core/config/MetricsConfiguration.java] from the *[SecurityStoreImpl|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/security/impl/SecurityStoreImpl.java#L105-L108]* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class _(Couples the SecurityStoreImpl to the MetricsManager but maybe 2nd best option)_ * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] _(Seems like best option)_ * Create another concrete class (or maybe even extend the concrete class [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micro
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:31 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision. [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] offers more detailed statistics than [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and it allows name prefixes. However, [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] needs to have the meterRegistry already there {_}at the time the cache is built{_}. There is no direct support to add a [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] to a Caffeine Cache after the cache is built. So if you use the [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] you might have to do something like call the [MetricsConfiguration|https://github.com/apache/activemq-artemis/blob/c47713454caeece82df29a0a7fd4a2a39000576b/artemis-server/src/main/java/org/apache/activemq/artemis/core/config/MetricsConfiguration.java] from the *[SecurityStoreImpl|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/security/impl/SecurityStoreImpl.java#L105-L108]* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class _(Couples the SecurityStoreImpl to the MetricsManager but maybe 2nd best option)_ * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] _(Seems like best option)_ * Create another concrete class (or maybe even extend the concrete class [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micro
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:29 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision. [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] offers more detailed statistics than [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and it allows name prefixes. However, [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] needs to have the meterRegistry already there {_}at the time the cache is built{_}. There is no direct support to add a [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] to a Caffeine Cache after the cache is built. So if you use the [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] you might have to do something like call the [MetricsConfiguration|https://github.com/apache/activemq-artemis/blob/c47713454caeece82df29a0a7fd4a2a39000576b/artemis-server/src/main/java/org/apache/activemq/artemis/core/config/MetricsConfiguration.java] from the *[SecurityStoreImpl|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/security/impl/SecurityStoreImpl.java#L105-L108]* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class _(Couples the SecurityStoreImpl to the MetricsManager but maybe 2nd best option)_ * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] _(Seems like best option)_ * Create another concrete class (or maybe even extend the concrete class [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micro
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:28 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision. [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] offers more detailed statistics than [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and it allows name prefixes. However, [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] needs to have the meterRegistry already there {_}at the time the cache is built{_}. There is no direct support to add a [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] to a Caffeine Cache after the cache is built. So if you use the [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] you might have to do something like call the [MetricsConfiguration|https://github.com/apache/activemq-artemis/blob/c47713454caeece82df29a0a7fd4a2a39000576b/artemis-server/src/main/java/org/apache/activemq/artemis/core/config/MetricsConfiguration.java] from the *[SecurityStoreImpl|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/security/impl/SecurityStoreImpl.java#L105-L108]* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class (Couples the SecurityStoreImpl to the MetricsManager but maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or maybe even extend the concrete class [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micromete
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:27 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision. [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] offers more detailed statistics than [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and it allows name prefixes. However, [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] needs to have the meterRegistry already there {_}at the time the cache is built{_}. There is no direct support to add a [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] to a Caffeine Cache after the cache is built. So if you use the [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] you might have to do something like call the [MetricsConfiguration|https://github.com/apache/activemq-artemis/blob/c47713454caeece82df29a0a7fd4a2a39000576b/artemis-server/src/main/java/org/apache/activemq/artemis/core/config/MetricsConfiguration.java] from the *[SecurityStoreImpl|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/security/impl/SecurityStoreImpl.java#L105-L108]* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class (Couples the SecurityStoreImpl to the MetricsManager but maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/microm
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:25 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision. *CaffeineStatsCounter* offers more detailed statistics than *CaffeineCacheMetrics* and it allows name prefixes. However, *CaffeineStatsCounter* needs to have the meterRegistry already there {_}at the time the cache is built{_}. There is no direct support to add a *CaffeineStatsCounter* to a Caffeine Cache after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *[SecurityStoreImpl|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/security/impl/SecurityStoreImpl.java#L105-L108]* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class (Couples the SecurityStoreImpl to the MetricsManager but maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:24 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision. *CaffeineStatsCounter* offers more detailed statistics than *CaffeineCacheMetrics* and it allows name prefixes. However, *CaffeineStatsCounter* needs to have the meterRegistry already there {_}at the time the cache is built{_}. There is no direct support to add a *CaffeineStatsCounter* to a Caffeine Cache after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class (Couples the SecurityStoreImpl to the MetricsManager but maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("c
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:23 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision. *CaffeineStatsCounter* offers more detailed statistics than *CaffeineCacheMetrics* and it allows name prefixes. However, *CaffeineStatsCounter* needs to have the meterRegistry already there {_}at the time the cache is built{_}. There is no direct support to add a *CaffeineStatsCounter* to a Caffeine Cache after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class (Couples the SecurityStoreImpl to the MetricsManager but maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:21 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision because *CaffeineStatsCounter* offers more statistics and it allows name prefixes. However, it needs to have the registry at the time the cache is created. There is no direct support to create a metrics counter after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class (Couples the SecurityStoreImpl to the MetricsManager but maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} I
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:20 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision because *CaffeineStatsCounter* offers more statistics and it allows name prefixes. However, it needs to have the registry at the time the cache is created. There is no direct support to create a metrics counter after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] could initialize the authn cache (and authz cache) from the MetricsManager class (Maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for microme
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:20 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision because *CaffeineStatsCounter* offers more statistics and it allows name prefixes. However, it needs to have the registry at the time the cache is created. There is no direct support to create a metrics counter after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* So this doesnt seem like the best option. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] but could initialize the authn cache (and authz cache) from the MetricsManager class (Maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for mic
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:18 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision because *CaffeineStatsCounter* offers more statistics and it allows name prefixes. However, it needs to have the registry at the time the cache is created. There is no direct support to create a metrics counter after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} MeterRegistry registry = metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* This doesnt seem like the best option though. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] but could initialize the authn cache (and authz cache) from the MetricsManager class (Maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:17 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision because *CaffeineStatsCounter* offers more statistics and it allows name prefixes. However, it needs to have the registry at the time the cache is created. There is no direct support to create a metrics counter after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "authentication")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* This doesnt seem like the best option though. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] but could initialize the authn cache (and authz cache) from the MetricsManager class (Maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibl
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:17 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("cacheName", "authentication"){}}}and {{{}Tag("{}}}{{{}cacheName{}}}{{{}", "authorization"){}}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision because *CaffeineStatsCounter* offers more statistics and it allows name prefixes. However, it needs to have the registry at the time the cache is created. There is no direct support to create a metrics counter after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "graphs")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* This doesnt seem like the best option though. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] but could initialize the authn cache (and authz cache) from the MetricsManager class (Maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("type", "authentication"){}}}and {{Tag("type", "authorization")}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are usi
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:14 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("type", "authentication"){}}}and {{Tag("type", "authorization")}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision because *CaffeineStatsCounter* offers more statistics and it allows name prefixes. However, it needs to have the registry at the time the cache is created. There is no direct support to create a metrics counter after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "graphs")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* This doesnt seem like the best option though. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] but could initialize the authn cache (and authz cache) from the MetricsManager class (Maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. {{Tag("type", "authorization")}} Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("type", "authentication"){}}}and {{Tag("type", "authorization")}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are us
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:14 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. {{Tag("type", "authorization")}} Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("type", "authentication"){}}}and {{Tag("type", "authorization")}} It seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision because *CaffeineStatsCounter* offers more statistics and it allows name prefixes. However, it needs to have the registry at the time the cache is created. There is no direct support to create a metrics counter after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "graphs")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* This doesnt seem like the best option though. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] but could initialize the authn cache (and authz cache) from the MetricsManager class (Maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("type", "authentication"){}}}and {{Tag("type", "authorization"). }}Seems this might be more of a standard too for micrometer users possibly. However, now that we are usin
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:14 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("type", "authentication"){}}}and {{Tag("type", "authorization"). }}Seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision because *CaffeineStatsCounter* offers more statistics and it allows name prefixes. However, it needs to have the registry at the time the cache is created. There is no direct support to create a metrics counter after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "graphs")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* This doesnt seem like the best option though. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] but could initialize the authn cache (and authz cache) from the MetricsManager class (Maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("type", "authentication"){}}}and {{Tag("type", "authorization"). }}Seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:13 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("type", "authentication"){}}}and {{Tag("type", "authorization"). }}Seems this might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision because *CaffeineStatsCounter* offers more statistics and it allows name prefixes. However, it needs to have the registry at the time the cache is created. There is no direct support to create a metrics counter after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "graphs")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* This doesnt seem like the best option though. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] but could initialize the authn cache (and authz cache) from the MetricsManager class (Maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("type", "authentication"){}}}and {{Tag("type", "authorization")}} ? Seems that might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:12 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {{{}Tag("type", "authentication"){}}}and {{Tag("type", "authorization")}} ? Seems that might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision because *CaffeineStatsCounter* offers more statistics and it allows name prefixes. However, it needs to have the registry at the time the cache is created. There is no direct support to create a metrics counter after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "graphs")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* This doesnt seem like the best option though. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] but could initialize the authn cache (and authz cache) from the MetricsManager class (Maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. `Tag("type", "authentication")` and `Tag("type", "authorization")` ? Seems that might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are t
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099 ] Mike Artz edited comment on ARTEMIS-4306 at 5/23/24 8:11 PM: - [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. `Tag("type", "authentication")` and `Tag("type", "authorization")` ? Seems that might be more of a standard too for micrometer users possibly. However, now that we are using the CaffeineCache, I see there are two concrete classes - [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] and [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java]. Both of these look ok at first (more or less), but I am stuck at this decision because *CaffeineStatsCounter* offers more statistics and it allows name prefixes. However, it needs to have the registry at the time the cache is created. There is no direct support to create a metrics counter after the cache is built. So if you use the *CaffeineStatsCounter* you might have to do something like call the *MetricsConfiguration* from the *SecurityStoreImpl* like {code:java} metricsConfiguration.getPlugin().getRegistry(); authenticationCache = Caffeine.newBuilder() .maximumSize(authenticationCacheSize) .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS) .recordStats(() -> new CaffeineStatsCounter(registry, "graphs")) .build();{code} And that doesnt make any sense because *MetricsConfiguration* happens after the *SecurityStoreImpl.* This doesnt seem like the best option though. *Other Options* * Use [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] but could initialize the authn cache (and authz cache) from the MetricsManager class (Maybe 2nd best option) * Use [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java] (Seems like best option) * Create another concrete class (or extend [CaffeineCacheMetrics|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineCacheMetrics.java]) that does as much as [CaffeineStatsCounter|https://github.com/micrometer-metrics/micrometer/blob/37883fa6fb4a6d3f83d01f6b53101cc9f52b3f78/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CaffeineStatsCounter.java] (Seems overkill) * Create some sort of decorator that would intercept the cache operations and delegate to an underlying cache (Seems overkill) {code:java} public class StatsCounterDecorator implements Cache { private final Cache delegate; private final StatsCounter statsCounter; ... @Override public void put(K key, V value) { delegate.put(key, value); } public static void main(String[] args) { //get already initialized cache server .getSecurityStore() .getAuthenticationMetrics() StatsCounter statsCounter = new ConcurrentStatsCounter(); Cache cacheWithStats = new StatsCounterDecorator<>(originalCache, statsCounter); }{code} was (Author: JIRAUSER301522): [~jbertram] - I made this [PR for micrometer to allow prefixing in the CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/pull/4048], so that we could for example add the *"artemis.authentication."* prefix but the PR _kind of_ got stuck, and the PR got closed. Then I had a kid and had a new job. Coming back to this now, _if we use the CacheMeterBinder,_ would it be ok to not have *"artemis.authentication."* prefixes, and adding *authentication* and *authorization* as Tags? i.e. {noformat} Tag("type", "authentication"){noformat} and {noformat} Tag("type", "authorization"){noformat} ? Seems that might be more of a standard too for micrometer users possibly. However, now that we are using the
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756191#comment-17756191 ] Mike Artz edited comment on ARTEMIS-4306 at 8/19/23 2:52 AM: - [~jbertram] for the metric names should it have just {{cache.gets}} with two different tags for {{type=authentication}} and {{{}type=authorization{}}}, or should it be two different mettrics - {{artemis.authentication.cache.gets}} and {{{}artemis.authorization.cache.gets{}}}. We can still use the {{CacheMeterBinder}} abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least. Also the user might find it nicer to group all the {{authentication}} metrics together going forward as more metrics are added and then group all the {{authorization}} metrics together, whether they are referencing the cache or not. If they are all just one thing like for example "SecurityMetrics" then we cant use the {{[CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/blob/c959eb3e7629363080c4628e70b31f28d044ef3c/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CacheMeterBinder.java]}} {color:#172b4d}(which is actually fine if we dont) but just something to think about. I can finish the changes and make the PR so you can look at it.{color} was (Author: JIRAUSER301522): [~jbertram] for the metric names should it have just {{cache.gets}} with two different tags for {{type=authentication}} and {{{}type=authorization{}}}, or should it be two different mettrics - {{artemis.authentication.cache.gets}} and {{{}artemis.authorization.cache.gets{}}}. We can still use the {{CacheMeterBinder}} abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least. Also the user might find it nicer to group all the {{authentication}} metrics together going forward as more metrics are added and then group all the {{authorization}} metrics together, whether they are referencing the cache or not. If they are all just one thing like for example "SecurityMetrics" then we cant use the {{CacheMeterBinder}} {color:#172b4d}(which is actually fine if we dont) but just something to think about. I can finish the changes and make the PR so you can look at it.{color} > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756191#comment-17756191 ] Mike Artz edited comment on ARTEMIS-4306 at 8/19/23 2:49 AM: - [~jbertram] for the metric names should it have just {{cache.gets}} with two different tags for {{type=authentication}} and {{{}type=authorization{}}}, or should it be two different mettrics - {{artemis.authentication.cache.gets}} and {{{}artemis.authorization.cache.gets{}}}. We can still use the {{CacheMeterBinder}} abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least. Also the user might find it nicer to group all the {{authentication}} metrics together going forward as more metrics are added and then group all the {{authorization}} metrics together, whether they are referencing the cache or not. If they are all just one thing like for example "SecurityMetrics" then we cant use the {{CacheMeterBinder}} {color:#172b4d}(which is actually fine if we dont) but just something to think about. I can finish the changes and make the PR so you can look at it.{color} was (Author: JIRAUSER301522): [~jbertram] for the metric names should it have just "cache.gets" or should it be "artemis.authentication.cache.gets". We can still use the CacheMeterBinder abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least. Also the user might find it nicer to group all the authentication metrics together going forward as more metrics are added and then group all the authorization metrics together, whether they are cache or not. If they are all just one thing like for example "SecurityMetrics" then we cant use the {{CacheMeterBinder}} {color:#172b4d}(which is actually fine) but just something to think about. I can finish the changes and make the PR so you can look at it.{color} > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756191#comment-17756191 ] Mike Artz edited comment on ARTEMIS-4306 at 8/19/23 2:45 AM: - [~jbertram] for the metric names should it have just "cache.gets" or should it be "artemis.authentication.cache.gets". We can still use the CacheMeterBinder abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least. Also the user might find it nicer to group all the authentication metrics together going forward as more metrics are added and then group all the authorization metrics together, whether they are cache or not. If they are all just one thing like for example "SecurityMetrics" then we cant use the {{CacheMeterBinder}} {color:#172b4d}(which is actually fine) but just something to think about. I can finish the changes and make the PR so you can look at it.{color} was (Author: JIRAUSER301522): [~jbertram] for the metric names should it have just "cache.gets" or should it be "artemis.authentication.cache.gets". We can still use the CacheMeterBinder abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least. Also the user might find it nicer to group all the authentication metrics together going forward as more metrics are added and then group all the authorization metrics together, whether they are cache or not. If they are all just one thing like for example "SecurityMetrics" then we cant use the {{CacheMeterBinder}} {color:#172b4d}(which is actually fine) but just something to think about.{color} > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756191#comment-17756191 ] Mike Artz edited comment on ARTEMIS-4306 at 8/19/23 2:44 AM: - [~jbertram] for the metric names should it have just "cache.gets" or should it be "artemis.authentication.cache.gets". We can still use the CacheMeterBinder abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least. Also the user might find it nicer to group all the authentication metrics together going forward as more metrics are added and then group all the authorization metrics together, whether they are cache or not. If they are all just one thing like for example "SecurityMetrics" then we cant use the {{CacheMeterBinder}} {color:#172b4d}(which is actually fine) but just something to think about.{color} was (Author: JIRAUSER301522): [~jbertram] for the metric names should it have just "cache.gets" or should it be "artemis.authentication.cache.gets". We can still use the CacheMeterBinder abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least. Also the user might find it nicer to group all the authentication metrics together going forward as more metrics are added and then group all the authorization metrics together, whether they are cache or not. IF they are all just one thing like for example "SecurityMetrics" then 1. We cant use the {{CacheMeterBinder}} {color:#172b4d}(which is actually fine) but just something to think about.{color} > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756191#comment-17756191 ] Mike Artz edited comment on ARTEMIS-4306 at 8/19/23 2:43 AM: - [~jbertram] for the metric names should it have just "cache.gets" or should it be "artemis.authentication.cache.gets". We can still use the CacheMeterBinder abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least. Also the user might find it nicer to group all the authentication metrics together going forward as more metrics are added and then group all the authorization metrics together, whether they are cache or not. IF they are all just one thing like for example "SecurityMetrics" then 1. We cant use the {{CacheMeterBinder}} {color:#172b4d}(which is actually fine) but just something to think about.{color} was (Author: JIRAUSER301522): [~jbertram] for the metric names should it have just "cache.gets" or should it be "artemis.authentication.cache.gets". We can still use the CacheMeterBinder abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least. Also the user might find it nicer to group all the authentication metrics together going forward as more metrics are added and then group all the authorization metrics together, whether they are cache or not. IF they are all just one thing like for example "SecurityMetrics" then 1. We cant use the {{CacheMeterBinder }}{color:#172b4d}(which is actually fine) but just something to think about.{color} > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756191#comment-17756191 ] Mike Artz edited comment on ARTEMIS-4306 at 8/19/23 2:43 AM: - [~jbertram] for the metric names should it have just "cache.gets" or should it be "artemis.authentication.cache.gets". We can still use the CacheMeterBinder abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least. Also the user might find it nicer to group all the authentication metrics together going forward as more metrics are added and then group all the authorization metrics together, whether they are cache or not. IF they are all just one thing like for example "SecurityMetrics" then 1. We cant use the {{CacheMeterBinder }}{color:#172b4d}(which is actually fine) but just something to think about.{color} was (Author: JIRAUSER301522): [~jbertram] for the metric names should it have just "cache.gets" or should it be "artemis.authentication.cache.gets". We can still use the CacheMeterBinder abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least. Also the user might find it nicer to group all the authentication metrics together going forward as more metrics are added and then group all the authorization metrics together, whether they are cache or not. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756191#comment-17756191 ] Mike Artz edited comment on ARTEMIS-4306 at 8/19/23 2:38 AM: - [~jbertram] for the metric names should it have just "cache.gets" or should it be "artemis.authentication.cache.gets". We can still use the CacheMeterBinder abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least. Also the user might find it nicer to group all the authentication metrics together going forward as more metrics are added and then group all the authorization metrics together, whether they are cache or not. was (Author: JIRAUSER301522): [~jbertram] for the metric names should it have just "cache.gets" or should it be "artemis.authentication.cache.gets". We can still use the CacheMeterBinder abstract class either way. The "artemis.authentication.cache.gets" looks like all the other artemis configs at least > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753224#comment-17753224 ] Mike Artz edited comment on ARTEMIS-4306 at 8/15/23 4:32 AM: - Yeah that is really helpful thanks. It does seem like we can do mostly the same things that were done in those other system metrics - but not the same same - because those other system metrics in that JIRA are completely for free. Although it is still global, and if we do extend the [CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/blob/1354fc2a1f4ca4c0c9678084fb3ccaf23d0b51e7/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CacheMeterBinder.java#L39] then the registration should be very similar to the other system metrics in theory. It might be ok to have just two new classes like {code:java} import com.google.common.cache.Cache; import io.micrometer.core.instrument.binder.cache.CacheMeterBinder; AuthenticationMetrics extends CacheMeterBinder{} AuthorizationMetrics extends CacheMeterBinder{}{code} and then those each would have weak references to those respective caches. They also would each have their respective non-cache metrics (right now just two - successes and failures). Then also they could be registered in the same place that the other system metrics were registered in {{MetricsManager}} only we would need to get the two (already instantiated metrics objects) from the server instance like {code:java} if (metricsConfiguration.isProcessor()) { new ProcessorMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isUptime()) { new UptimeMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isAuthentication()) { server .getSecurityStore() .getAuthenticationMetrics() .bindTo(meterRegistry); } if (metricsConfiguration.isAuthorization()) { server .getSecurityStore() .getAuthorizationMetrics() .bindTo(meterRegistry); }{code} was (Author: JIRAUSER301522): Yeah that is really helpful thanks. It doesn't seem like we can do the same things that were done in those other system metrics because those are completely for free. Although it is still global, and if we do extend the [CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/blob/1354fc2a1f4ca4c0c9678084fb3ccaf23d0b51e7/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CacheMeterBinder.java#L39] then the registration should be very similar to the other system metrics in theory. It might be ok to have just two new classes like {code:java} import com.google.common.cache.Cache; import io.micrometer.core.instrument.binder.cache.CacheMeterBinder; AuthenticationMetrics extends CacheMeterBinder{} AuthorizationMetrics extends CacheMeterBinder{}{code} and then those each would have weak references to those respective caches. They also would each have their respective non-cache metrics (right now just two - successes and failures). Then also they could be registered in the same place that the other system metrics were registered in {{MetricsManager}} only we would need to get the two (already instantiated metrics objects) from the server instance like {code:java} if (metricsConfiguration.isProcessor()) { new ProcessorMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isUptime()) { new UptimeMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isAuthentication()) { server .getSecurityStore() .getAuthenticationMetrics() .bindTo(meterRegistry); } if (metricsConfiguration.isAuthorization()) { server .getSecurityStore() .getAuthorizationMetrics() .bindTo(meterRegistry); }{code} > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753224#comment-17753224 ] Mike Artz edited comment on ARTEMIS-4306 at 8/15/23 4:32 AM: - Yeah that is really helpful thanks. It does seem like we can do mostly the same things that were done in those other system metrics - but not the same same - because those other system metrics in ARTEMIS-4292 are completely for free. Although it is still global, and if we do extend the [CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/blob/1354fc2a1f4ca4c0c9678084fb3ccaf23d0b51e7/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CacheMeterBinder.java#L39] then the registration should be very similar to the other system metrics in theory. It might be ok to have just two new classes like {code:java} import com.google.common.cache.Cache; import io.micrometer.core.instrument.binder.cache.CacheMeterBinder; AuthenticationMetrics extends CacheMeterBinder{} AuthorizationMetrics extends CacheMeterBinder{}{code} and then those each would have weak references to those respective caches. They also would each have their respective non-cache metrics (right now just two - successes and failures). Then also they could be registered in the same place that the other system metrics were registered in {{MetricsManager}} only we would need to get the two (already instantiated metrics objects) from the server instance like {code:java} if (metricsConfiguration.isProcessor()) { new ProcessorMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isUptime()) { new UptimeMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isAuthentication()) { server .getSecurityStore() .getAuthenticationMetrics() .bindTo(meterRegistry); } if (metricsConfiguration.isAuthorization()) { server .getSecurityStore() .getAuthorizationMetrics() .bindTo(meterRegistry); }{code} was (Author: JIRAUSER301522): Yeah that is really helpful thanks. It does seem like we can do mostly the same things that were done in those other system metrics - but not the same same - because those other system metrics in that JIRA are completely for free. Although it is still global, and if we do extend the [CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/blob/1354fc2a1f4ca4c0c9678084fb3ccaf23d0b51e7/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CacheMeterBinder.java#L39] then the registration should be very similar to the other system metrics in theory. It might be ok to have just two new classes like {code:java} import com.google.common.cache.Cache; import io.micrometer.core.instrument.binder.cache.CacheMeterBinder; AuthenticationMetrics extends CacheMeterBinder{} AuthorizationMetrics extends CacheMeterBinder{}{code} and then those each would have weak references to those respective caches. They also would each have their respective non-cache metrics (right now just two - successes and failures). Then also they could be registered in the same place that the other system metrics were registered in {{MetricsManager}} only we would need to get the two (already instantiated metrics objects) from the server instance like {code:java} if (metricsConfiguration.isProcessor()) { new ProcessorMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isUptime()) { new UptimeMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isAuthentication()) { server .getSecurityStore() .getAuthenticationMetrics() .bindTo(meterRegistry); } if (metricsConfiguration.isAuthorization()) { server .getSecurityStore() .getAuthorizationMetrics() .bindTo(meterRegistry); }{code} > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753224#comment-17753224 ] Mike Artz edited comment on ARTEMIS-4306 at 8/15/23 4:29 AM: - Yeah that is really helpful thanks. It doesn't seem like we can do the same things that were done in those other system metrics because those are completely for free. Although it is still global, and if we do extend the [CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/blob/1354fc2a1f4ca4c0c9678084fb3ccaf23d0b51e7/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CacheMeterBinder.java#L39] then the registration should be very similar to the other system metrics in theory. It might be ok to have just two new classes like {code:java} import com.google.common.cache.Cache; import io.micrometer.core.instrument.binder.cache.CacheMeterBinder; AuthenticationMetrics extends CacheMeterBinder{} AuthorizationMetrics extends CacheMeterBinder{}{code} and then those each would have weak references to those respective caches. They also would each have their respective non-cache metrics (right now just two - successes and failures). Then also they could be registered in the same place that the other system metrics were registered in {{MetricsManager}} only we would need to get the two (already instantiated metrics objects) from the server instance like {code:java} if (metricsConfiguration.isProcessor()) { new ProcessorMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isUptime()) { new UptimeMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isAuthentication()) { server .getSecurityStore() .getAuthenticationMetrics() .bindTo(meterRegistry); } if (metricsConfiguration.isAuthorization()) { server .getSecurityStore() .getAuthorizationMetrics() .bindTo(meterRegistry); }{code} was (Author: JIRAUSER301522): Yeah that is really helpful thanks. It doesn't seem like we can do the same things that were done in those other system metrics because those are completely for free. Although it is still global, and if we do extend the [CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/blob/1354fc2a1f4ca4c0c9678084fb3ccaf23d0b51e7/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CacheMeterBinder.java#L39] then the registration should be very similar to the other system metrics in theory. It might be ok to have just two new classes like {code:java} import com.google.common.cache.Cache; import io.micrometer.core.instrument.binder.cache.CacheMeterBinder; AuthenticationMetrics extends CacheMeterBinder{} AuthorizationMetrics extends CacheMeterBinder{}{code} and then those each would have weak references to those respective caches. They also would each have their respective non-cache metrics (right now just two - successes and failures). Then also they could be registered in the same place that the other system metrics were registered in {{MetricsManager }}only we would need to get the two (already instantiated metrics objects) from the server instance like {code:java} if (metricsConfiguration.isProcessor()) { new ProcessorMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isUptime()) { new UptimeMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isAuthentication()) { server .getSecurityStore() .getAuthenticationMetrics() .bindTo(meterRegistry); } if (metricsConfiguration.isAuthorization()) { server .getSecurityStore() .getAuthorizationMetrics() .bindTo(meterRegistry); }{code} > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753224#comment-17753224 ] Mike Artz edited comment on ARTEMIS-4306 at 8/15/23 4:28 AM: - Yeah that is really helpful thanks. It doesn't seem like we can do the same things that were done in those other system metrics because those are completely for free. Although it is still global, and if we do extend the [CacheMeterBinder|https://github.com/micrometer-metrics/micrometer/blob/1354fc2a1f4ca4c0c9678084fb3ccaf23d0b51e7/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache/CacheMeterBinder.java#L39] then the registration should be very similar to the other system metrics in theory. It might be ok to have just two new classes like {code:java} import com.google.common.cache.Cache; import io.micrometer.core.instrument.binder.cache.CacheMeterBinder; AuthenticationMetrics extends CacheMeterBinder{} AuthorizationMetrics extends CacheMeterBinder{}{code} and then those each would have weak references to those respective caches. They also would each have their respective non-cache metrics (right now just two - successes and failures). Then also they could be registered in the same place that the other system metrics were registered in {{MetricsManager }}only we would need to get the two (already instantiated metrics objects) from the server instance like {code:java} if (metricsConfiguration.isProcessor()) { new ProcessorMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isUptime()) { new UptimeMetrics().bindTo(meterRegistry); } if (metricsConfiguration.isAuthentication()) { server .getSecurityStore() .getAuthenticationMetrics() .bindTo(meterRegistry); } if (metricsConfiguration.isAuthorization()) { server .getSecurityStore() .getAuthorizationMetrics() .bindTo(meterRegistry); }{code} was (Author: JIRAUSER301522): Yeah that is really helpful thanks. One thought - does it makes sense to have a class next to {{SecurityStoreImpl}} called like {{SecurityStoreMetrics}} that keeps track of the success & failures. Then a reference to {{SecurityStoreMetrics}} can be a property in {{{}SecurityStoreImpl{}}}. Similar to how {{[QueueMessageMetrics|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueMessageMetrics.java]}} is being done. Because though it is not at the broker level, QueueMessageMetrics is kind of similar in that it is also having some metrics that Micrometer cant give, like the authn/z failure and success. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753224#comment-17753224 ] Mike Artz edited comment on ARTEMIS-4306 at 8/11/23 1:29 PM: - Yeah that is really helpful thanks. One thought - so does it makes sense to have a class next to {{SecurityStoreImpl}} called like {{SecurityStoreMetrics}} that keeps track of the success & failures. Then a reference to {{SecurityStoreMetrics}} can be a property in {{{}SecurityStoreImpl{}}}. Similar to how {{[QueueMessageMetrics|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueMessageMetrics.java]}} is being done. Because though it is not at the broker level, QueueMessageMetrics is kind of similar in that it is also having some metrics that Micrometer cant give, like the authn/z failure and success. was (Author: JIRAUSER301522): Yeah that is really helpful thanks. One thought - so does it makes sense to have a class next to {{SecurityStoreImpl}} called like {{SecurityStoreMetrics}} that keeps track of the success & failures. Then a reference to {{SecurityStoreMetrics}} can be a property in {{{}SecurityStoreImpl{}}}. Similar to how {{[QueueMessageMetrics|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueMessageMetrics.java]}} is being done. Even though it is not at the broker level, QueueMessageMetrics is kind of similar in that it is also having some metrics that Micrometer cant give. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753224#comment-17753224 ] Mike Artz edited comment on ARTEMIS-4306 at 8/11/23 1:29 PM: - Yeah that is really helpful thanks. One thought - does it makes sense to have a class next to {{SecurityStoreImpl}} called like {{SecurityStoreMetrics}} that keeps track of the success & failures. Then a reference to {{SecurityStoreMetrics}} can be a property in {{{}SecurityStoreImpl{}}}. Similar to how {{[QueueMessageMetrics|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueMessageMetrics.java]}} is being done. Because though it is not at the broker level, QueueMessageMetrics is kind of similar in that it is also having some metrics that Micrometer cant give, like the authn/z failure and success. was (Author: JIRAUSER301522): Yeah that is really helpful thanks. One thought - so does it makes sense to have a class next to {{SecurityStoreImpl}} called like {{SecurityStoreMetrics}} that keeps track of the success & failures. Then a reference to {{SecurityStoreMetrics}} can be a property in {{{}SecurityStoreImpl{}}}. Similar to how {{[QueueMessageMetrics|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueMessageMetrics.java]}} is being done. Because though it is not at the broker level, QueueMessageMetrics is kind of similar in that it is also having some metrics that Micrometer cant give, like the authn/z failure and success. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753224#comment-17753224 ] Mike Artz edited comment on ARTEMIS-4306 at 8/11/23 1:26 PM: - Yeah that is really helpful thanks. One thought - so does it makes sense to have a class next to {{SecurityStoreImpl}} called like {{SecurityStoreMetrics}} that keeps track of the success & failures. Then a reference to {{SecurityStoreMetrics}} can be a property in {{{}SecurityStoreImpl{}}}. Similar to how {{[QueueMessageMetrics|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueMessageMetrics.java]}} is being done. Even though it is not at the broker level, QueueMessageMetrics is kind of similar in that it is also having some metrics that Micrometer cant give. was (Author: JIRAUSER301522): Yeah that is really helpful thanks. One thought - so does it makes sense to have a class next to {{SecurityStoreImpl}} called like {{SecurityStoreMetrics}} that keeps track of the success & failures. Then a reference to {{SecurityStoreMetrics}} can be a property in {{{}SecurityStoreImpl{}}}. Similar to how {{[QueueMessageMetrics|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueMessageMetrics.java]}} is being done. Even though it is not at the broker level, {{QueueMessageMetrics }}is kind of similar in that it is also having some metrics that Micrometer cant give. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753224#comment-17753224 ] Mike Artz edited comment on ARTEMIS-4306 at 8/11/23 1:26 PM: - Yeah that is really helpful thanks. One thought - so does it makes sense to have a class next to {{SecurityStoreImpl}} called like {{SecurityStoreMetrics}} that keeps track of the success & failures. Then a reference to {{SecurityStoreMetrics}} can be a property in {{{}SecurityStoreImpl{}}}. Similar to how {{[QueueMessageMetrics|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueMessageMetrics.java]}} is being done. Even though it is not at the broker level, {{QueueMessageMetrics }}is kind of similar in that it is also having some metrics that Micrometer cant give. was (Author: JIRAUSER301522): Yeah that is really helpful thanks. One thought - so does it makes sense to have a class next to {{SecurityStoreImpl}} called like {{SecurityStoreMetrics}} that keeps track of the success & failures. Then a reference to {{SecurityStoreMetrics}} can be a property in {{{}SecurityStoreImpl{}}}. Similar to how {{QueueMessageMetrics}} is being done. Even though it is not at the broker level, {{[QueueMessageMetrics|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueMessageMetrics.java]}} is also having metrics that Micrometer cant give. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753224#comment-17753224 ] Mike Artz edited comment on ARTEMIS-4306 at 8/11/23 1:25 PM: - Yeah that is really helpful thanks. One thought - so does it makes sense to have a class next to {{SecurityStoreImpl}} called like {{SecurityStoreMetrics}} that keeps track of the success & failures. Then a reference to {{SecurityStoreMetrics}} can be a property in {{{}SecurityStoreImpl{}}}. Similar to how {{QueueMessageMetrics}} is being done. Even though it is not at the broker level, {{[QueueMessageMetrics|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueMessageMetrics.java]}} is also having metrics that Micrometer cant give. was (Author: JIRAUSER301522): Yeah that is really helpful thanks. One thought - so does it makes sense to have a class next to {{SecurityStoreImpl}} called like {{SecurityStoreMetrics}} that keeps track of the success & failures. Then a reference to {{SecurityStoreMetrics}} can be a property in {{{}SecurityStoreImpl{}}}. Similar to how {{QueueMessageMetrics}} is being done. Even though it is not at the broker level, {{QueueMessageMetrics}} is also having metrics that Micrometer cant give. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753224#comment-17753224 ] Mike Artz edited comment on ARTEMIS-4306 at 8/11/23 1:23 PM: - Yeah that is really helpful thanks. One thought - so does it makes sense to have a class next to {{SecurityStoreImpl}} called like {{SecurityStoreMetrics}} that keeps track of the success & failures. Then a reference to {{SecurityStoreMetrics}} can be a property in {{{}SecurityStoreImpl{}}}. Similar to how {{QueueMessageMetrics}} is being done. Even though it is not at the broker level, {{QueueMessageMetrics}} is also having metrics that Micrometer cant give. was (Author: JIRAUSER301522): Yeah that is really helpful thanks. Do you think it makes sense to have a class next to `SecurityStoreImpl` called like `SecurityStoreMetrics` that keeps track of the success & failures. Then a reference to `SecurityStoreMetrics` can be a property in `SecurityStoreImpl`. Similar to how QueueMessageMetrics is being done. Even though it is not at the broker level, QueueMEssageMetrics is also having metrics that Micrometer cant give. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750845#comment-17750845 ] Justin Bertram edited comment on ARTEMIS-4306 at 8/3/23 5:54 PM: - I linked the original discussion in the description. I think success & failure counts for both authn & authz are a good place to start. The user in the email thread requested individual success & failure counts for a handful of individual permission types, but I'm not convinced of the utility of those. In my opinion it doesn't make sense to provide metrics for only _some_ of the permission types and there are [10 permission types|https://activemq.apache.org/components/artemis/documentation/latest/security.html#role-based-security-for-addresses] so that would be 20 metrics for authz rather than just 2. At this point I just don't see the justification for the additional complexity that would add. We can get metrics for both authn & authz caches mostly for free by using Micrometer's [cache integration|https://github.com/micrometer-metrics/micrometer/tree/main/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache] similar to what's already been done with various system metrics (recent work via ARTEMIS-4292). Lastly, there needs to be a flag to enable/disable these metrics like there is for the [JVM, Netty, etc.|https://activemq.apache.org/components/artemis/documentation/latest/metrics.html#configuration] was (Author: jbertram): I linked the original discussion in the description. I think success & failure counts for both authn & authz are a good place to start. The user in the email thread requested individual success & failure counts for a handful of individual permission types, but I'm not convinced of the utility of those. In my opinion it doesn't make sense to provide metrics for only _some_ of the permission types and there are [10 permission types|https://activemq.apache.org/components/artemis/documentation/latest/security.html#role-based-security-for-addresses] so that would be 20 metrics for authz rather than just 2. At this point I just don't see the justification for the additional complexity that would add. We can get metrics for both authn & authz caches mostly for free by using Micrometer's [cache integration|https://github.com/micrometer-metrics/micrometer/tree/main/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/cache]. Lastly, there needs to be a flag to enable/disable these metrics like there is for the [JVM, Netty, etc.|https://activemq.apache.org/components/artemis/documentation/latest/metrics.html#configuration] > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. > See this discussion on the users mailing list for more details: > https://lists.apache.org/thread/g6ygyo4kb3xhygq8hpw7vsl3l2g5qt92 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750543#comment-17750543 ] Mike Artz edited comment on ARTEMIS-4306 at 8/3/23 4:03 PM: Just wondering which metrics we are talking about - these are what I have so far. {*}EDIT{*}: Took out the response time metrics and took out the ratio * Authentication Metrics: ** authn_success_count: Number of successful authentication attempts. ** authn_failure_count: Number of failed authentication attempts. * Authorization Metrics: ** authz_success_count: Number of successful authorization checks. ** authz_failure_count: Number of failed authorization checks. * Cache Metrics: ** authn_cache_size: Size of the authentication cache. ** authn_cache_hit_count: Number of cache hits for authentication. ** authn_cache_miss_count: Number of cache misses for authentication. ** authz_cache_size: Size of the authorization cache. ** authz_cache_hit_count: Number of cache hits for authorization. ** authz_cache_miss_count: Number of cache misses for authorization. * ?Extra ** auth_cache_invalidated_count: Number of times the authn cache was invalidated. ** authz_cache_invalidated_count: Number of times the authz cache was invalidated. was (Author: JIRAUSER301522): Just wondering which metrics we are talking about - these are what I have so far. {*}EDIT{*}: Took out the response time metrics * Authentication Metrics: ** authn_success_count: Number of successful authentication attempts. ** authn_failure_count: Number of failed authentication attempts. * Authorization Metrics: ** authz_success_count: Number of successful authorization checks. ** authz_failure_count: Number of failed authorization checks. * Cache Metrics: ** authn_cache_size: Size of the authentication cache. ** authn_cache_hit_count: Number of cache hits for authentication. ** authn_cache_miss_count: Number of cache misses for authentication. ** authn_cache_hit_ratio: Ratio of cache hits to total cache lookups for authentication. ** authz_cache_size: Size of the authorization cache. ** authz_cache_hit_count: Number of cache hits for authorization. ** authz_cache_miss_count: Number of cache misses for authorization. ** authz_cache_hit_ratio: Ratio of cache hits to total cache lookups for authorization. * ?Extra ** auth_cache_invalidated_count: Number of times the authn cache was invalidated. ** authz_cache_invalidated_count: Number of times the authz cache was invalidated. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750543#comment-17750543 ] Mike Artz edited comment on ARTEMIS-4306 at 8/3/23 4:01 PM: Just wondering which metrics we are talking about - these are what I have so far. EDIT: Took out the response time metrics * Authentication Metrics: ** authn_success_count: Number of successful authentication attempts. ** authn_failure_count: Number of failed authentication attempts. * Authorization Metrics: ** authz_success_count: Number of successful authorization checks. ** authz_failure_count: Number of failed authorization checks. * Cache Metrics: ** authn_cache_size: Size of the authentication cache. ** authn_cache_hit_count: Number of cache hits for authentication. ** authn_cache_miss_count: Number of cache misses for authentication. ** authn_cache_hit_ratio: Ratio of cache hits to total cache lookups for authentication. ** authz_cache_size: Size of the authorization cache. ** authz_cache_hit_count: Number of cache hits for authorization. ** authz_cache_miss_count: Number of cache misses for authorization. ** authz_cache_hit_ratio: Ratio of cache hits to total cache lookups for authorization. * ?Extra ** auth_cache_invalidated_count: Number of times the authn cache was invalidated. ** authz_cache_invalidated_count: Number of times the authz cache was invalidated. was (Author: JIRAUSER301522): Just wondering which metrics we are talking about - these are what I have so far. Do you think some of these are unnecessary/not worth implementing and are there any obvious ones missing from the below - * Authentication Metrics: ** authn_success_count: Number of successful authentication attempts. ** authn_failure_count: Number of failed authentication attempts. ** authn_response_time: Average time taken for authentication * Authorization Metrics: ** authz_success_count: Number of successful authorization checks. ** authz_failure_count: Number of failed authorization checks. ** authz_response_time: Average time taken for authorization checks. * Cache Metrics: ** authn_cache_size: Size of the authentication cache. ** authn_cache_hit_count: Number of cache hits for authentication. ** authn_cache_miss_count: Number of cache misses for authentication. ** authn_cache_hit_ratio: Ratio of cache hits to total cache lookups for authentication. ** authz_cache_size: Size of the authorization cache. ** authz_cache_hit_count: Number of cache hits for authorization. ** authz_cache_miss_count: Number of cache misses for authorization. ** authz_cache_hit_ratio: Ratio of cache hits to total cache lookups for authorization. * ?Extra ** auth_cache_invalidated_count: Number of times the authn cache was invalidated. ** authz_cache_invalidated_count: Number of times the authz cache was invalidated. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750543#comment-17750543 ] Mike Artz edited comment on ARTEMIS-4306 at 8/3/23 4:01 PM: Just wondering which metrics we are talking about - these are what I have so far. {*}EDIT{*}: Took out the response time metrics * Authentication Metrics: ** authn_success_count: Number of successful authentication attempts. ** authn_failure_count: Number of failed authentication attempts. * Authorization Metrics: ** authz_success_count: Number of successful authorization checks. ** authz_failure_count: Number of failed authorization checks. * Cache Metrics: ** authn_cache_size: Size of the authentication cache. ** authn_cache_hit_count: Number of cache hits for authentication. ** authn_cache_miss_count: Number of cache misses for authentication. ** authn_cache_hit_ratio: Ratio of cache hits to total cache lookups for authentication. ** authz_cache_size: Size of the authorization cache. ** authz_cache_hit_count: Number of cache hits for authorization. ** authz_cache_miss_count: Number of cache misses for authorization. ** authz_cache_hit_ratio: Ratio of cache hits to total cache lookups for authorization. * ?Extra ** auth_cache_invalidated_count: Number of times the authn cache was invalidated. ** authz_cache_invalidated_count: Number of times the authz cache was invalidated. was (Author: JIRAUSER301522): Just wondering which metrics we are talking about - these are what I have so far. EDIT: Took out the response time metrics * Authentication Metrics: ** authn_success_count: Number of successful authentication attempts. ** authn_failure_count: Number of failed authentication attempts. * Authorization Metrics: ** authz_success_count: Number of successful authorization checks. ** authz_failure_count: Number of failed authorization checks. * Cache Metrics: ** authn_cache_size: Size of the authentication cache. ** authn_cache_hit_count: Number of cache hits for authentication. ** authn_cache_miss_count: Number of cache misses for authentication. ** authn_cache_hit_ratio: Ratio of cache hits to total cache lookups for authentication. ** authz_cache_size: Size of the authorization cache. ** authz_cache_hit_count: Number of cache hits for authorization. ** authz_cache_miss_count: Number of cache misses for authorization. ** authz_cache_hit_ratio: Ratio of cache hits to total cache lookups for authorization. * ?Extra ** auth_cache_invalidated_count: Number of times the authn cache was invalidated. ** authz_cache_invalidated_count: Number of times the authz cache was invalidated. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750543#comment-17750543 ] Mike Artz edited comment on ARTEMIS-4306 at 8/3/23 3:25 AM: Just wondering which metrics we are talking about - these are what I have so far. Do you think some of these are unnecessary/not worth implementing and are there any obvious ones missing from the below - * Authentication Metrics: ** authn_success_count: Number of successful authentication attempts. ** authn_failure_count: Number of failed authentication attempts. ** authn_response_time: Average time taken for authentication * Authorization Metrics: ** authz_success_count: Number of successful authorization checks. ** authz_failure_count: Number of failed authorization checks. ** authz_response_time: Average time taken for authorization checks. * Cache Metrics: ** authn_cache_size: Size of the authentication cache. ** authn_cache_hit_count: Number of cache hits for authentication. ** authn_cache_miss_count: Number of cache misses for authentication. ** authn_cache_hit_ratio: Ratio of cache hits to total cache lookups for authentication. ** authz_cache_size: Size of the authorization cache. ** authz_cache_hit_count: Number of cache hits for authorization. ** authz_cache_miss_count: Number of cache misses for authorization. ** authz_cache_hit_ratio: Ratio of cache hits to total cache lookups for authorization. * ?Extra ** auth_cache_invalidated_count: Number of times the authn cache was invalidated. ** authz_cache_invalidated_count: Number of times the authz cache was invalidated. was (Author: JIRAUSER301522): Just wondering which metrics we are talking about - these are what I have so far. Do you think some of these unnecessary/not worth implementing and are there any obvious ones missing from the below - * Authentication Metrics: ** authn_success_count: Number of successful authentication attempts. ** authn_failure_count: Number of failed authentication attempts. ** authn_response_time: Average time taken for authentication * Authorization Metrics: ** authz_success_count: Number of successful authorization checks. ** authz_failure_count: Number of failed authorization checks. ** authz_response_time: Average time taken for authorization checks. * Cache Metrics: ** authn_cache_size: Size of the authentication cache. ** authn_cache_hit_count: Number of cache hits for authentication. ** authn_cache_miss_count: Number of cache misses for authentication. ** authn_cache_hit_ratio: Ratio of cache hits to total cache lookups for authentication. ** authz_cache_size: Size of the authorization cache. ** authz_cache_hit_count: Number of cache hits for authorization. ** authz_cache_miss_count: Number of cache misses for authorization. ** authz_cache_hit_ratio: Ratio of cache hits to total cache lookups for authorization. * ?Extra ** auth_cache_invalidated_count: Number of times the authn cache was invalidated. ** authz_cache_invalidated_count: Number of times the authz cache was invalidated. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750543#comment-17750543 ] Mike Artz edited comment on ARTEMIS-4306 at 8/3/23 3:24 AM: Just wondering which metrics we are talking about - these are what I have so far. Do you think some of these unnecessary/not worth implementing and are there any obvious ones missing from the below - * Authentication Metrics: ** authn_success_count: Number of successful authentication attempts. ** authn_failure_count: Number of failed authentication attempts. ** authn_response_time: Average time taken for authentication * Authorization Metrics: ** authz_success_count: Number of successful authorization checks. ** authz_failure_count: Number of failed authorization checks. ** authz_response_time: Average time taken for authorization checks. * Cache Metrics: ** authn_cache_size: Size of the authentication cache. ** authn_cache_hit_count: Number of cache hits for authentication. ** authn_cache_miss_count: Number of cache misses for authentication. ** authn_cache_hit_ratio: Ratio of cache hits to total cache lookups for authentication. ** authz_cache_size: Size of the authorization cache. ** authz_cache_hit_count: Number of cache hits for authorization. ** authz_cache_miss_count: Number of cache misses for authorization. ** authz_cache_hit_ratio: Ratio of cache hits to total cache lookups for authorization. * ?Extra ** auth_cache_invalidated_count: Number of times the authn cache was invalidated. ** authz_cache_invalidated_count: Number of times the authz cache was invalidated. was (Author: JIRAUSER301522): Just wondering which metrics we are talking about - I listed some. Are some of these unnecessary/not worth implementing. Are there any obvious ones missing from the below - * Authentication Metrics: ** authn_success_count: Number of successful authentication attempts. ** authn_failure_count: Number of failed authentication attempts. ** authn_response_time: Average time taken for authentication * Authorization Metrics: ** authz_success_count: Number of successful authorization checks. ** authz_failure_count: Number of failed authorization checks. ** authz_response_time: Average time taken for authorization checks. * Cache Metrics: ** authn_cache_size: Size of the authentication cache. ** authn_cache_hit_count: Number of cache hits for authentication. ** authn_cache_miss_count: Number of cache misses for authentication. ** authn_cache_hit_ratio: Ratio of cache hits to total cache lookups for authentication. ** authz_cache_size: Size of the authorization cache. ** authz_cache_hit_count: Number of cache hits for authorization. ** authz_cache_miss_count: Number of cache misses for authorization. ** authz_cache_hit_ratio: Ratio of cache hits to total cache lookups for authorization. * ?Extra ** auth_cache_invalidated_count: Number of times the authn cache was invalidated. ** authz_cache_invalidated_count: Number of times the authz cache was invalidated. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750543#comment-17750543 ] Mike Artz edited comment on ARTEMIS-4306 at 8/3/23 3:22 AM: Just wondering which metrics we are talking about - I listed some. Are some of these unnecessary/not worth implementing. Are there any obvious ones missing from the below - * Authentication Metrics: ** authn_success_count: Number of successful authentication attempts. ** authn_failure_count: Number of failed authentication attempts. ** authn_response_time: Average time taken for authentication * Authorization Metrics: ** authz_success_count: Number of successful authorization checks. ** authz_failure_count: Number of failed authorization checks. ** authz_response_time: Average time taken for authorization checks. * Cache Metrics: ** authn_cache_size: Size of the authentication cache. ** authn_cache_hit_count: Number of cache hits for authentication. ** authn_cache_miss_count: Number of cache misses for authentication. ** authn_cache_hit_ratio: Ratio of cache hits to total cache lookups for authentication. ** authz_cache_size: Size of the authorization cache. ** authz_cache_hit_count: Number of cache hits for authorization. ** authz_cache_miss_count: Number of cache misses for authorization. ** authz_cache_hit_ratio: Ratio of cache hits to total cache lookups for authorization. * ?Extra ** auth_cache_invalidated_count: Number of times the authn cache was invalidated. ** authz_cache_invalidated_count: Number of times the authz cache was invalidated. was (Author: JIRAUSER301522): Just wondering which metrics we are talking about - are some of them unnecessary/too weird to implement. Also am I missing any good ones here * Authentication Metrics: ** authn_success_count: Number of successful authentication attempts. ** authn_failure_count: Number of failed authentication attempts. ** authn_response_time: Average time taken for authentication * Authorization Metrics: ** authz_success_count: Number of successful authorization checks. ** authz_failure_count: Number of failed authorization checks. ** authz_response_time: Average time taken for authorization checks. * Cache Metrics: ** authn_cache_size: Size of the authentication cache. ** authn_cache_hit_count: Number of cache hits for authentication. ** authn_cache_miss_count: Number of cache misses for authentication. ** authn_cache_hit_ratio: Ratio of cache hits to total cache lookups for authentication. ** authz_cache_size: Size of the authorization cache. ** authz_cache_hit_count: Number of cache hits for authorization. ** authz_cache_miss_count: Number of cache misses for authorization. ** authz_cache_hit_ratio: Ratio of cache hits to total cache lookups for authorization. * ?Extra ** auth_cache_invalidated_count: Number of times the authn cache was invalidated. ** authz_cache_invalidated_count: Number of times the authz cache was invalidated. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750038#comment-17750038 ] Justin Bertram edited comment on ARTEMIS-4306 at 8/1/23 11:39 PM: -- [~mike.artz], off the cuff I wouldn't expect this to be possible. In order to register a metric you need to use {{org.apache.activemq.artemis.core.server.metrics.MetricsManager}} which is not passed to security manager implementation. In any case, you'd want to implement this in {{org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl}} next to the authn/z caches so that the metrics would work regardless of the security manager implementation. was (Author: jbertram): [~mike.artz], off the cuff I wouldn't expect this to be possible. In order to register a metric you need to use {{org.apache.activemq.artemis.core.server.metrics.MetricsManager}} which is not passed to security manager implementations. In any case, you'd want to implement this in `org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl` next to the authn/z caches so that the metrics would work regardless of the security manager implementation. > Add authn/z metrics > --- > > Key: ARTEMIS-4306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4306 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > > It would be useful to have metrics for authn/z successes and failures as well > as for metrics related to the corresponding caches. -- This message was sent by Atlassian Jira (v8.20.10#820010)