[ 
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<Cache>{}
AuthorizationMetrics extends CacheMeterBinder<Cache>{}{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<Cache>{}
AuthorizationMetrics extends CacheMeterBinder<Cache>{}{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)

Reply via email to