Release1/common_logging_across_OSM_components.md

   1 # Common logging across OSM components #
   2
   3 ## Proposer ##
   4 - Gerardo García (Telefónica)
   5 - Alfonso Tierno (Telefónica)
   6
   7 ## Type ##
   8 **Feature**
   9
  10 ## Target MDG/TF ##
  11 UI, RO, SO
  12
  13 ## Description ##
  14 Format and log levels in all components must be uniform so that reading and debugging become easier
  15 for end user and developer. The following is suggested:
  16
  17 - Each line should be prepended with date and time, in UTC or local time (to be decided).
  18 - Log level should be included and should be coherent across modules. Typical log levels, based on
  19 the description from [here](http://stackoverflow.com/questions/7839565/logging-levels-logback-rule-of-thumb-to-assign-log-levels "log levels"),
  20 are:
  21     - **UNSET**: no logs will be shown.
  22     - **ERROR**: the system is in distress, customers are probably being affected (or will soon be)
  23     and the fix probably requires human intervention.
  24     - **WARNING**: an unexpected technical or business event happened, customers may be affected,
  25     but probably no immediate human intervention is required.
  26     - **INFO**: things we want to see at high volume in case we need to forensically analyze an
  27     issue. System lifecycle events (system start, stop) go here. "Session" lifecycle events (login,
  28     logout, etc.) go here. Significant boundary events should be considered as well (e.g. database
  29     calls, remote API calls).
  30     - **DEBUG**: lowest level of detail, just about everything that doesn't make the "info" cut.
  31 - The module and function name should be included.
  32
  33 The specific format is to be decided. A suggestion in Python language is the following:
  34
  35 - datefmt="%Y-%m-%d %H:%M:%S"
  36 - format='%(asctime)s.%(msecs)d %(levelname)s %(module)s - %(funcName)s: %(message)s'
  37
  38
  39 ## Demo or definition of done ##
  40 Best practices for the different programming languages used in OSM (e.g. Python) should be
  41 collected in a document or wiki page.
  42
  43 A test must be also run to check that the format is appropriate. Any test is suitable, e.g.
  44 deployment of an NS instance, as long as it leads to ERROR and WARNING messages in all OSM
  45 components (UI, RO and SO). While a single test for all components is desired, another possibility
  46 is one test for each OSM component.
  47
  48 The log level must be set to DEBUG in all OSM components before running the test.
  49
  50 For each of the OSM components, the log file must be read and analyzed to find the first occurence
  51 for each of the error messages (ERROR, WARNING, INFO and DEBUG). For each of the log levels, there
  52 must be at least 1 occurrence, and the pattern must follow the agreed pattern.
  53