bmcweb logging

[Ed Tanous]

On Fri, Oct 30, 2020 at 3:42 AM Andrei Kartashev <a.kartashev at yadro.com> wrote:
>
> Hi Ed,
>
> I disagree with you here. Once we have logs I expect to see errors
> information by default.

This imposes performance constraints.  Considering bmcweb is measured
for performance a lot, and enabling logging slows it down (quite a bit
if I remember the old testing I did) I would not be in support of any
debug level logging by default.  It should be noted, the current
logging mechanisms rely on iostreams, which also make the binary quite
a bit bigger.  Both of these aren't really acceptable as a default.

> I'm not gonna to build applications with
> verbose logging unless I debug it but but bugs could appears even you
> are not looking for them ;). Logging unusual/unexpected behaviour by
> default typically helps to localize problem.

I don't disagree, if your priorities are that debug is more important
than performance, enabling logging for all/some requests seems
reasonable.

> So I believe, we should formalize and cleanup log level usage.

I look forward to seeing the specifics of that.


PS, please don't top post when replying to the mailing list.

>
>
> On Thu, 2020-10-29 at 09:22 -0700, Ed Tanous wrote:
> > On Thu, Oct 29, 2020 at 8:47 AM Ratan Gupta <
> > ratagupt at linux.vnet.ibm.com> wrote:
> > > Hi Ed,
> > >
> > > I was having issues in getting the logs from bmcweb repo, If I
> > > don't
> > > define the compiler flag(BMCWEB_ENABLE_LOGGING) then it doesn't get
> > > me
> > > any logs in journal(not even error log) and if I define the
> > > compiler
> > > flag then it gets too much debug info.
> >
> > What's your limit for "too much"?
> >
> > > Seems it happens because we have hardcoded the logelevel  and there
> > > is
> > > no way through which we can change except making the change
> > > manually in
> > > the following place.
> > >
> > > https://github.com/openbmc/bmcweb/blob/master/http/logging.hpp#L93
> > >
> > > Suggestion is we can define another compile time flag for log level
> > > and
> > > use that log level at the above line for type of logging , by
> > > default
> > > logging should be enabled with error log level.
> >
> > Thusfar, we don't really have a definition of what kind of detail
> > should be included at each log level, nor are we consistent about
> > setting the log levels.  If it's important to you, and you want to
> > put
> > together some patches, we certainly could define the log verbosity,
> > but we'd also have to come up with better definitions for what level
> > each log needs to take, and be more consistent about it.
> >
> > IMO, that level of log granularity was never that valuable to debug,
> > my thought being that if I'm enabling logging I don't care about
> > performance, so the more logs the better.  When reproducing a
> > failure,
> > there doesn't tend to be a lot of logging present, and it's easy
> > enough to find what you want, but maybe you had a different
> > experience?
> >
> > Long term, my intent was to just get rid of the various verbosities,
> > and make logging ON or OFF in the code, and downgrade to a single
> > macro, but if you see a need, we could certainly go the other
> > direction.
> >
> > > If there is a need user can play with new compiler flag for more
> > > verbose
> > > logging.
> >
> > I don't personally see the need, but if it would help you, I don't
> > think it adds much complexity to do it, and I'd be happy to review
> > your patches.
> >
> > > Am I missing something in usage of logging infra?
> > >
> > > Ratan
> > >
> > >
> >
> > Just to be clear, you're using logging in a debug context, correct?
> > If we're trying to use this to define an access log, that's a very
> > different problem space, and the existing logging infrastructure
> > would
> > be poorly suited for it.
> --
> Best regards,
> Andrei Kartashev
>
>