Hi John, thanks for bringing this up. I just realized that I actually forgot to create a tracker issue for that :/ But it's probably a good idea to have that conversation beforehand anyway :) On 09/12/2018 04:43 PM, John Spray wrote: > Inspired by chatting to Volker just now, I'm wondering if we need to > think about how we want the audit log to work as higher level > functionality is added to ceph-mgr. > > Currently, the mgr and mon both send entries to the audit log when > they handle commands. When a mgr command actually calls some mon > commands under the hood, that makes things pretty spammy, and > potentially makes it harder to pick out the real human operator's > action amid all the other inter-service commands. Indeed, that's something that can already be observed when looking at the audit log via the dashboard landing page. Logging all dashboard events would add another layer of noise here. > The dashboard's REST API doesn't write to the audit log yet, but I > gather that it is desired to make it do so -- that brings similar > issues, if we are writing both the high level human "click", and also > the underlying mon commands. It could get kind of hard to read when > we're writing so much, and it would (I think?) be nice if we could > stick to logging the actual user operation, rather than all the > underlying steps in it. One option is to simply have the REST API > write to a separate audit log channel, but that feels like we're > sidestepping the general issue. That was one option that I discussed with Volker as well - the current log format is quite difficult to read and injecting log messages from the dashboard would make this look even more complicated. So our initial idea was for the dashboard to write a custom audit log in a format that is inspired by httpd access logs. But we first wanted to better understand the existing log infrastructure that is already available and how it could be utilized, so thanks for initiating this discussion. > Any thoughts? Do we want to keep the audit log as detailed as > possible (including internal mgr->mon commands), or should we try and > simplify it to have a single audit log entry per logical user > operation? > > If we want the latter then I guess that would involve tagging internal > interservice commands to suppress their audit logging, or similar. I think it probably depends on what purpose the log entries should serve. A classical "audit log" generally should answer the question: "who did what, and when?", which does not really care too much about how the action has been performed internally, but what the end result was. So I'd be in favor of having a single audit log entry per user operation and being able to "squelch the noise" and suppressing interservice commands, as to me they are more "debug" log messages, not necessarily "audit" events. Lenz -- SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany) GF:Felix Imendörffer,Jane Smithard,Graham Norton,HRB 21284 (AG Nürnberg)
Attachment:
signature.asc
Description: OpenPGP digital signature
