github.com/yacovm/fabric@v2.0.0-alpha.0.20191128145320-c5d4087dc723+incompatible/docs/source/logging-control.rst (about)

     1  Logging Control
     2  ===============
     3  
     4  Overview
     5  --------
     6  
     7  Logging in the ``peer`` and ``orderer`` is provided by the
     8  ``common/flogging`` package. Chaincodes written in Go also use this
     9  package if they use the logging methods provided by the ``shim``.
    10  This package supports
    11  
    12  -  Logging control based on the severity of the message
    13  -  Logging control based on the software *logger* generating the message
    14  -  Different pretty-printing options based on the severity of the
    15     message
    16  
    17  All logs are currently directed to ``stderr``. Global and logger-level
    18  control of logging by severity is provided for both users and developers.
    19  There are currently no formalized rules for the types of information
    20  provided at each severity level. When submitting bug reports, developers
    21  may want to see full logs down to the DEBUG level.
    22  
    23  In pretty-printed logs the logging level is indicated both by color and
    24  by a four-character code, e.g, "ERRO" for ERROR, "DEBU" for DEBUG, etc. In
    25  the logging context a *logger* is an arbitrary name (string) given by
    26  developers to groups of related messages. In the pretty-printed example
    27  below, the loggers ``ledgermgmt``, ``kvledger``, and ``peer`` are
    28  generating logs.
    29  
    30  ::
    31  
    32     2018-11-01 15:32:38.268 UTC [ledgermgmt] initialize -> INFO 002 Initializing ledger mgmt
    33     2018-11-01 15:32:38.268 UTC [kvledger] NewProvider -> INFO 003 Initializing ledger provider
    34     2018-11-01 15:32:38.342 UTC [kvledger] NewProvider -> INFO 004 ledger provider Initialized
    35     2018-11-01 15:32:38.357 UTC [ledgermgmt] initialize -> INFO 005 ledger mgmt initialized
    36     2018-11-01 15:32:38.357 UTC [peer] func1 -> INFO 006 Auto-detected peer address: 172.24.0.3:7051
    37     2018-11-01 15:32:38.357 UTC [peer] func1 -> INFO 007 Returning peer0.org1.example.com:7051
    38  
    39  An arbitrary number of loggers can be created at runtime, therefore there is
    40  no "master list" of loggers, and logging control constructs can not check
    41  whether logging loggers actually do or will exist.
    42  
    43  Logging specification
    44  ---------------------
    45  
    46  The logging levels of the ``peer`` and ``orderer`` commands are controlled
    47  by a logging specification, which is set via the ``FABRIC_LOGGING_SPEC``
    48  environment variable.
    49  
    50  The full logging level specification is of the form
    51  
    52  ::
    53  
    54      [<logger>[,<logger>...]=]<level>[:[<logger>[,<logger>...]=]<level>...]
    55  
    56  Logging severity levels are specified using case-insensitive strings
    57  chosen from
    58  
    59  ::
    60  
    61     FATAL | PANIC | ERROR | WARNING | INFO | DEBUG
    62  
    63  
    64  A logging level by itself is taken as the overall default. Otherwise,
    65  overrides for individual or groups of loggers can be specified using the
    66  
    67  ::
    68  
    69      <logger>[,<logger>...]=<level>
    70  
    71  syntax. Examples of specifications:
    72  
    73  ::
    74  
    75      info                                        - Set default to INFO
    76      warning:msp,gossip=warning:chaincode=info   - Default WARNING; Override for msp, gossip, and chaincode
    77      chaincode=info:msp,gossip=warning:warning   - Same as above
    78  
    79  Logging format
    80  --------------
    81  
    82  The logging format of the ``peer`` and ``orderer`` commands is controlled
    83  via the ``FABRIC_LOGGING_FORMAT`` environment variable. This can be set to
    84  a format string, such as the default
    85  
    86  ::
    87  
    88     "%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}"
    89  
    90  to print the logs in a human-readable console format. It can be also set to
    91  ``json`` to output logs in JSON format.
    92  
    93  
    94  Chaincode
    95  ---------
    96  
    97  **Chaincode logging is the responsibility of the chaincode developer.**
    98  
    99  As independently executed programs, user-provided chaincodes may technically
   100  also produce output on stdout/stderr. While naturally useful for “devmode”,
   101  these channels are normally disabled on a production network to mitigate abuse
   102  from broken or malicious code. However, it is possible to enable this output
   103  even for peer-managed containers (e.g. “netmode”) on a per-peer basis
   104  via the CORE_VM_DOCKER_ATTACHSTDOUT=true configuration option.
   105  
   106  Once enabled, each chaincode will receive its own logging channel keyed by its
   107  container-id. Any output written to either stdout or stderr will be integrated
   108  with the peer’s log on a per-line basis. It is not recommended to enable this
   109  for production.
   110  
   111  Stdout and stderr not forwarded to the peer container can be viewed from the
   112  chaincode container using standard commands for your container platform.
   113  
   114  ::
   115  
   116      docker logs <chaincode_container_id>
   117      kubectl logs -n <namespace> <pod_name>
   118      oc logs -n <namespace> <pod_name>
   119  
   120  
   121  
   122  .. Licensed under Creative Commons Attribution 4.0 International License
   123     https://creativecommons.org/licenses/by/4.0/
   124