The Problem: with IBM Blockchain Platform running in a Kubernetes cluster how do you get the logs to find out what happened with your contract?
This is command line stuff, so make sure that you have the
kubectl command installed and it's able to access the K8S Cluster. Or alternatively use the 'web cli'.. your choice. Access either from the 'Actions...' menu on the cluster summary page.
What is the k8s namespace?
Within K8S, each IBP instance has it's own namespace which you need to know. Saves guessing what it is from a list later on. Easiest way to find this is to first to get the 'ServiceID' of the IBP installation.
Go to the IBP instance from the Resource List, and note the Service ID
. In my case it's 7a4c1452-7572-4d57-8006-510f0c152dfc (double click the string to copy it)
Now to the command line using the service id, you can get the namespace.
kubectl get ns -l name=7a4c1452-7572-4d57-8006-510f0c152dfc NAME STATUS AGE nbe307c Active 84d
What pods are there?
Using the namespace helps limit the list of pods. The prefixs of the names should look familiar if you've done anything with IBP or Fabric before.
kubectl --namespace=nbe307c get pods NAME READY STATUS RESTARTS AGE ibp-operator-58595bff67-bqlk7 1/1 Running 0 18d orderingorgca-576b46cfc-87rmm 1/1 Running 0 2d orderingservicenode1-96cd78fc6-kkxq7 2/2 Running 0 31h org1ca-9b74dd4fd-fwzc9 1/1 Running 0 2d org1peer-5d6898fd99-hnrsm 5/5 Running 0 2d org2ca-6dcbf66d57-kwkvs 1/1 Running 0 2d org2peer-64cd465987-92ch7 5/5 Running 0 2d
We're interested in the peers in this case. For the chaincode I've got running here I know that it's on both peers, so going to use
org1peer-5d6898fd99-hnrsm as the name of the pod we're interested in
It's helpful to know now whether the peer is a v1.4.7 (the current default) or if it's been updated to v2.1.1. To help find out if you want to check copy the name of the one of the pods with a peer,
kubectl --namespace=nbe307c describe pod org1peer-5d6898fd99-hnrsm | grep ibp-peer Image: us.icr.io/ibp2/ibp-peer:1.4.7-20200618-amd64
So we know this is 1.4.7. v2.1.1 would have shown
Getting the logs
Time for the main event!
For v1.4.7: Using the namespace, and the name of the pod, let's get the chaincode logs. We'll route it to a file for later reading.
kubectl --namespace=nbe307c logs org1peer-5d6898fd99-hnrsm chaincode-logs > ibp.log
The peer log can also be interesting and useful that can be accessed by changing the
For v2.1.1 peers: You will probably have already noticed something different in the list of pods.
kubectl --namespace=nca6559 get pods NAME READY STATUS RESTARTS AGE chaincode-execution-35bccce6-865c-4337-b80c-d16b651213fb 1/1 Running 0 29h ibp-operator-c57d88665-cjswx 1/1 Running 0 31h orderingorgca-576b46cfc-cn5cn 1/1 Running 0 30h orderingservicenode1-59479765f6-p7p6h 2/2 Running 0 30h org1ca-9b74dd4fd-9qfp2 1/1 Running 0 30h org1peer-668588f746-kdbr4 4/4 Running 0 29h org2ca-6dcbf66d57-czq7c 1/1 Running 0 29h org2peer-6664fb876b-wdh66 4/4 Running 0 29h
In this case the first pod,
chaincode-execution-35bccce6-865c-4337-b80c-d16b651213fb is where the chaincode is running. Each chaincode gets it's own pod.
To access the logs it's a similar command
kubectl --namespace=nca6559 logs chaincode-execution-35bccce6-865c-4337-b80c-d16b651213fb > ibp.log
Likewise the peer log:
kubectl --namespace=nca6559 logs org1peer-668588f746-kdbr4 peer > peer.log
Reading the logs
Reading log files can be a bit tricky, there's lots in there some useful, some not-so-useful all depending on what you know about the system and what's wrong.
For chaincode there are two phases (1) when the code is being built and (2) when it's up and running.
Failures of chaincode 'to just install and instantiate' probably mean that the first, building, hasn't worked. Maybe a compilation error has crept in, or a NPM install failed etc. In a Hyperledger Fabric Dev environment it can be hard to capture this log, but in IBP it is captured.
For a v1.4.7 it's all in the log file from
chaincode-logs, for v2.1.1 look in the peer log. So if you contract or chaincode has just not started look here first. Usually any compilation or similar will be visible.
For anything else when it's up and running, again for v1.4.7 it's
chaincode-logs, and for v2.1.1 it's the log from the
But the log looks a bit different from Fabric?
Bet you're looking at the v1.4.7 log? Yes well it's 'envelope logged'. The log is there just been wrapped in another log file. So either you can use this is an excuse to learn that scripting language you've always wanted to try. Or you can cheat and use the one I've written already - go to github.com/ampretia/ibp-chaincode-log for the info.
It's a node.js tool, so assuming you've node.js installed; using the same namespace and peer pod name as above...
npm install -g @ampretia/ibp-chaincode-log kubectl --namespace=nbe307c logs org1peer-7ccbd7c5f6-7k55d -c chaincode-logs > ibp.log ibpccl --file ibp.log
The output will be a lot cleaner - note that v2.1.1 doesn't need this.
That's it! Good Luck