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