I did that, but I still get a good chunk of logs on every request: Mar 5 04:54:20 172.18.0.15 radosgw: 2013-03-05 04:54:20.279978 7f5017fef700 0 validated token: admin:admin expires: 1362541501 Mar 5 04:54:20 172.18.0.14 radosgw: 2013-03-05 04:54:20.274411 7f91c67fc700 1 ====== starting new request req=0x7f920a157410 ===== Mar 5 04:54:20 172.18.0.14 radosgw: 2013-03-05 04:54:20.274475 7f91c67fc700 2 req 2:0.000065::::initializing Mar 5 04:54:20 172.18.0.14 radosgw: 2013-03-05 04:54:20.274541 7f91c67fc700 2 req 2:0.000131:swift:GET /swift/v1::getting op Mar 5 04:54:20 172.18.0.14 radosgw: 2013-03-05 04:54:20.274545 7f91c67fc700 2 req 2:0.000135:swift:GET /swift/v1:list_buckets:authorizing Mar 5 04:54:20 172.18.0.14 radosgw: 2013-03-05 04:54:20.321919 7f91c67fc700 0 validated token: admin:admin expires: 1362541501 Mar 5 04:54:20 172.18.0.14 radosgw: 2013-03-05 04:54:20.323542 7f91c67fc700 2 req 2:0.049131:swift:GET /swift/v1:list_buckets:reading permissions Mar 5 04:54:20 172.18.0.14 radosgw: 2013-03-05 04:54:20.323559 7f91c67fc700 2 req 2:0.049149:swift:GET /swift/v1:list_buckets:verifying op permissions Mar 5 04:54:20 172.18.0.14 radosgw: 2013-03-05 04:54:20.323561 7f91c67fc700 2 req 2:0.049151:swift:GET /swift/v1:list_buckets:verifying op params Mar 5 04:54:20 172.18.0.14 radosgw: 2013-03-05 04:54:20.323563 7f91c67fc700 2 req 2:0.049153:swift:GET /swift/v1:list_buckets:executing Mar 5 04:54:20 172.18.0.14 radosgw: 2013-03-05 04:54:20.325882 7f91c67fc700 2 req 2:0.051471:swift:GET /swift/v1:list_buckets:http status=200 Mar 5 04:54:20 172.18.0.14 radosgw: 2013-03-05 04:54:20.326074 7f91c67fc700 1 ====== req done req=0x7f920a157410 http_status=200 ====== Mar 5 04:54:20 172.18.0.15 radosgw: 2013-03-05 04:54:20.391018 7f500f7de700 0 validated token: admin:admin expires: 1362541501 even dropping it down to 0 leaves some successful request logs: Mar 5 04:55:11 172.18.0.13 radosgw: 2013-03-05 04:55:11.183432 7fc2c57fa700 0 validated token: admin:admin expires: 1362541501 Mar 5 04:55:11 172.18.0.14 radosgw: 2013-03-05 04:55:11.271855 7fb477fff700 0 validated token: admin:admin expires: 1362541501 Mar 5 04:55:11 172.18.0.14 radosgw: 2013-03-05 04:55:11.327159 7fb498cf6700 0 validated token: admin:admin expires: 1362541501 which I suppose isn't so bad, but it would be great if it could be made to only log errors/warnings, and not things that are expected under normal operation (especially things that generate log entries on each successful request). On Mon, Mar 4, 2013 at 8:43 PM, Yehuda Sadeh <yehuda@xxxxxxxxxxx> wrote: > On Mon, Mar 4, 2013 at 8:16 PM, Nick Bartos <nick@xxxxxxxxxxxxxxx> wrote: >> I'm trying to figure out how to tone down the radosgw log messages, >> preferably just to warnings and errors. Here's an excerpt from a >> simple bucket list from the openstack dashboard: >> >> https://gist.github.com/anonymous/aabe9886a7c236cc2321 >> >> Note that the "radosgw.log" entries are generated from output on >> stderr of the radosgw process. Radosgw is started via upstart with >> the command: "setuidgid radosgw radosgw -c /etc/ceph/radosgw.conf -n >> client.radosgw.gateway -f" >> >> I was thinking that these were the ops and usage logs, but they are >> off by default in 0.56.3: >> >> OPTION(rgw_enable_ops_log, OPT_BOOL, false) // enable logging every >> rgw operation >> OPTION(rgw_enable_usage_log, OPT_BOOL, false) // enable logging bandwidth usage >> >> Maybe it has something to do with logging to syslog? Here's the >> logging section of our ceph.conf: >> >> [global] >> # Log only to syslog. >> log file = "" >> log to syslog = true >> clog to monitors = false >> clog to syslog = true >> mon cluster log file = "" >> mon cluster log to syslog = true >> # Don't allow log output to get put on stderr of command line commands. >> log to stderr = false > > add: > debug rgw = 2 > > Yehuda _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |