Zhuang's Diary

go-ethereum 在 2019 年 7 月推出了 Geth v1.9.x 版本。

Geth 可以通过 --metrics 命令符收集运行状态信息。 Geth v1.9.x 有3套独立的监控体系，ExpVars，InfluxDB 和 Prometheus：

1. ExpVars

是将Golang系统公共指标暴露给到HTTP接口。Geth 用 pprof 来作为埋点暴露这些公共参数。

运行 Geth –metrics –pprof 将暴露指标成为ExpVars的格式，于地址

http://127.0.0.1:6060/debug/metrics。

ExpVars 有 Golang 非常好的支持。

2. Prometheus

同理 ExpVars，运行 Geth –metrics –pprof 将暴露指标成为Prometheus的格式，于地址

http://127.0.0.1:6060/debug/metrics/prometheus。

Prometheus更加接近业界的标准。

3. InfluxDB

ExpVars 和 Prometheus 是拉取pull数据的监控方式。InfluxDB 是推送push数据的监控方式。

InfluxDB的启用有些麻烦，请参见 geth help 中的 --metrics.influxdb 及其子标识。

参数可视化

推荐使用 Grafana，建议使用 geth-prometheus 项目中给出的图表，参考链接==> https://github.com/karalabe/geth-prometheus。效果如下图：

参考文档==> Geth v1.9.0 Six months distilled

具体功能如下：

• 节点进程监控
  • 节点的存活，进程中CPU、内存使用率，IO
• 区块链数据健康监控
  • 节点出块高度历史，出块时间，出块间隔趋势，交易量历史，TPS，磁盘占用，数据目录大小增长趋势
• 运行环境监控
  • 主机运行环境的系统负载、CPU、内存、磁盘空间使用情况、网络流量、TCP 连接数等
• 故障告警通知
  • 监控告警策略
  • 支持邮件通知、短信通知
• 节点网络监控
  • 连接节点数、网络拓扑、地理位置等

仪表板的监控指标：

• Summary Dashboard
  • 各节点最新块高
  • 各节点监控进程存活
  • 各节点 CPU 使用率变化
  • 节点列表
• Node Info Dashboard
  • Chain Meta Data - 链的配置信息，如 Chain Name、创建时间等
  • Chain Info - 链的最新块高、共识节点数、共识节点出块历史趋势
  • Node Info - 选定节点的详细信息，包括区块链数据、运行环境、运行软件信息
• Host Info Dashboard
  • 各节点运行主机的信息，包括系统负载、CPU、内存、硬盘使用率、网络流量
• Process Info Dashboard
  • 节点中进程（pprof）的历史情况、CPU、内存、IO 变化历史

关于PBFT的监控，已tendermint为例，已经具备 Prometheus 监控能力。

具体参数请参见 ==> https://docs.tendermint.com/master/tendermint-core/metrics.html

List of available metrics

The following metrics are available:

go-ethereum 在 2019 年 7 月推出了 v1.9.x 版本。

Geth v1.9.0为轻型客户端提供了一种新模式，称为超轻型客户端 ultra light client。

此模式旨在将自己定位在受信任服务器和轻型服务器之间的安全范围中，用来自大多数受信任服务器的数字签名代替PoW验证。借助来自独立实体的足够签名，可以为非关键DApp实现远远超过足够的安全性。就是说，超轻量客户端模式并不是真正针对您的普通节点，而是希望将Geth嵌入到自己的流程中的项目。

轻客户端不下载和验证任何块头，而是使用硬编码检查点（hard coded checkpoint）作为起点。这个检查点包含了全部的必要的信息，从而验证之前的区块的正确性。所以从安全角度而言，没有任何的损失。

但是硬编码检查点（hard coded checkpoint）也有缺点：

• 由于检查点被硬编码到发行版二进制文件中，因此较旧的发行版将始终从较旧的块开始同步。几个月就可以了，但是最终变得很烦人。当然，您可以更新Geth来获取一个新的检查点，也可以获取所有的变更，但是很少有人希望这样做。
• 由于这些检查点已嵌入到代码中，因此如果您想在自己的专用网络中支持它们，那将很不幸，需要修改Geth，或通过配置文件配置检查点，并在每次更新检查点时分发一个新文件。可行，但长期而言并不可行。

Geth v1.9.x 附带了对链上检查点oracle的支持。超轻型客户端 ultra light client 可以不依赖于硬编码的检查点，而可以联系远程轻服务器，并要求它们返回存储在链上智能合约中的更新的检查点。最好的部分是，超轻型客户端 ultra light client 可以通过密码证明返回的数据已由所需数量的批准验证者签名！

等等，超轻型客户端 ultra light client 如何知道谁被授权签署链上检查站？对于开箱即用的受支持网络，Geth附带硬编码的检查点oracle地址和授权签署者的列表；对于专用网络，可以通过配置文件指定oracle详细信息。

尽管新旧检查点机制看起来很相似（两者都需要Geth或配置文件中的硬编码数据），但新检查点oracle只需要配置一次，然后可以任意长时间使用以发布新的检查点。

checkpoint-admin —Geth v1.9.x 附带的针对 checkpoint oracle contract 的管理工具。

