You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Dennys Fredericci (Jira)" <ji...@apache.org> on 2020/10/01 07:24:00 UTC

[jira] [Commented] (LOG4J2-2937) Provide counters to measure log rate

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

Dennys Fredericci commented on LOG4J2-2937:
-------------------------------------------

 


Hi all,

Sorry for the lack of context, I will try to give a better picture here.

I am working on [micrometer|http://micrometer.io/], a library which provides a facade for the most popular monitoring systems(NewRelic, DataDog, CloudWatch, Prometheus, Dynatrace etc.)

Micrometer already have a way to count log events based on , it is a simple counter for each level as you can see [here|]

Micrometer already has a way to count log events based on [log4j filters|https://github.com/micrometer-metrics/micrometer/blob/777493a3e876374c98f68b0f3a4535869f8b6e61/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/logging/Log4j2Metrics.java#L186], it is a simple counter for each level as you can see [here|https://github.com/micrometer-metrics/micrometer/blob/777493a3e876374c98f68b0f3a4535869f8b6e61/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/logging/Log4j2Metrics.java#L200].

After a while we noticed that the counters are not correct due to the fact that a log4j filter can be called multiple times for the same log event, this can be worst if we have a log4j async configuration.

I tried to find a workaround and other ways to add a filter programmatically but never succeeded, there is also another thread about it here LOG4J2-2918.

So instead of trying to make a workaround will be better to have log4j statistics, this can be a counter for each level as already discussed.

 
{code:java}

  Would counting be a feature a configuration would have to opt in to avoid any performance hit?

{code}
Performance-wise I think it is insignificant but you could add a way to enable/disable it programmatically. Using that approach we will have the statistics enabled only if libraries like micrometer are present in the classpath.

 
{code:java}

  Isn't there often some temporal aspect to such counters?

{code}
This is up to the library which will send the data to the monitoring system tool. Some monitoring systems expect for some types of discrete samples (such as counts) to be converted to a rate by the application prior to being published. Some expect cumulative values to always be sent. And still, others have no opinion on it either way.

There is a good explanation about it here: [http://micrometer.io/docs/concepts#_supported_monitoring_systems]

 

 

 

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