I am pretty sure, I don't like mixing monitoring & statistics with logging. This clearly violates the separation of concern patterns ....
Of two evils, I prefer creating new API over misusing functionality meant for other things ... Regards Felix Am 25.02.2013 um 11:56 schrieb Bertrand Delacretaz: > On Mon, Feb 25, 2013 at 11:14 AM, Ian Boston <[email protected]> wrote: >> ...I think it's quite common when running more than a few instances to want >> to >> be able to quickly gather read only stats from all the instances. Ie a json >> feed per server. The easiest way of doing that is to have a single end >> point that delivers a bundle of counters with a time stamp... > > I tend to agree, but IMO that's a different use case than JMX which is > a more general management framework. You're looking here at a subset > which is just monitoring counters and time series. > > Keeping track of counters can also be seen as a logging activity, we > might also use slf4j markers for this? > > Using a "counter" Marker and logging at the TRACE level, for example, > to tell the logger to behave as a counter as well, and interpret > messages like +1 or -1 (which is cheap with String comparison). > > Just a rough idea, but this would avoid inventing new services, and > the resulting values can be made available both via JMX and a > "counters" HTTP endpoint, which I agree makes sense to feed tools like > Splunk. And using loggers we inherit the existing enable/disable > functionality. > > I experimented a bit with slf4j markers recently, just committed that > experiment in my whiteboard as revision 1449656 but the use case is > different - use markers to tell some loggers to ignore all messages > that don't have a specific marker. > > -Bertrand -- Felix Meschberger | Principal Scientist | Adobe
