> Am 23.02.2014 um 13:02 schrieb Göran Krampe <[email protected]>:
>
> Hey!
>
>> On 02/23/2014 11:34 AM, Norbert Hartl wrote:
>> Sure, seems so nobody knew about it then :)
>
> Nobody? I have posted about SimpleLog to Pharo-dev 7 times I think, first in
> 2009 or something. And in 2010, 2012, 2013 :)
>
> And its on SqueakMap, so if I were to write a new logging framework I would
> have searched the "usual places" for inspiration - but perhaps Stephane did.
>
> It was written with Gjallar a looong time ago.
>
>>> - Using syslog levels, it is very standard and logging these days of clouds
>>> do NOT stay on the local machine.
>>> - Stealing the syslog emitter, it is just 20 lines of code.
>>
>> That is a nice extension to SystemLogger.
>>
>>> - Stealing log file rotation perhaps? I think its in there.
>>
>> Are you are using this? I think it is not too common to do that in your
>> application because there are tools like logrotate that do those things way
>> better with compressing, deleting files, etc.. The only thing it needs is
>> that the filestream sees when the file is gone and reopens.
>
> Yeah, I know logrotate. I don't recall exactly why we wrote it, it was a long
> time ago.
>
> Further, regarding class behaviors or not - in SimpleLog an instance of SLLog
> is the "log book". And you can have several if you like so the logging
> behavior should IMHO definitely be on the instance side.
>
> BUT... we simply added a Defauly class var and mirrored the public interface
> on the SLLog class side. Thus for most people, you just use the class side
> behaviors.
>
> Not sure why Stephane didn't do something similar.
>
Hmm, I thought it is just like that. Log class side being just easy access
instance creation methods
Norbert
>> This is also a nice extension to the SystemLogger. The goal of the framework
>> is simplicity _and_ extendability so you can add your use case with ease.
>> I personally decided against using fluentd because I try to avoid much of
>> the system complexity if I don’t need it (I have not even close to 50000
>> reqs/s). Putting the logs from within the image into syslog only to have it
>> transported to fluentd wouldn’t be a clever thing to do. First you squeeze
>> your object into a string just to have the fluentd tool apply a filter to
>> create a json object of it. So converting a log to JSON and put it directly
>> into fluentd would be the way to go. This way you can have fluentd for the
>> buffering and for the single point of configuration for the log sink.
>> If you look at the FormattingLogger it does provide the hooks for this.
>> There is a conversion and a storing method because these are two things you
>> want to adjust if you need a different format like JSON and a different way
>> of storing (sockets, http,…).
>> I use the SystemLogger to put all the logs into elasticsearch directly.
>
> I personally do not use Fluentd, I just mentioned it. Further, AFAICT there
> is no specific JSON format, instead it wants something like:
>
> <timestamp>
> <tag>
> { ...a JSON object... }
>
>
> regards, Göran
>
> PS. Regarding syslog levels or not - I don't really care but the concept is
> very known to developers. And it is also a fairly neat way of selecting "how
> much" you want to see. On the other hand, having the sender class or similar
> in the logged entries - and a search UI like we added - that was super useful.
>
