github.com/hechain20/hechain@v0.0.0-20220316014945-b544036ba106/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 "global 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 .. note:: Logging specification terms are separated by a colon. If a term does not include a specific logger, for example `info:` then it is applied as the default log level 78 across all loggers on the component. The string `info:dockercontroller,endorser,chaincode,chaincode.platform=debug` sets 79 the default log level to `INFO` for all loggers and then the `dockercontroller`, `endorser`, `chaincode`, and 80 `chaincode.platform` loggers are set to `DEBUG`. The order of the terms does not matter. In the examples above, 81 the second and third options produce the same result although the order of the terms is reversed. 82 83 Logging format 84 -------------- 85 86 The logging format of the ``peer`` and ``orderer`` commands is controlled 87 via the ``FABRIC_LOGGING_FORMAT`` environment variable. This can be set to 88 a format string, such as the default 89 90 :: 91 92 "%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}" 93 94 to print the logs in a human-readable console format. It can be also set to 95 ``json`` to output logs in JSON format. 96 97 98 Chaincode 99 --------- 100 101 **Chaincode logging is the responsibility of the chaincode developer.** 102 103 As independently executed programs, user-provided chaincodes may technically 104 also produce output on stdout/stderr. While naturally useful for “devmode”, 105 these channels are normally disabled on a production network to mitigate abuse 106 from broken or malicious code. However, it is possible to enable this output 107 even for peer-managed containers (e.g. “netmode”) on a per-peer basis 108 via the CORE_VM_DOCKER_ATTACHSTDOUT=true configuration option. 109 110 Once enabled, each chaincode will receive its own logging channel keyed by its 111 container-id. Any output written to either stdout or stderr will be integrated 112 with the peer’s log on a per-line basis. It is not recommended to enable this 113 for production. 114 115 Stdout and stderr not forwarded to the peer container can be viewed from the 116 chaincode container using standard commands for your container platform. 117 118 :: 119 120 docker logs <chaincode_container_id> 121 kubectl logs -n <namespace> <pod_name> 122 oc logs -n <namespace> <pod_name> 123 124 125 126 .. Licensed under Creative Commons Attribution 4.0 International License 127 https://creativecommons.org/licenses/by/4.0/