I just finished writing the documentation for the emitter. This explains how the system is designed, and exactly how it will be used by libraries. (including migration strategies, and including API docs)
Any thoughts? https://github.com/SLaks/logup-emitter#readme I still need to document the hub and the configuration system, and to write all of the code. :) On Thursday, April 18, 2013 11:03:38 PM UTC-4, Schabse Laks wrote: > > *<tldr>* > I'm creating a reusable and externally configurable logging framework, > intended to be used by both libraries and applications. > What features would you want to see in it? > *</tldr>* > > *What I want* > I'm running a large Node.js website (https://unroll.me), and I want to > configure logging for each of the components used. (eg, put all trace from > each package in its own file, and have a single file with info or higher). > Coming to the Node.js world from Java, I really miss the existence of a > widespread and externally configurable logging framework like Logback > <http://logback.qos.ch/>(with SLF4J). > > In my mind, a good logging framework should: > > - Have a separate emitter component which would be used by (ideally, > all) libraries (npm packages) that want to log things > - Be version resilient (if the application uses v1.2, and it > references different libraries that use v1.1 and v1.3, everything should > still work) > - Include the package (and ideally file) that emitted each log message > in each line of output > - Allow applications (entry points) to configure log levels and > outputs (appenders, transports, whatever you call them) for logs from > different packages, with different outputs, filters, and log levels for > different packages > - (Ideally) Allow this configuration to be changed at runtime without > restarting (so you can start gathering additional log data when things > start going wrong) > - Allow both applications and libraries to attach context information > that will flow down asynchronous call chains and be associated with all > log > messages made in that context, such as user ID or HTTP request ID. (like > Logback's MDC <http://logback.qos.ch/manual/mdc.html>) > - Be runnable in a browser (with and without browserify), logging to > the JS console or to a server over websockets (the server should then run > it through its regular logging outputs) > - Not send logged messages from the browser if the server isn't > writing those levels (per component) > - Include the package and file name even from browserified packages > - Support existing Winston transports > - Be easily pluggable into older libraries that take a log function as > a config parameter (eg, Socket.io) > - Have a JSON output writer coupled to a web-based streaming viewer > for nice filtering and grouping (like > pupergrep<https://github.com/bobrik/pupergrep>), > which should: > - Highlight related messages when hovering a message (by context > key) > - Show a menu to filter by context key when clicking a message > - Stream new events over web sockets, either by reading a file live > or by a separate appender directly from the program being logged > - Support search-as-you-type > - Aggregate logs from multiple programs or servers (interleaved by > timestamp) > - Show different groups of messages (by source or context key or > package) side-by-side > - Use bookmarkable / sharable URLs for filtered and/or timeranged > views > - I will only start writing this after I finish everything else; > it's much less urgent for us. > > *Why I feel the need to re-invent the wheel* > The important feature that no existing framework (that I've been able to > find) is the ability to use it from a library. > This means three things: > > - You must be able to create a logger by specifying a name only, and > have it pick up settings from a central (application-level) configuration > - Loggers created by different versions must still share configuration > (in case different referenced packages reference different versions of the > logging framework > - Log messages emitted from each package must include the name of the > package > > Winston and Bunyan come close, but they don't have any kind of > configuration mechanism or global storage, making them impractical to use > in nested library packages. > > I also haven't found any libraries that support contextual data. > > *Where I want this to end up* > If done right, this should end up being used by all reusable libraries so > that applications can easily capture their log outputs. > For example, today, if I write a reusable library that wraps socket.io, > there is no decent way for consumers of my library to handle my log output > and socket.io's log output differently (unless the library takes lots of > config log functions) > > To this end, the library should have two separate npm packages: > > 1. An emitter, used by libraries to emit log messages (like > SLF4J<http://www.slf4j.org/>in the Java world) > 2. A sink / server / host (I'm trying to find the best term), used by > applications to configure how messages from different emitters are > consumed > (console, file, etc) > > Applications would also use the emitter to perform application-level > logging; the second package would only be used at launch time to set things > up. > > For when the emitter is used in a process that has not set up the sink / > host, the emitter should have a basic console output built-in (probably > only logging info or higher). > This means that people can get started with libraries that use the > framework, without having to add extra packages or configure anything. > It should probably also print a message instructing people to install the > second component to fully configure logging. > > *What I'm asking* > > - Is there an existing solution for this that I'm missing? > - What features would you want to see in this? > - Do you disagree with any parts of this design? What would you change? > - Once I finish writing & testing it, what would it take to get this > used by most libraries? (to replace the more-annoying log callback config > option) > - Do you want a pony? (no guarantees; sorry) > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
