[
https://issues.apache.org/jira/browse/LOG4J2-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17203623#comment-17203623
]
Ralph Goers commented on LOG4J2-2937:
-------------------------------------
[~rpopma] No, there doesn't need to be. I am using Flume's REST endpoint to
query the flume statistics in Splunk and generate the dashboards below. The
File Channel Size graphs simply show the difference in the counter from one
interval to the next while the rate of successfully rated calls calculates the
number of events per second being processed. Most decent application monitoring
tooling is able to do something like this. In addition to being thread-safe
just incrementing counters is very fast and has virtually no impact on
performance.
!image-2020-09-28-21-10-13-850.png|width=1423,height=478!
> 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
> Attachments: image-2020-09-28-21-10-13-850.png
>
>
> 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)
