hi,
i am thinking about logging in the osd in seastar (BTW, how about
naming it oyster? =). in seastar, we print log[1] like
seastar::logger logger{"osd"};
// ...
logger.info("i am doing fine.");
logger.error("something goes wrong: {}", std::current_exception());
and the logger will print the above messages to either stdout and/or
syslog, depending on the configurations, like:
INFO %Y-%m-%d %T,%03d [shard 0] osd - i am doing fine.
ERROR %Y-%m-%d %T,%03d [shard 0] osd - something goes wrong: std::bad_alloc
so, in comparison with the logging in Ceph, the logging in seastar
- resembles the logging module in python or printf()
- does not support fine-grained loglevel, it offers 5 log levels.
- offers APIs to adjust the log level of a certain logger. like
global_logger_registry().set_logger_level("osd", log_level::debug);
- could be slower as the writing to stdout or syslog pipe could be a
blocking write. as both of them are buffered write. if the write
buffer or the pipe is full, the reactor thread is blocked.
for taking the full advantage of seastar, i don't think we should
continue using the existing logging infrastructure, as it uses a grand
lock for protecting the log entry queue. and hence is not lock free,
and the logging thread will be competing with the seastar's reactor
thread.
we could support the streaming semantic used by ceph::logging, but we
will have to stringify all parameters even they will not be printed
according to current logging level setting. that'd be a serious
performance punishment. and neither seastar logging nor ceph::logging
prints the logging message to a string buffer in this case.
i think a compromised approach would be using a compile-time switch to
define two implementations for "dout(lv)" for the code shared by osd
and non-seastarized parts of ceph. and we can use the same facility
(stdout or syslog) and the same prefix as seastar does in our seastar
implementation, so it would be easier to debug osd-in-seastar in
future.
or we could use tracelog() in LTTNG. but it uses the same style just
like seastar and it only allows parameters supported vasprintf(3). so
it's more limited than seaststar logging.
any thoughts?
---
[1] http://docs.seastar.io/master/classseastar_1_1logger.html
--
Regards
Kefu Chai
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
