[jira] [Comment Edited] (ARTEMIS-4760) Creating MQTT consumer should work if auto-create-queues is false

[Mike Artz (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851177#comment-17851177
 ] 

Mike Artz edited comment on ARTEMIS-4760 at 5/31/24 6:40 PM:
-

It seems there should be a topic every time a consumer is created.  If that is 
the expected behavior, then do we have the consumer creation process ignore 
auto-create-queues entirely in the method 
{{{}[MQTTSubscriptionManager.createQueueForSubscription(String rawTopicName, 
String 
parsedTopicName)|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTSubscriptionManager.java#L161-L163]{}}}?

ARTEMIS-788 added that intentionally so I was just making sure.


was (Author: JIRAUSER301522):
It seems there should be a topic every time a consumer is created.  If that is 
the expected behavior, then do we have the consumer creation process ignore 
auto-create-queues entirely in the method 
{{{}MQTTSubscriptionManager.createQueueForSubscription(String rawTopicName, 
String parsedTopicName){}}}?

ARTEMIS-788 added that intentionally so I was just making sure.

> Creating MQTT consumer should work if auto-create-queues is false
> -
>
> Key: ARTEMIS-4760
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4760
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

[jira] [Comment Edited] (ARTEMIS-4760) Creating MQTT consumer should work if auto-create-queues is false

[Mike Artz (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851177#comment-17851177
 ] 

Mike Artz edited comment on ARTEMIS-4760 at 5/31/24 6:39 PM:
-

It seems there should be a topic every time a consumer is created.  If that is 
the expected behavior, then do we have the consumer creation process ignore 
auto-create-queues entirely in the method 
{{{}MQTTSubscriptionManager.createQueueForSubscription(String rawTopicName, 
String parsedTopicName){}}}?

ARTEMIS-788 added that intentionally so I was just making sure.


was (Author: JIRAUSER301522):
It seems there should be a topic every time a consumer is created.  If that is 
the expected behavior, then do we have the consumer creation process ignore 
auto-create-queues entirely in the method 
{{MQTTSubscriptionManager.createQueueForSubscription(String rawTopicName, 
String parsedTopicName)}}?}}

{{{}[ARTEMIS-788|{}}}{{{}https://issues.apache.org/jira/browse/ARTEMIS-788]{}}}

> Creating MQTT consumer should work if auto-create-queues is false
> -
>
> Key: ARTEMIS-4760
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4760
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

[jira] [Comment Edited] (ARTEMIS-4760) Creating MQTT consumer should work if auto-create-queues is false

[Mike Artz (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851177#comment-17851177
 ] 

Mike Artz edited comment on ARTEMIS-4760 at 5/31/24 6:38 PM:
-

It seems there should be a topic every time a consumer is created.  If that is 
the expected behavior, then do we have the consumer creation process ignore 
auto-create-queues entirely in the method 
{{MQTTSubscriptionManager.createQueueForSubscription(String rawTopicName, 
String parsedTopicName)}}?}}

{{{}[ARTEMIS-788|{}}}{{{}https://issues.apache.org/jira/browse/ARTEMIS-788]{}}}


was (Author: JIRAUSER301522):
It seems there should be a topic every time a consumer is created.  If that is 
the expected behavior, then do we have the consumer creation process ignore 
auto-create-queues entirely in the method 
{{MQTTSubscriptionManager.createQueueForSubscription(String rawTopicName, 
String parsedTopicName)?}}

> Creating MQTT consumer should work if auto-create-queues is false
> -
>
> Key: ARTEMIS-4760
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4760
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

[jira] [Commented] (ARTEMIS-4760) Creating MQTT consumer should work if auto-create-queues is false

[Mike Artz (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851177#comment-17851177
 ] 

Mike Artz commented on ARTEMIS-4760:


It seems there should be a topic every time a consumer is created.  If that is 
the expected behavior, then do we have the consumer creation process ignore 
auto-create-queues entirely in the method 
{{MQTTSubscriptionManager.createQueueForSubscription(String rawTopicName, 
String parsedTopicName)?}}

> Creating MQTT consumer should work if auto-create-queues is false
> -
>
> Key: ARTEMIS-4760
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4760
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

[jira] [Commented] (ARTEMIS-3957) Check for Subject on RemotingConnection before auth cache

[Mike Artz (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850884#comment-17850884
 ] 

Mike Artz commented on ARTEMIS-3957:


Oh nevermind thats my mistake sorry

> Check for Subject on RemotingConnection before auth cache
> -
>
> Key: ARTEMIS-3957
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3957
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Authenticated users automatically have their {{Subject}} set on their 
> {{RemotingConnection}}. The {{SecurityStore}} should check for this 
> {{Subject}} during authorization before checking its cache or attempting 
> re-authentication. This will avoid unnecessary traffic to the underlying 
> security repository (e.g. LDAP) in cases where the cache times out or is 
> disabled completely.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

[jira] [Commented] (ARTEMIS-3957) Check for Subject on RemotingConnection before auth cache

[Mike Artz (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850677#comment-17850677
 ] 

Mike Artz commented on ARTEMIS-3957:


This looks like it should be closed

> Check for Subject on RemotingConnection before auth cache
> -
>
> Key: ARTEMIS-3957
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3957
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Authenticated users automatically have their {{Subject}} set on their 
> {{RemotingConnection}}. The {{SecurityStore}} should check for this 
> {{Subject}} during authorization before checking its cache or attempting 
> re-authentication. This will avoid unnecessary traffic to the underlying 
> security repository (e.g. LDAP) in cases where the cache times out or is 
> disabled completely.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

[jira] [Commented] (ARTEMIS-4306) Add authn/z metrics

[Mike Artz (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850507#comment-17850507
 ] 

Mike Artz commented on ARTEMIS-4306:


Ah I was doing something kind of similar but I didn't do it fast enough. At 
first I was trying avoid changing the `SecurityStore` interface and avoid doing 
something implementation specific (like casting to the `SecurityStoreImpl`) in 
the `MetricsManager` because I thought you wouldn't have wanted to do that. But 
then I had to create a whole new class `SecurityMetricsManager` but it allowed 
me to keep the `CaffeineStatsCounter` and later on I could use 
`CaffeineStatsCounter.registerSizeMetric()` in the `MetricsManager`. 

> 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
> Fix For: 2.34.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> 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)

-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

[jira] [Comment Edited] (ARTEMIS-4306) Add authn/z metrics

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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] [Commented] (ARTEMIS-4306) Add authn/z metrics

[Mike Artz (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849099#comment-17849099
 ] 

Mike Artz commented on ARTEMIS-4306:


 

[~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 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}

 

> 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] [Commented] (ARTEMIS-4306) Add authn/z metrics

[Mike Artz (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756232#comment-17756232
 ] 

Mike Artz commented on ARTEMIS-4306:


I thought you would say that! Ok it makes sense though as all of the metrics 
that are specific to artemis do seem to have that. 

> 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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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] [Commented] (ARTEMIS-4306) Add authn/z metrics

[Mike Artz (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756191#comment-17756191
 ] 

Mike Artz commented on ARTEMIS-4306:


[~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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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] [Commented] (ARTEMIS-4306) Add authn/z metrics

[Mike Artz (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753224#comment-17753224
 ] 

Mike Artz commented on ARTEMIS-4306:


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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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

[Mike Artz (Jira)]

[ 
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] [Commented] (ARTEMIS-4306) Add authn/z metrics

[Mike Artz (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750543#comment-17750543
 ] 

Mike Artz commented on ARTEMIS-4306:


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] [Commented] (ARTEMIS-4306) Add authn/z metrics

[Mike Artz (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750030#comment-17750030
 ] 

Mike Artz commented on ARTEMIS-4306:


Do you think this could be implemented by implementing a 
ActiveMQSecurityManager?

> 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)