couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rogutės Sparnuotos <rogu...@googlemail.com>
Subject Re: The perfect logger
Date Thu, 08 Dec 2011 19:44:17 GMT
Jason Smith (2011-12-07 09:28):
> Hi, all. I am brainstorming features for the perfect CouchDB logging
> support. I want to know, if God snapped his fingers and logging in
> CouchDB was perfect according to You, what would that look like?
> 
> I posted a similar email in the development list, but here I am
> focusing on features that sysadmins and application developers want.
> 
> This is the brainstorming and requirements gathering phase. I will
> compile feedback into a spec on the wiki.
> 
> For me, here is what I would like to see, in no particular order:
> 
> * Opt-in. No surprising changes to the log format or anything.
> 
> * Traditional log targets such as syslog, syslog-ng
> 
> * One message per line, no more crazy multi-line stack traces. You
> should be able to do useful things with `perl -n`
> 
> * Javascript errors make more sense. (I know that is vague, it's not a
> personal pain point but I believe it is problematic for most people.)
> 
> * Ability to send debug, info, and error logs to different places (or no place)
> 
> * Ability to send Javascript errors and logs to their own place
> 
> * Log to a database. This is the elephant in the room. This is huge
> goal, with lots of complications. It will probably be cut from the
> first iteration. But this is basically my end game for all this. We
> want a database or databases which catches requests to our couchapp,
> vhost rules applied, rewrite rules applied, our log() calls from
> Javascript, and of course exceptions. And we want a web Couch app to
> present that and let us sort and filter. And the app will follow the
> _changes feed and give us a real-time "tail -f" of our work, minus
> Erlang stack traces.

Developers want human readable log messages, as Bade Iriabho wrote in his
thread. Is it at all possible to have those Erlang "crashes" be presented
in a saner way?

All the other points sound very nice for sysadmins, unfortunately I have
nothing to add, because I am still developing.

-- 
--  Rogutės Sparnuotos

Mime
View raw message