本节包含一些在运行IPFS集群时识别和纠正问题的技巧。
调试日志
默认情况下， ipfs-cluster-service 只有输出 INFO， WARNING 和 ERROR 消息。有时候，用--loglevel debug 旗帜增加冗长度是很有用的 。这将使ipfs-cluster及其组件更加冗长。 --debug flag变量将使ipfs-cluster，其组件及其最突出的依赖项（raft，libp2p-raft，libp2p-gorpc）冗长。
ipfs-cluster-ctl 提供一个 --debug flag变量，用于输出有关工具使用的API端点的信息。 --enc json 允许从API输出json 原始响应。
解释调试信息可能很棘手。例如：
18:21:50.343 ERROR ipfshttp: error getting:Get http://127.0.0.1:5001/api/v0/repo/stat: dial tcp 127.0.0.1:5001: getsockopt: connection refused ipfshttp.go:695
上面的一行显示了来自ipfshttp 设施的严重性错误的消息 。此工具对应于ipfshttp 实现IPFS连接器组件的模块。此信息有助于缩小发生错误的上下文。该错误消息表明该组件未能对ipfs HTTP API执行GET请求。日志条目包含记录错误的文件和行号。
鉴于所有这些上下文，我们可以发现很可能ipfs守护程序没有运行，或者无法访问。
发现问题时，如果您在寻求帮助时可以提供一些日志，则始终有用。
节点没有启动
当您的对等节点没有启动时：
- 检查日志并查找错误
- 所有的监听地址都是免费的还是由不同的进程使用？
- 集群的其他对等节点是否可达？
- 所有同行的
cluster.secret是否相同？ - 仔细检查
peerstore文件是否具有正确的内容，并且您已按照“ 启动群集”部分中的某个方法进行操作 。 - 仔细检查集群的其余部分是否处于正常状态。
- 在某些情况下，它可能有助于运行
ipfs-cluster-service state clean（特别是如果不启动的原因是筏状态和jiqun对等体之间不匹配）。假设集群是健康的，这将允许非启动对等节点在引导时从集群领导者中拉出干净状态。
节点意外地停了下来
当对等节点意外停止时：
- 确保您没有从集群中删除对等节点或触发关闭
- 检查日志中是否存在因内部故障导致进程死亡的线索
- 检查系统日志以查找是否有任何外部操作终止了该过程
- 报告任何应用程序恐慌，因为它们不应该与日志一起报告
ipfs-cluster-ctl status <cid> 不报告所有对等节点的CID信息
这通常是共享状态 和本地状态之间或本地状态 和ipfs状态之间的异步的结果。如果问题在几分钟后没有自动更正（由于自动同步），请尝试运行 ipfs-cluster-ctl sync [cid] 有问题的项目。您也可以重新启动节点。
libp2p错误
由于集群是建立在libp2p之上的，因此新用户面临的许多错误都来自libp2p并且具有令人困惑的消息，这些消息乍一看并不明显。此列表汇编了其中一些：
dial attempt failed: misdial to <peer.ID XXXXXX> through ....：这意味着您正在联系的多地址在其中具有与预期不同的对等节点。dial attempt failed: connection refused：对等节点未运行或未在预期的地址/协议/端口上侦听。dial attempt failed: context deadline exceeded：这意味着无法访问该地址或使用了错误的密码。dial backoff：与上述相同。dial attempt failed: incoming message was too large：这可能意味着您的集群对等节点没有共享相同的秘密。version not supported：这意味着您的节点正在运行不同版本的raft / cluster。