checkpoint-admin 可用于查询已部署合同的状态。--rpc 需要指向一个light node，或者一个开启 --lightserv 特性的 full node。

1
2
3
4
5
6
7
8
9

$ checkpoint-admin --rpc ~/.ethereum/rinkeby/geth.ipc status
Oracle => 0xebe8eFA441B9302A0d7eaECc277c09d20D684540

Admin 1 => 0xD9C9Cd5f6779558b6e0eD4e6Acf6b1947E7fA1F3
Admin 2 => 0x78d1aD571A1A09D60D9BBf25894b44e4C8859595
Admin 3 => 0x286834935f4A8Cfb4FF4C77D5770C2775aE2b0E7
Admin 4 => 0xb86e2B0Ab5A4B1373e40c51A7C712c70Ba2f9f8E

Checkpoint (published at #4638418) 140 => 0x488c2eba92d31baeccfb6968fad5c21a3df93181b43b4cf253b4d572b64172ef

该命令也可以用户部署一个oracle，用以更新checkpoint，并publish该checkpoint到区块链网络中。

将来，checkpoint-admin 也可以离线工作，并有 clef 钱包签名。

参考文档==> Geth v1.9.0 Six months distilled

go-ethereum 在 2019 年 7 月推出了 v1.9.x 版本。1.9.x 在数据方面做了重新整理，大概有以下两个非兼容的改动：

1. 历史的区块链数据(header，body， receipts等)被挪到一个flaten file存储中，因为这部分数据已经是不会更改的了

2. 更改了部分数据结构的scheme，例如receipt。原先很多字段不需要存到db，是可以在read之后重新计算出来的。这部分会占据大量的存储空间，在1.9把这些字段删去了。

geth 有一个 inspect 命令，统计数据库详细信息。help中的内容是 inspect，Inspect the storage size for each type of data in the database。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

+-----------------+--------------------+------------+
|    DATABASE     |      CATEGORY      |    SIZE    |
+-----------------+--------------------+------------+
| Key-Value store | Headers            | 211.40 KiB |
| Key-Value store | Bodies             | 44.00 B    |
| Key-Value store | Receipts           | 42.00 B    |
| Key-Value store | Difficulties       | 19.07 KiB  |
| Key-Value store | Block number->hash | 17.24 KiB  |
| Key-Value store | Block hash->number | 845.67 KiB |
| Key-Value store | Transaction index  | 0.00 B     |
| Key-Value store | Bloombit index     | 0.00 B     |
| Key-Value store | Trie nodes         | 4.79 MiB   |
| Key-Value store | Trie preimages     | 547.13 KiB |
| Key-Value store | Clique snapshots   | 0.00 B     |
| Key-Value store | Singleton metadata | 149.00 B   |
| Ancient store   | Headers            | 5.97 MiB   |
| Ancient store   | Bodies             | 851.64 KiB |
| Ancient store   | Receipts           | 182.32 KiB |
| Ancient store   | Difficulties       | 279.10 KiB |
| Ancient store   | Block number->hash | 769.77 KiB |
| Light client    | CHT trie nodes     | 0.00 B     |
| Light client    | Bloom trie nodes   | 0.00 B     |
+-----------------+--------------------+------------+
|                         TOTAL        | 14.40 MIB  |
+-----------------+--------------------+------------+

这里的flaten file 存储，其实是把历史数据挪到了 ancient 文件夹（在前文亦有size说明），不在用 LeveldDB 存储，而用普通的二进制格式储存数据。

当从更加老的版本升级到 v1.9.x （或者Geth1.9.x重新启动）时，Geth将自动地升级Blocks和Receipts，从 LevelDB 转移到 ancient 文件夹。也可以通过手动设定 ancient 文件夹位置 --datadir.ancient 。

chaindata 存放了账本数据（cold data），默认的话，ancient 在 chaindata 里面。state 存放了业务数据（hotdata）。

• 如果 chaindata 账本数据被删除（或者指定到了错误的位置），节点将变得不可用。这种操作是命令禁止的。
• 如果 state 业务数据被删除，Geth将在 chaindata 账本数据的基础上重建其索引，并在顶部快速同步到丢失的状态数据。

参考文档==> Geth v1.9.0 Six months distilled

2019-12-20，版本1.0.4，块高89万+（约59万笔交易）

==========================================================

run 25G

|

consus.log 526M

logs 4.6G

odys.log 16M

data 19G

|

config 32K

data 2.7G — blockstore.db 1.4G / cs.wal 1G / state.db 21M / tx.index 308M

odyssey 17G

|

chaindata 17G — 平均每个文件2.1M，共计97224个文件，其中 ancient 472M

==========================================================

某项目中，2019年11月29日上线起始，截至2020年6月19日为止。用户量逐渐增大，目前的日活用户数量为10000~60000。区块高度为6,000,000以上，单个节点的磁盘用量为300G，日新增存储量为1.5G。

==========================================================

BTW：在ethereum1.9.9的版本中，geth 增加了 inspect 命令，“Inspect the storage size for each type of data in the database” ，详细情况将在下一篇文章中介绍。