From user-return-19068-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Dec 8 20:06:21 2011 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 93E659775 for ; Thu, 8 Dec 2011 20:06:21 +0000 (UTC) Received: (qmail 34877 invoked by uid 500); 8 Dec 2011 20:06:19 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 34839 invoked by uid 500); 8 Dec 2011 20:06:19 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 34831 invoked by uid 99); 8 Dec 2011 20:06:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Dec 2011 20:06:19 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of hvandenbulk@gmail.com designates 209.85.220.180 as permitted sender) Received: from [209.85.220.180] (HELO mail-vx0-f180.google.com) (209.85.220.180) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Dec 2011 20:06:11 +0000 Received: by vcbfo14 with SMTP id fo14so2369205vcb.11 for ; Thu, 08 Dec 2011 12:05:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=MFAs+k1o/+0/U4gg4whAiNW+1O9+Z9ELplgioGOwBr0=; b=LSQ51YocP21hMYsfIppMmm/kozmxGL+Q2npR2qL6knN14IHM3E0erMULKT9e4V+cSg 4bUEiVbaw5HQyar1CCVBLwpbDVM/H3NW8GWwyYT7Z7zGjNnI/2mq/hbZntRYlyhMwXWc JLkjtqr4Zx4aFmZq1PY8PlFNeh+TY6vOLuvDM= Received: by 10.52.28.38 with SMTP id y6mr2888569vdg.9.1323374750836; Thu, 08 Dec 2011 12:05:50 -0800 (PST) Received: from actiemac-2.denverwater.org (machine02.denverwater.org. [159.143.1.2]) by mx.google.com with ESMTPS id dn20sm1263669vdb.15.2011.12.08.12.05.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Dec 2011 12:05:49 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: The perfect logger From: GMail In-Reply-To: <20111208194417.GA12431@urvas> Date: Thu, 8 Dec 2011 13:05:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <900C39F1-FDC3-484F-B2E2-1264AE58A14A@gmail.com> References: <20111208194417.GA12431@urvas> To: user@couchdb.apache.org X-Mailer: Apple Mail (2.1251.1) How about some graylog2 GELF support or log stash? On Dec 8, 2011, at 12:44 PM, Rogut=C4=97s Sparnuotos wrote: > 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? >>=20 >> I posted a similar email in the development list, but here I am >> focusing on features that sysadmins and application developers want. >>=20 >> This is the brainstorming and requirements gathering phase. I will >> compile feedback into a spec on the wiki. >>=20 >> For me, here is what I would like to see, in no particular order: >>=20 >> * Opt-in. No surprising changes to the log format or anything. >>=20 >> * Traditional log targets such as syslog, syslog-ng >>=20 >> * One message per line, no more crazy multi-line stack traces. You >> should be able to do useful things with `perl -n` >>=20 >> * 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.) >>=20 >> * Ability to send debug, info, and error logs to different places (or = no place) >>=20 >> * Ability to send Javascript errors and logs to their own place >>=20 >> * 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. >=20 > 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? >=20 > All the other points sound very nice for sysadmins, unfortunately I = have > nothing to add, because I am still developing. >=20 > --=20 > -- Rogut=C4=97s Sparnuotos