couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Gable <>
Subject Re: The perfect logger
Date Wed, 07 Dec 2011 18:41:04 GMT
Perhaps someone could write a CouchDB->syslog(-ng) log output mechanism,
and then create a CouchDB destination for syslog(-ng)? That will give you
the flexibility of having log data in CouchDB if you want it (as a feature
of syslog(-ng)), or not if you don't.

Keith Gable
A+ Certified Professional
Network+ Certified Professional
Web Developer

On Wed, Dec 7, 2011 at 5:21 AM, Alexander Shorin <> wrote:

> Hi, Jason!
> Adding native support of syslog[1]/event journal (I hope, windows
> hosts wouldn't be forgotten?) will be great - it solves a lot of tasks
> about:
> what to log; what the message receiver will be; what handlers to apply
> and so on.  Of course, for windows you will have to write some script
> that will be subscribed on CouchDB journal, but each tool should do it
> own work.  However, idea with one line per message is bad if exception
> had occurred, because I need to get record that could answer on next
> questions:
> 1. What's happened?
> 2. When it was?
> 3. How it could even be?
> 4. What the environment was to help me reproduce it?
> Without stack traces this messages would be useless to get operative
> reaction on problem.
> I'd prefer to receive powerful and handy tool that would help me in
> log analyze rather than ability to easy grep from cli.
> About log database. From one side this is very sweet idea and I'm
> addicted from it too - it's very handy to make nicer log reports,
> generate events statistic and more -, but if syslog support will be
> added, so it will be his task to decide what write and where - there
> will be no needs to duplicate functionality. However, it will be great
> to receive syslog couchdb plugin out of box.
> And what about others query servers? Ruby, clojure, python...I don't
> worry about python one due to it has very powerful logging module, but
> I suppose there should be fair logging API on query server protocol
> side. By the way, someone some time has idea about adding more log
> levels to query server[2] and make them configurable. May be it's time
> to implement this feature?(:
> That's small batch of my thoughts(: Sorry for my English.
> [1]
> [2]
> --
> ,,,^..^,,,
> On Wed, Dec 7, 2011 at 6:28 AM, Jason Smith <> wrote:
> > 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.
> >
> > --
> > Iris Couch

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message