[
https://issues.apache.org/jira/browse/LOG4J2-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17203530#comment-17203530
]
Ralph Goers commented on LOG4J2-2937:
-------------------------------------
Take a look at Flume's
[ChannelCounter|https://github.com/apache/flume/blob/trunk/flume-ng-core/src/main/java/org/apache/flume/instrumentation/ChannelCounter.java]
as an example. Flume provides the underlying support for MBeans and querying
via JSON. Each type of counter simply provides the attributes to be counted. It
is up to each type to figure out what those are. In Flume you can also see a
SinkCounter and a SourceCounter. So in Log4j's case you could have a
FilterCounter that identifies how many events it received, how many matched,
and how many did not. For an Appender you might instrument AppenderControl to
count the number of events received, the number of events that were accepted
and the number of errors encountered. Specific appenders, such as rolling file
could extend the counter to include the number of rollovers, etc.
> Provide counters to measure log rate
> ------------------------------------
>
> Key: LOG4J2-2937
> URL: https://issues.apache.org/jira/browse/LOG4J2-2937
> Project: Log4j 2
> Issue Type: New Feature
> Reporter: Dennys Fredericci
> Priority: Major
>
> As a Log4j API user will be really nice to have a way to get the number of
> log calls for each level without any instrumentation or bytecode
> manipulation, something native from log4j API.
> Once this interface is implemented this can be exposed through JMX or used by
> other libraries to send the log rate to monitoring systems such as Datadog,
> NewRelic, Dynatrace, etc. :)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
