The magic behaviour of 'logging level all LEVEL'

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Wed Jul 25 14:22:09 UTC 2018


Hi all,

for logging changes, I would welcome a comprehensive approach and maybe add an
all new set of logging commands, to not confuse with the current logging
behavior; keep and deprecate the old ones for users that were fine with those.
(I was the one responsible for the death of 'logging level all everything', and
I've stumped at least one user who now keeps patching it back in manually;
let's not repeat that.)

Maybe we can come up with more meaningful wording that more accurately indicate
what is happening? But if the current command set suffices without confusion,
we can also keep that, and maybe resurrect the 'logging level all everything'??

Here are the handles / use cases that come up -- I've embedded implementation
choices and command names in this proposal, but it's intended as a blueprint to
incorporate everyone else's bikesheds:

 A) The hardcoded logging landscape on program startup without config.
    (Maybe this isn't all that important, including it nevertheless.)
   1) a command to reset all to hardcoded defaults?

 B) A "normal" logging behavior configured by the user. We need:
   1) a command to set all categories at once
   2) a command to tweak individual categories

 C) Temporarily reducing the logging on all categories: silence the log.
    Even though a category is "normally" set to INFO, after this command it can
    be forced down to only log e.g. NOTICE. But if a category is already on
    ERROR, leave it down there and do not lift it up to NOTICE.
   1) a command to temporarily reduce all categories.
   2) a command to temporarily reduce individual categories.

 D) Temporarily increasing the logging on all categories: show everything.
    Even though a category is "normally" set to ERROR, after this command it
    can be forced up to e.g. INFO. But if a category is already up at DEBUG,
    don't reduce it to NOTICE.
   1) a command to temporarily increase all categories.
   2) a command to temporarily increase individual categories.
   3) we need to decide whether temporarily increasing is stronger/weaker than
      temporarily reducing. Depending on the implementation, it could also be
      "last one wins" (which IMHO would be best).

 T) Maybe we also want to unconditionally set temporary levels, whether they
    increase or reduce.

 E) Remove temporary logging to go back to the "normal" logging landscape.
   1) a command to put everything back to "normal",
   2) a command to put individual categories back to "normal",
   3) a separate command to only remove temporary reduction, i.e lift the
      temporary changes only if they cause less logging than normal,
   4) a separate command to only remove temporary verbosity, i.e. only lift the
      temporary changes if they cause more logging than normal.

 F) Set a specific log context, and silence all messages (regardless of their
    logging category setting) unless they match the context filter:
        logging filter imsi 123456789123456
    Though this feature has probably never been properly implemented through
    all code paths, it is potentially very powerful for live debugging.
    Especially with the new FSMs around everywhere, there is a good chance that
    we can fairly easily improve on the current 'logging filter foo'
    experience. During congress, I really yearned for this to work well.
   0) In the current implementation, on each individual log message, this
      decides whether the context matches, and if not, the message is
      discarded.
   1) Instead of discarding, we may want a level to reduce to.
   2) Or maybe we want to leave the logging landscape unchanged, but lift the
      level for all logs that match the set context?
   3) disable individual filters
   4) disable all filters. This is currently 'logging filter all 1' but that is
      confusing, we could use a meaningful synonym, and separate from filters.

 G) toggle all logging in the telnet vty
   1) silence logging (currently 'logging filter all 0', confusing)
   2) continue logging (currently 'logging filter all 1', confusing)


A bit of a meaningless image of different logging layers:

                           level
                             ^
        Hardcoded defaults.. | ... - ======    =....
  Normal logging landscape== | == .==  ... ==...  --
          Temporary levels-- | -- =....   ...== -  =
                             |   =  --   ----  -===
                             |________________________> categories

  	Same image with actual current logging overlayed:

                           level
                             ^
                             | ... # =###==    =....
                             | == .==  ... ==...  ##
         Resulting levels ## | ## #....   ...## #  =
                             |   #  ##   ####  #=#=
                             |________________________> categories

  - the hardcoded defaults are immutable.
  - the normal landscape can be freely chosen.
  - Some categories may have temporary tweaks. Where there are temporary
    tweaks, they take precedence as-is. The vty command ("make stronger" or
    "make weaker") decided whether to put a temporary level in place or not.


Can you guys explain the current patch proposals in terms of above features?
(like, use the capital letters A-G for reference)

Feel free to change this vty transcript proposal i've tossed up as I went:

! A.1) hardcoded defaults
  logging hard-reset rsl,chan,msc
  logging hard-reset

! B) set normal categories
! B.1) all
  logging set notice all
! B.2) individual
  logging set notice rsl,chan,msc

! C) Temporarily reducing
! C.1) all
  logging reduce notice all
! C.2) individual
  logging reduce error l1p,nm,cc

! D) Temporarily increasing
! D.1) all
  logging increase info all
! D.2) individual
  logging increase debug mm,rr

! D.3) last one wins
  logging reduce error l1p,mm,rr
  logging increase debug mm,rr
  logging reduce notice rr
! result: l1p=error mm=debug rr=notice

! T) set temporary level unconditionally
  logging set-temp error all
  logging set-temp error mm,rr
  ! logging (recrease|induce) ;)

! E.3) remove temporary verbosity
  no logging reduce nm,cc
  no logging reduce all
! E.4) remove temporary silencing
  no logging increase nm,cc
  no logging increase all
! E.2) snap back to normal levels
  logging reset rsl,nm,rr
! E.1) ...for all categories
  logging reset all

! F.0) context filter
  logging filter imsi 123456789123456
! F.1) choose context filter behavior
  logging filter-reduce error
  logging filter-discard
! F.2)
  logging filter-increase debug
! F.3) disable filter
  no logging filter imsi
! F.4)
  no logging filter

! G.1)
  logging [on]
  logging 1
! G.2)
  no logging
  logging 0

Using a .TEXT argument, we could easily allow a space separator for category
lists, as in "l1p mm cc". (nice would be to invent a VTY argument type that
allows any number of the same kind, so far we have weird constructs like seen
in bsc_vty.c, cfg_bts_codec0_cmd thru cfg_bts_codec4_cmd each with a different
nr of same argument)

A test program should define logging categories and a context filter, issue
each of above commands and then log once all across each level and category to
see what logging we still see.

As a final step, we should figure out how the current logging commands match
these features, and make them still do the things they always did as best as
makes sense.

What do you guys think?

About bikesheds: if we can't agree, we could put out a patch contest, where
everyone that cares implements a proposal, and we vote in the end. I hope we
don't waste time by deadlocking in the end ;)

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180725/5081dbc4/attachment.bin>


More information about the OpenBSC mailing list