FISCO BCOS日志规范有哪些

FISCO BCOS日志规范有哪些，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

FISCO BCOS日志规范

为了使日志输出更加友好，FISCO BCOS 2.0设计了通用的日志格式，并根据日志输出信息的重要性对日志进行了分级。

此外，为了清晰地区分各模块日志，FISCO BCOS 2.0为各模块设计了日志关键字，并设计了各种宏来确保日志输出格式一致、方便写日志输出代码。

本节从日志格式、日志级别以及日志关键字三个方面介绍FISCO BCOS日志规范。

  通用日志格式

FISCO BCOS所有群组的日志均输出到节点log目录下的 log_%YYYY%mm%dd%HH.%MM 文件中，该日志文件每1个小时切分一次。为了区分各群组日志，使得日志输出更加友好，FISCO BCOS 2.0设计了通用日志格式。

通用日志格式如下：

log_level|time|[g:group_id][module_name]content

• log_level : 日志级别，目前主要包括 trace , debug , info ，warning, error 和 fatal ，其中在发生极其严重错误时会输出fatal

• time : 日志输出时间，精确到纳秒

   

• group_id : 输出日志记录的群组ID

   

• module_name ：模块关键字，例如同步模块关键字为SYNC ，共识模块关键字为CONSENSUS

   

• content ：日志记录内容

下面是群组3提交区块时输出的日志：

info|2019-06-2616:37:08.253147|[g:3][CONSENSUS][PBFT]^^^^^^^^Report,num=0,sealerIdx=0,hash=a4e10062...,next=1,tx=0,nodeIdx=2

该日志级别是info，输出时间是 2019-06-26 ，群组id是3，模块是 CONSENSUS ，日志关键字是 PBFT 和 Report 。

  日志级别

日志分级对于及时定位问题至关重要，FISCO BCOS 2.0 对标生产环境，将日志级别从低到高划分为 trace、debug、info、 warning、error 和 fatal ，其中：

• trace 和 debug 日志主要用于代码调试

   

• info 级别日志输出了系统关键流程，主要用于生产环境定位问题

   

• warning 日志输出了告警信息，当告警日志记录超过一定数目时，运维人员应当介入

   

• error 日志输出了核心错误信息，系统出现 error 日志时，运维人员应当介入

   

• fatal 日志一般用于程序开发调试过程中，尽快定位bug，当系统触及不可能的逻辑时，可以通过打印日志的形式终止程序，从而在开发阶段暴露逻辑错误

我们希望，在降低日志占用磁盘空间的同时，能尽量暴露、定位系统问题。为了达到这个目的，生产环境一般开启info及其以上级别的日志，FISCO BCOS建链工具生成的区块链节点默认日志级别是 info，会输出 info、warning、error 以及fatal级别的日志。

若需要调整日志级别，可以修改节点目录下的 config.ini 的 log.level 配置，如，将日志级别调整为 ≥debug ，配置如下：

[log]level=debug

  模块日志关键字

为了准确区分多个模块日志、方便定位bug和解析日志，FISCO BCOS 2.0为每个模块都定制了日志关键字，且设计了宏，方便开发者写日志输出代码的同时，保证日志输出格式一致，提升代码的可读性。

主要的日志宏包括：

• LOG_BADGE ：输出模块信息，模块信息外围用中括号 [] 括起来，从而与其他日志输出信息区分开

   

• LOG_DESC : 输出日志描述信息

   

• LOG_KV ：LOG_KV(_K, _V) 被定义为 "," << (_K) << "=" << (_V) ，主要用于输出关键变量及其对应的值

以 DEBUG 级别输出区块执行信息的例子如下：

BLOCKVERIFIER_LOG(DEBUG)<< LOG_BADGE("executeBlock")                        << LOG_DESC("Init env takes")                                              << LOG_KV("time(ms)",utcTime() - startTime)                                               <<LOG_KV("txNum",block.transactions().size())                                               << LOG_KV("num",block.blockHeader().number());

各个模块的日志关键字如下：

常用日志

网络模块、共识模块是决定区块链系统能否正常运行的重要模块，本节主要介绍这两个模块的常用日志。通过这些日志，大家可以判断区块链系统是否正常工作。

  网络模块

查看网络连接数目

可通过搜索关键字connected count 获取指定节点的网络连接情况，查看四节点区块链系统中，某个节点的网络连接情况，输出日志如下：

