Created *https://github.com/joyent/node/issues/3733*
On Thu, Jul 12, 2012 at 7:21 PM, Matt <hel...@gmail.com> wrote: > In my experience most libraries don't even bother logging anything, and so > all logging ends up being custom, giving you full control over it. What are > you using that logs that you can't customise? > > > On Thu, Jul 12, 2012 at 10:21 AM, Elad Ben-Israel < > elad.benisr...@gmail.com> wrote: > >> I'm getting a vibe that no one thinks this is actually a need and >> wondering where my perception is skewed. In systems I worked on, we could >> not control all the modules we were using and make them support pluggable >> logging. I'm also wondering if this makes sense as the best practice since >> I wouldn't really want to care about this all the time and pass some >> logging object to every async call I'm making. >> >> On Wed, Jul 11, 2012 at 8:18 PM, Isaac Schlueter <i...@izs.me> wrote: >> >>> They could. Bunyan is pretty nice and has this capability as well. >>> >>> On Wed, Jul 11, 2012 at 8:51 AM, Elad Ben-Israel >>> <elad.benisr...@gmail.com> wrote: >>> > On Wed, Jul 11, 2012 at 6:34 PM, Guillermo Rauch <rau...@gmail.com> >>> wrote: >>> >> >>> >> Socket.io's logger is pluggable >>> > >>> > >>> > Unfortunately not all libraries employ pluggable logging :-) >>> > >>> >> >>> >> >>> >> >>> >> On Wednesday, July 11, 2012, Elad Ben-Israel wrote: >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Jul 11, 2012 at 5:25 PM, Matt <hel...@gmail.com> wrote: >>> >>>> >>> >>>> On Tue, Jul 10, 2012 at 6:17 PM, Elad Ben-Israel >>> >>>> <elad.benisr...@gmail.com> wrote: >>> >>>>> >>> >>>>> Not sure exactly what use case Gaurav is interested in, but I was >>> >>>>> interested in this thread because I think there is an unmet need >>> around >>> >>>>> logging which domain-attached context could help solve (even a >>> single >>> >>>>> pointer to a global instance). Logs are emitted everywhere across >>> >>>>> application (and library) stack and in node, mostly via >>> `console.xxx`. One >>> >>>>> useful feature would be to allow, for example, correlating all >>> console logs >>> >>>>> emitted during the processing of an incoming request. A few logging >>> >>>>> libraries do allow pushing context but they all require passing >>> along some >>> >>>>> state throughout the async hoops, which means modifying the way >>> logging is >>> >>>>> done throughout the entire stack. >>> >>>> >>> >>>> >>> >>>> Well yes, you can't use console.log(), but "Don't Do That" anyway, >>> it's >>> >>>> bad practice. Look at how Haraka does logging - every log line gets >>> a UUID >>> >>>> associated with the current connection/transaction. It has made >>> tracing >>> >>>> issues with mail at Craigslist an absolute dream. >>> >>>> >>> >>> >>> >>> Haraka is awesome but it has the privilege of being a 'mini >>> ecosystem' >>> >>> where plugins must adhere to the Haraka environment (in which case, >>> use the >>> >>> Haraka `this.logxxx()` functions which emit the request UUID by >>> extracting >>> >>> them from the current context in `this`). >>> >>> >>> >>> Now say you would want to create a Hakara plugin that used a library >>> like >>> >>> socket.io for example (just an example) which emits it's own logs - >>> now what >>> >>> do you do? You will need to pass the Haraka `this` pointer all the >>> way to >>> >>> every log callsite in the socket.io codebase. Not very practical. >>> >>> >>> >>> >>> >>>> >>> >>>> Matt. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Elad. >>> >> >>> >> >>> >> >>> >> -- >>> >> Guillermo Rauch >>> >> LearnBoost CTO >>> >> http://devthought.com >>> >> >>> > >>> > >>> > >>> > -- >>> > Elad. >>> >> >> >> >> -- >> Elad. >> > >
