Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of kxepal@gmail.com designates
 209.85.210.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAN-3CBLfLVOfsUoWMpCahy=_f5=Uyt5tXX5hTswLgX0tETV3eA@mail.gmail.com>
References: 
 <CAN-3CBLfLVOfsUoWMpCahy=_f5=Uyt5tXX5hTswLgX0tETV3eA@mail.gmail.com>
Date: Wed, 7 Dec 2011 14:21:29 +0300
Message-ID: 
 <CAHdjipJGbHk0MhkSoeCWYs2QXYtgVz2r4fYLjDN-BmRmVPGY-Q@mail.gmail.com>
Subject: Re: The perfect logger
From: Alexander Shorin <kxepal@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

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] https://issues.apache.org/jira/browse/COUCHDB-706
[2] https://github.com/apache/couchdb/blob/master/share/server/util.js#L145

--
,,,^..^,,,


On Wed, Dec 7, 2011 at 6:28 AM, Jason Smith <jhs@iriscouch.com> 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