Its a matter of viewpoint here.. while I would agree that the needs
outlined in your note are valid.
Log4J does a good job of what I would consider the laymen spirit of logging
production , UAT ( at client site ) with real data and workflow textual
logs. The default event logging done captures the specific of class, line
number, timestamp, method et als.
* the rendered string that is 90% of the logging use is formatted
string to a file / channel with options of logging the event object to DB /
MQ et als
* the events logged do have a fair amount of information that can be
used for automation tooling around it
* the rendered string too can be usefully queried for much information
* the 7 levels of logging of info, trace, debug, warn, error allows for
optimization in production run to keep it at "warn" and reduce the
performance.
The purpose is to reduce the number of logging events routed
to an appender, performance is impacted if it goes 10 / 100 times larger..
While UAT it is typical to work with debug to get more
information of the replicated issue.
The 80-20 rule in typical enterprise is to capture the log trace of the
exception / error and use that to fix a bug, mostly trivial use of the
logging information.
Rarely if ever have I seen the log is used for deep dive analysis for
improving the product, though it certainly can be and is done.
So in log4j it is upto the configuration that allows one to log event
object or formatted strings and to have finer control over amount of log
events channelled and to any number / types of appenders eventually as per
customer convenience. Given there may be 100's of customers with varied
needs, it is ok to have that flexibility.
I do find log4j as such a very enterprise like framework, which may seem to
posses gaps you point out, but for almost 99% of its usage it fits in very
well.
On Tue, Jan 13, 2015 at 3:24 PM, Tudor Girba <tu...@tudorgirba.com> wrote:
> Hi,
>
> Log4j types of logging systems do a reasonable job at capturing log
> entries, but they are poor at helping the human make sense of the produced
> log. Of course, they do attempt, but given that they see the log as a long
> string, there is a significant mechanism built around formatting.
>
> This is broken because it implies that the human should read the log as a
> way of understanding it. This works fine for a couple of lines but fails
> miserably for even Mb logs (not to mention larger logs). One could tweak
> the formatting to make it machine readable, but in practice all logs I have
> seen in enterprise systems are mostly unstructured and one has to spend
> great effort to extract the useful information out of them. For example, I
> use the information in logs to understand performance and diagnose errors,
> and I am using automatic tools for that. But, to build those tools, the
> hardest part is to parse the log. That cost should not exist.
>
> The object as an item of logging preserves the original information so
> that the machine can read it. String is just a way of serializing an
> object, and we should only use it only in this way. Formatting still has a
> place, but it should be clear that it is just one tool - most often the
> least useful one. That is the reason why in Beacon, there is no formatting
> in the core.
>
> Priority is another thing I find rather artificial. For example,
> developers should mark as DEBUG things that are not useful in production,
> but in the end, they mark as DEBUG things that are too large to have in
> production all the time. The problem with this is that sometimes you really
> want to have access to a very specific event regardless of "priority". So,
> a better way of looking at filtering is by allowing the developer to cherry
> pick any event at any given moment.
>
> We definitely have to get good at the backend, but logging objects should
> provide a significant advantage.
>
> Cheers,
> Doru
>
>
>
> On Tue, Jan 13, 2015 at 10:05 AM, S Krish <
> krishnamachari.sudha...@gmail.com> wrote:
>
>>
>> Log4J does do Event object logging by default. I see it may be relevant
>> to roll it into log4s also. I remember Toothpick probably did that
>>
>> On Tue, Jan 13, 2015 at 11:30 AM, Hernán Morales Durand <
>> hernan.mora...@gmail.com> wrote:
>>
>>> First of all, I am not the developer of Log4s, but I have been using it
>>> for a while and I see no significant gain switching to SystemLogger or
>>> ZnLogEvent. As Alain said, it is based in Log4j, which has his own
>>> Wikipedia page: http://en.wikipedia.org/wiki/Log4j
>>>
>>> I don't think there is too much sense in having "Log Objects" around,
>>> where probably I want to tail a daily rolled log from a headless remote
>>> image. I read the documentation of SystemLogger hoping to find a mechansim
>>> which dynamically selects compression strategies based in what's logged, or
>>> some other advanced feature, but I didn't found any :(
>>>
>>> So if Object logging is implementing #asLog and #logClass methods maybe
>>> I should add them so Log4s can log "Object" :). But seriously, such
>>> comparison is not fair. Let's compare real logging features: priorities,
>>> levels, appenders, output destinations, hierarchical logging, formatting
>>> layout, etc. Many of them are implemented in Log4s.
>>>
>>> Cheers,
>>>
>>> Hernán
>>>
>>> 2015-01-12 14:56 GMT-03:00 Sven Van Caekenberghe <s...@stfx.eu>:
>>>
>>>
>>>> > On 12 Jan 2015, at 18:27, Alain Rastoul <alf.mmm....@gmail.com>
>>>> wrote:
>>>> >
>>>> > hi all,
>>>> >
>>>> > Googling a bit for a logging framework in Pharo, I found sl4j, which
>>>> sounds familiar to me.
>>>> > http://ss3.gemstone.com/ss/Log4s.html/Wiki
>>>> >
>>>> > I suppose the API is the same as the java package, as claimed by the
>>>> project page.
>>>> > I wonder if anybody is using it , or has tried it and have an advice
>>>> on that package ?
>>>> > (I saw there was no test and no comments ... :( )
>>>> >
>>>> > I think it could be great for Pharo to have a standard package like
>>>> that, a logging facility is mandatory for most -if not all- applications
>>>> >
>>>> > Any advice or pointers ?
>>>>
>>>> Object logging instead of String logging is the way to go.
>>>> SystemLogger, Beacon, Zinc's ZnLogEvent are examples. Search the mailing
>>>> list for past discussions.
>>>>
>>>> > TIA
>>>> > --
>>>> > Regards,
>>>> >
>>>> > Alain
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>
>>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>
