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 <[email protected]> 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] 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 <[email protected]> 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 >
