Do you have any plans to instrument `log4j2` with metrics?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Do you have any plans to instrument `log4j2` with metrics?

Yaroslav Skopets
Hi guys,

I was going through the source code of `log4j2` and didn't notice any
metrics that could tell how the system is doing.

Most importantly, classes like `AsyncAppender` might just silently drop
errors instead of making such incidents noticeable.

So, do you have any plans to introduce metrics for those cases? And,
ideally, provide bindings to libraries like `Dropwizard`, `Prometheus`,
`Micrometer` ?

Thanks in advance!

--
Best regards,
Yaroslav Skopets
Reply | Threaded
Open this post in threaded view
|

Re: Do you have any plans to instrument `log4j2` with metrics?

Ralph Goers
Development of Log4j happens based on a) what committers are interested in doing or b) patches that are submitted by users.  Sometimes we discuss things we want to develop in advance but most of the time we decide to do something and just do it.

You are the first person to ask for metrics from the AsyncAppender. We already have a JMX component so I would imagine reporting of those metrics would be integrated with that if it was implemented.

I’ve not heard anyone mention integrating with those 3 libraries.

As I noted above, patches are always welcome!

Ralph


> On Sep 30, 2017, at 4:16 PM, Yaroslav Skopets <[hidden email]> wrote:
>
> Hi guys,
>
> I was going through the source code of `log4j2` and didn't notice any
> metrics that could tell how the system is doing.
>
> Most importantly, classes like `AsyncAppender` might just silently drop
> errors instead of making such incidents noticeable.
>
> So, do you have any plans to introduce metrics for those cases? And,
> ideally, provide bindings to libraries like `Dropwizard`, `Prometheus`,
> `Micrometer` ?
>
> Thanks in advance!
>
> --
> Best regards,
> Yaroslav Skopets



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Do you have any plans to instrument `log4j2` with metrics?

Remko Popma-2
Ralph beat me to it. :-)

We could add counters to various components and make those counters visible via JMX. Surely the libraries you mention know how to consume metrics from a JMX data source.

To me a key point would be to avoid impacting performance while updating counters in multi-threaded situations.

Patches are welcome!

Remko

(Shameless plug) Every java main() method deserves http://picocli.info

> On Oct 1, 2017, at 10:00, Ralph Goers <[hidden email]> wrote:
>
> Development of Log4j happens based on a) what committers are interested in doing or b) patches that are submitted by users.  Sometimes we discuss things we want to develop in advance but most of the time we decide to do something and just do it.
>
> You are the first person to ask for metrics from the AsyncAppender. We already have a JMX component so I would imagine reporting of those metrics would be integrated with that if it was implemented.
>
> I’ve not heard anyone mention integrating with those 3 libraries.
>
> As I noted above, patches are always welcome!
>
> Ralph
>
>
>> On Sep 30, 2017, at 4:16 PM, Yaroslav Skopets <[hidden email]> wrote:
>>
>> Hi guys,
>>
>> I was going through the source code of `log4j2` and didn't notice any
>> metrics that could tell how the system is doing.
>>
>> Most importantly, classes like `AsyncAppender` might just silently drop
>> errors instead of making such incidents noticeable.
>>
>> So, do you have any plans to introduce metrics for those cases? And,
>> ideally, provide bindings to libraries like `Dropwizard`, `Prometheus`,
>> `Micrometer` ?
>>
>> Thanks in advance!
>>
>> --
>> Best regards,
>> Yaroslav Skopets
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Do you have any plans to instrument `log4j2` with metrics?

Yaroslav Skopets
Thanks a lot already!

@Ralph

Besides `AsyncAppender`, other good candidates for instrumentation would be
`BurstFilter` and `DefaultErrorHandler`.

Another angle to this are custom plugins. E.g., we've got our own
`RedisAppender` that is guarded by a rate limit, a throughput limit, etc.
And while we would like to expose how those limits work out in practice, we
don't see examples/guidelines in `log4j2` code.

By the way, how could we integrate our own plugin with JMX ? So that it
would be registered/unregistered at the same time as components provided
out-of-the-box.

@Remko

Regarding performance of counters, I've just double checked that both
`Dropwizard` and `Prometheus` address this problem by including a copy of
JDK 8 `LongAdder`/`DoubleAdder` into their own codebase (e.g.,
https://github.com/dropwizard/metrics/blob/3.2-development/metrics-core/src/main/java/com/codahale/metrics/LongAdder.java#L37
 and
https://github.com/prometheus/client_java/blob/master/simpleclient/src/main/java/io/prometheus/client/DoubleAdder.java#L35
)

So, may be `log4j2` could introduce a notion of `AdderFactory` and use it
for counters and gauges?


On Sun, Oct 1, 2017 at 3:09 AM, Remko Popma <[hidden email]> wrote:

> Ralph beat me to it. :-)
>
> We could add counters to various components and make those counters
> visible via JMX. Surely the libraries you mention know how to consume
> metrics from a JMX data source.
>
> To me a key point would be to avoid impacting performance while updating
> counters in multi-threaded situations.
>
> Patches are welcome!
>
> Remko
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Oct 1, 2017, at 10:00, Ralph Goers <[hidden email]>
> wrote:
> >
> > Development of Log4j happens based on a) what committers are interested
> in doing or b) patches that are submitted by users.  Sometimes we discuss
> things we want to develop in advance but most of the time we decide to do
> something and just do it.
> >
> > You are the first person to ask for metrics from the AsyncAppender. We
> already have a JMX component so I would imagine reporting of those metrics
> would be integrated with that if it was implemented.
> >
> > I’ve not heard anyone mention integrating with those 3 libraries.
> >
> > As I noted above, patches are always welcome!
> >
> > Ralph
> >
> >
> >> On Sep 30, 2017, at 4:16 PM, Yaroslav Skopets <[hidden email]>
> wrote:
> >>
> >> Hi guys,
> >>
> >> I was going through the source code of `log4j2` and didn't notice any
> >> metrics that could tell how the system is doing.
> >>
> >> Most importantly, classes like `AsyncAppender` might just silently drop
> >> errors instead of making such incidents noticeable.
> >>
> >> So, do you have any plans to introduce metrics for those cases? And,
> >> ideally, provide bindings to libraries like `Dropwizard`, `Prometheus`,
> >> `Micrometer` ?
> >>
> >> Thanks in advance!
> >>
> >> --
> >> Best regards,
> >> Yaroslav Skopets
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Best regards,
Yaroslav Skopets
Reply | Threaded
Open this post in threaded view
|

Re: Do you have any plans to instrument `log4j2` with metrics?

Matt Sicker
On 1 October 2017 at 04:24, Yaroslav Skopets <[hidden email]> wrote:
>
> By the way, how could we integrate our own plugin with JMX ? So that it
> would be registered/unregistered at the same time as components provided
> out-of-the-box.
>

I don't see a currently supported way of doing that. However, if
o.a.l.l.core.jmx.Server were refactored to be less of a bundle of static
methods and enhanced to allow for service discovery or use of the plugin
system, I could see that working out. Perhaps it would be simpler to
enhance the specific MBean classes (e.g., AppenderAdmin) come to think of
it.

--
Matt Sicker <[hidden email]>