From: Mark Kampe <mark.kampe@dreamhost.com>
To: ceph-devel@vger.kernel.org
Subject: towards a user-mode diagnostic log mechanism
Date: Mon, 19 Dec 2011 18:42:28 -0800 [thread overview]
Message-ID: <4EEFF614.8040207@dreamhost.com> (raw)
I'd like to keep this ball moving ... as I believe that the
limitations of our current logging mechanisms are already
making support difficult, and that is about to become worse.
As a first step, I'd just like to get opinions on the general
requirements we are trying to satisfy, and decisions we have
to make along the way.
Comments?
I Requirements
A. Primary Requirements (must have)
1. information captured
a. standard: time, sub-system, level, proc/thread
b. additional: operation and parameters
c. extensible for new operations
2. efficiency
a. run time overhead < 1%
(I believe this requires delayed flush circular bufferring)
b. persistent space O(Gigabytes per node-year)
3. configurability
a. capture level per sub-system
4. persistence
a. flushed out on process shut-down
b. recoverable from user-mode core-dumps
5. presentation
a. output can be processed w/grep,less,...
B. Secondary Requirements (nice to have)
1. ease of use
a. compatible with/convertable from existing calls
b. run-time definition of new event records
2. configurability
a. size/rotation rules per sub-system
b. separate in-memory/on-disk capture levels
II Decisions to be made
A. Capture Circumstances
1. some subset of procedure calls
(I'm opposed to this, but it is an option)
2. explicit event logging calls
B. Capture Format
1. ASCII text
2. per-event binary format
3. binary header + ASCII text
C. Synchronization
1. per-process vs per-thread buffers
D. Flushing
1. last writer flushes vs dedicated thread
2. single- vs double-bufferred output
E. Available open source candidates
next reply other threads:[~2011-12-20 2:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-20 2:42 Mark Kampe [this message]
2011-12-23 10:04 ` towards a user-mode diagnostic log mechanism Wido den Hollander
2012-01-06 4:09 ` Colin McCabe
2012-01-07 1:46 ` Mark Kampe
2012-01-10 2:20 ` Colin McCabe
2012-01-10 23:25 ` Tommi Virtanen
[not found] ` <4F0CDA9A.4070500@cs.ucsc.edu>
2012-01-11 1:04 ` Tommi Virtanen
2012-01-11 1:06 ` Noah Watkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EEFF614.8040207@dreamhost.com \
--to=mark.kampe@dreamhost.com \
--cc=ceph-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.