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