Yes I agree, mixing logging with monitoring is a bit evil. It's also ugly
to do anything beyond a simple incrementing counter.
How do you all feel about a service or a singleton covering counters, set
values and possibly running mean?. I am less keen on anything that's
expensive to record as impact on the runtime must be close to zero.
@carsten. The intention is that the consuming service collects the counters
and performs first and second order differentials on the time series to
generate rate and rate of change information. Doing this outside simplifies
the the internal monitoring code and its impact on the runtime. Most
monitoring frameworks (Munin, Reconoiter) are capable of working like this
and some perfumer it. The service needs to also support set value, so that
things like queue backlog can be monitored.
I started with pure counters since it was easiest.
Ian
On Thursday, February 28, 2013, Bertrand Delacretaz wrote:
> On Wed, Feb 27, 2013 at 12:56 AM, Ian Boston <i...@tfd.co.uk <javascript:;>>
> wrote:
> ...
> > public static final Marker COUNT = MarkerFactory.getMarker("count");
> > log.info(Counter.COUNT,"read-property");...
>
> I agree with others that this looks like abusing the logging API...my
> initial idea was more like
>
> log.info(Markers.INCREMENT, "{} incremented for {}", "read-property",
> property;
>
> which would combine logging and keeping counters in a single
> call...not sure if it's practical.
>
> -Bertrand (at ApacheCon, sorry about unpredictable response times)
>
