According to http://ceph.com/docs/master/rados/configuration/ceph-conf/#logs-debugging there are in-memory logs. How are those accessed? I tried specifying 'debug rgw 0/20', but when an error occurs (such as "-1 Initialization timeout, failed to initialize"), no additional verbosity is put in the logs. I thought I recall someone telling me it could be set up to dump previous in-memory debug logs when an error is encountered, but perhaps I misunderstood. I ended up applying this small patch and setting 'debug rgw 0'. It seems like the token message shouldn't be a 0, and I wasn't sure what to do about the add_child message which is quite verbose and always going to stdout or stderr, so I just commented it out. diff -U3 -r ceph-0.56.3.orig/src/rgw/rgw_json.cc ceph-0.56.3/src/rgw/rgw_json.cc --- ceph-0.56.3.orig/src/rgw/rgw_json.cc 2013-02-13 09:21:37.000000000 -0800 +++ ceph-0.56.3/src/rgw/rgw_json.cc 2013-03-04 21:52:13.700028538 -0800 @@ -55,7 +55,7 @@ void JSONObj::add_child(string el, JSONObj *obj) { - cout << "add_child: " << name << " <- " << el << std::endl; + //cout << "add_child: " << name << " <- " << el << std::endl; children.insert(pair<string, JSONObj *>(el, obj)); } diff -U3 -r ceph-0.56.3.orig/src/rgw/rgw_swift.cc ceph-0.56.3/src/rgw/rgw_swift.cc --- ceph-0.56.3.orig/src/rgw/rgw_swift.cc 2013-02-13 10:08:29.000000000 -0800 +++ ceph-0.56.3/src/rgw/rgw_swift.cc 2013-03-04 21:03:22.631018457 -0800 @@ -497,7 +497,7 @@ return -EPERM; } - ldout(cct, 0) << "validated token: " << t.tenant_name << ":" << t.user_name << " expires: " << t.expiration << dendl; + ldout(cct, 1) << "validated token: " << t.tenant_name << ":" << t.user_name << " expires: " << t.expiration << dendl; rgw_set_keystone_token_auth_info(t, info); On Mon, Mar 4, 2013 at 8:57 PM, Nick Bartos <nick@xxxxxxxxxxxxxxx> wrote: > 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
 |