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