我们都知道见证人在HIVE区块链上扮演着重要的角色，比如打包出块、提供喂价、参数设定，其中根据共识打包出块是由见证人节点程序来实现的，所以保证这个程序实时在线且在出问题时能够及时切换或者下线是很重要的事情。
(图源 ：pixabay)
这篇文章中我来简单介绍一下监控以及切换&下线的实现机制。
首先说监控，我们怎么才能知道见证人节点程序是否在正常的运行呢？这个正常运行大致有两个层次：
关于第一个层次，我们可以在节点上开启对应的API插件，然后使用诸如database_api.get_dynamic_global_properties等方式获取head_block_number，time等信息，并以此判断节点程序是否在运行，有没有跟上最新块等。
但是有个问题就是，有时候虽然我们能正常同步最新块，但是由于机器性能、负载、延时等问题，导致见证人节点程序无法正常打包出块，这时候仅凭第一层次的检查是判断不出来问题的，所以需要第二层次的判断。
那么我们怎么才能知道见证人节点有没有正常出块呢？其实这个很简单，见证人没有正常出块的话，丢块数（total_missed）就会增加，所以我们只需要检测丢块数就可以啦。
我们可以通过condenser_api.get_witness_by_account来检测对应的见证人账户，并读取其中的丢块数（total_missed）和原始记录的丢块数对比，即可判断见证人节点程序是否正常出块。
通过上述分析，我们不难看出，一般情况我们其实只需要监控丢块数就可以了，如果见证人正常出块不丢块，那么程序肯定也正常运行着呢。（如果见证人排名比较低，出块间隔较大，上述结论可能不适用。）
说到切换，其实是很简单的，只不过是更新系统里见证人对应的公钥即可。
切换的前提是你有两台运行见证人节点程序的服务器（或者VPS)，并且在配置中为两个见证人节点程序配置不同的出块公私钥（比如说公钥A，私钥A；公钥B，私钥B）。
然后我们假定A为主节点，B为备份节点，系统中设置A节点对应的公钥A为见证人公钥。我们使用上述机制监控见证人的运行情况。
一旦发现新增丢块超过阈值（比如3个块），我们将系统中对应的见证人公钥设置为B节点的公钥，即完成了主备节点的切换。
我们可以使用witness_update_operation来更新系统中对应的见证人公钥。系统中当前见证人公钥可以通过condenser_api.get_witness_by_account来查看或者在https://hiveblocks.com/上查看，比如我当前的见证人公钥为：
为什么见证人要下线呢？因为当节点程序出现故障没法正常出块时，丢块数就会一直增加，并且对于整个HIVE系统，每次轮到这个出故障的见证人节点时，都要卡三秒。所以无论是对HIVE系统还是对见证人本身都不是什么好事情。
如果我们有备份节点，那么最好的方式就是切换到备份节点上去。但是如果没有备份节点，这时候最好的方式就是先将节点下线，这样系统就不会为这个下线的见证人排位了，也不会增加丢块数了。
其实下线的本质也是切换公钥（witness_update_operation），不过是切换成如下公钥了：
STM1111111111111111111111111111111114T1Anm
除了节点出故障外，如果只有单节点并且需要replay的时候，一般也应该先下线节点，否则replay一次可能要十多个小时（甚至更久），那会丢好多的块哦。
另外，除了witness_update_operation外，witness_set_properties_operation也可以实现切换公钥的功能，详细信息这里就不再赘述了。
以上内容仅介绍基本机制，具体实现大家自由发挥吧，很多成熟的HIVE库可以使用（beem、 dhive、hive-python、hivejs等）。
