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

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。