Description of problem: No messages are logged if we use "user.<any syslogpriority other than debug>" to route the ceph logs to syslog. The user should be able to see log messages with other priority(emerg, crit, info, err...) too. Current design does not support this. Please see BZ 1276186 also for additional details. Version-Release number of selected component (if applicable): 1.3.2 async How reproducible:always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I don't quite understand, is the problem that we output everything at the same priority level so we see either everything or nothing?
we see all messages as debug messages (priority 7) when we use "user.*" and "user.debug". If we use "user.emerg" or "user.info", we don't see any log messages at all. It looks like all messages are going to be logged as 'debug' as per current design. If a user wants to segregate the log messages based on priority then that is not not happening. Not sure if that requires some new code at ceph side.
According to Dan, we actually did this on purpose. It used to output all messages at a high priority level, but that annoyed people, so we recently changed it. I'm going to change this to an RFE to give syslog more information about the log level ceph generated the logging at so that users can use the syslog filtering instead of the ceph logging filtering?
Old title: 1.3.2: syslog: no messages logged if "user.<any syslogpriority other than debug>" is used while configuring syslog for ceph
I looked into this today and opened a bug to log at LOG_INFO so the logs at least show up in syslog since that is the desired behaviour. This probably should be backported to hammer, infernalis and jewel but I'm not sure it is worth investing much more, if any, effort into any additional functionality for two reasons. 1: Many (most?) distros are moving to journalctl based logging now and although it is possible to filter by log level in that implementation I'm not sure that it will be widely used in that regard. the good news here is that journalctl logs *all* messages by default so you don't get the LOG_INFO only and no LOG_DEBUG behaviour. On modern systems syslog is not installed by default. 2: Logging to syslog is not a widely used feature and this is demonstrated by how long it took for bz1276186 to be discovered. http://tracker.ceph.com/issues/15808 should accomplish the expected behaviour for anyone setting up logging to syslog. I think there would need to be discussion of what the exact benefits are of separating messages out into different priorities and what the expected use case would be.
https://github.com/ceph/ceph/pull/9026 It's in master, but not jewel.
It looks like it *is* in jewel? https://github.com/ceph/ceph/pull/6815 Is this bug entirely fixed in the current jewel codebase, or do we need more things?
Sam, "log: Log.cc: Assign LOG_DEBUG priority to syslog calls" has been in Jewel for a long time (definitely in RHCS 2.0). What else is there to cherry-pick for this BZ?
Ken: Yep, "log: Log.cc: Assign LOG_DEBUG priority to syslog calls" is already backported, but "log: Log.cc: Assign LOG_INFO priority to syslog calls" isn't. That's the one that needs to be backported (https://github.com/ceph/ceph/pull/9026 is what needs to be cherry-picked).
(In reply to Samuel Just from comment #12) > Ken: Yep, "log: Log.cc: Assign LOG_DEBUG priority to syslog calls" is > already backported, Right, but it was decided this was a mistake and the LOG_INFO patch was created to resolve this. > but "log: Log.cc: Assign LOG_INFO priority to syslog > calls" isn't. That's the one that needs to be backported > (https://github.com/ceph/ceph/pull/9026 is what needs to be cherry-picked). Including this is definitely a good move but I believe this Bugzilla was opened as an RFE (This should have always been an RFE) to change Ceph logging so it is able to output at multiple levels such as LOG_EMERGENCY when we log at prio "-1" such as the following code. static void simple_segv_test() { generic_dout(-1) << "triggering SIGSEGV..." << dendl; // cppcheck-suppress nullPointer int i = *get_null(); std::cout << "i = " << i << std::endl; } The following give a good description of the issue as it currently stands and the intention behind the creation of this bug and Harish should be able to confirm. https://bugzilla.redhat.com/show_bug.cgi?id=1276186#c50 https://bugzilla.redhat.com/show_bug.cgi?id=1276186#c51 https://bugzilla.redhat.com/show_bug.cgi?id=1276186#c53 https://bugzilla.redhat.com/show_bug.cgi?id=1276186#c54 https://bugzilla.redhat.com/show_bug.cgi?id=1276186#c55 Also consider comment 7.
I think without a precedent for this or a good description of how this is going to work and why we need this going forward (especially given the move to journalctl) we can probably close this however, I'll leave it open for a few days to give any interested parties the opportunity to comment.