$ tail -f log/* |grep "connected count"info|2019-06-2618:00:01.343480|[P2P][Service] heartBeat,connected count=3

其中 connected count 表示与当前节点建立P2P网络连接的节点数。

从上面日志可看出，该节点与三个其他节点建立了P2P网络连接，符合预期。若节点连接不符合预期，则需要通过命令 netstat -anp| grep fisco-bcos 命令检查节点连接情况，找出断连节点。

证书验证失败输出日志

为了保障节点通信的机密性，FISCOBCOS节点间通信采用了openssl握手协议，需要相互间进行证书验证，在P2P 初始化过程中，若由于证书验证失败导致节点间断连，一般会输出 Certverify failed 关键字的error日志：

$ tail -f log/* |grep "Cert verify failed"error|2019-06-2621:01:01.343989|[NETWORK][Host] Cert verify failed, wrong version number

节点输出该错误时，一方面要确认节点证书是否正确，另一方面需要确认openssl版本是否升级到最新，ubuntu系统可使用 sudo apt install -y openssl 安装最新的openssl；centos系统可使用 sudo yum -y install opensslopenssl-devel 升级到最新的openssl。

  共识模块

查看Leader打包区块

FISCO BCOS 2.0共识节点轮流担任leader打包区块，成功打包区块时会输出 +++ 日志，可通过搜索群组id(记为group_id )以及 +++ 日志判断指定群组是否正常共识，若没有输出 ++ 日志，说明节点已处于异常状态，请优先检查网络连接是否正常、节点证书是否有效。

查看群组2的区块打包情况，输出日志如下：

$ tail -f log/*|grep "g:2.*++"info|2019-06-2618:00:02.551399|[g:2][CONSENSUS][SEALER]++++++++++++++++ Generating sealon,blkNum=1,tx=0,nodeIdx=3,hash=1f9c2b14...

日志中各字段的含义如下：

• blkNum : 打包区块的高度

• tx : 打包区块中包含的交易数

• nodeIdx : 当前共识节点的索引

• hash : 打包区块的哈希

从上面日志可以看出，群组2的当前leader是索引为3( nodeIdx=3 )的节点，正在打包区块高度为1( blkNum=1 )的空区块( tx=0 ，空区块不落盘)。

查看区块落盘情况

非空区块共识落盘成功或区块同步落盘成功，均会输出关键字为 Report 的日志，可通过 `tail -f log/* | grep"${group_id}.*Report" 查看区块落盘情况。

查看群组1区块落盘日志输出如下：

$ tail -f log/* |grep "g:1.*Report"info|2019-06-2618:00:07.802027|[g:1][CONSENSUS][PBFT]^^^^^^^^Report,num=716,sealerIdx=2,hash=dfd75e06...,next=717,tx=8,nodeIdx=3

其中，各个字段含义如下：

• num : 落盘区块块高

• sealerIdx : 打包该区块的共识节点索引

• hash : 落盘区块哈希

• next : 下一个区块块高

• tx : 落盘区块中包含的交易数

• nodeIdx : 当前共识节点索引

从上面日志可看出，群组1高度为716( num=716 )的区块落盘成功，出块节点是索引为2( sealerIdx=2)的共识节 点，区块哈希前8位为 dfd75e06 ，包含8笔( tx=8 )交易。

共识异常

网络抖动、网络断连或配置出错(如同一个群组的创世块文件不一致)均有可能导致节点共识异常，PBFT共识节点会输出 ViewChangeWarning 日志，可使用 tail -f log/*|grep "g:group_id.*ViewChangeWarning" 查看组group_id 是否共识异常。

组1共识异常输出日志如下：

$ tail -f log/*|grep "g:1.*ViewChangeWarning"warning|2019-06-2618:00:06.154102|[g:1][CONSENSUS][PBFT]ViewChangeWarning: not caused by omitempty block ,v=5,toV=6,curNum=715,hash=ed6e856d...,nodeIdx=3,myNode=e39000ea...

各个字段的含义如下：

• v: 当前节点PBFT共识视图

• toV: 当前节点试图切换到的视图

• curNum: 节点最高块高

• hash: 节点最高块哈希

• nodeIdx: 当前共识节点索引

• myNode: 当前节点Node ID

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注亿速云行业资讯频道，感谢您对亿速云的支持。