Hyperledger Fabric 2.2 配置logspout的报错及相关问题咨询

1. 127.0.0.1:8000连接被拒绝是不是预期现象？需要更换使用端口吗？ #

这个报错完全不属于正常预期，也完全不需要更换端口。
出现这个问题的本质是：monitordocker.sh启动logspout容器时，因为指定的Docker网络不存在，docker run命令执行失败，logspout根本没有被正常拉起。只有logspout容器正常处于运行状态时，才会把自身的8000服务端口映射到宿主机，对外提供日志采集接口；容器启动失败的情况下，宿主机8000端口自然没有进程监听，curl请求当然会返回连接拒绝。
默认的8000端口是Hyperledger Fabric配套工具链约定的固定服务端口，后续所有日志采集操作都是基于这个端口设计的，随意更换端口反而会导致和配套命令执行逻辑不匹配。只要把网络配置问题解决，让logspout正常启动，8000端口的连通性会自动恢复。

2. 执行monitordocker.sh需要传入的正确Docker网络名称是什么？ #

不存在可以直接套用的固定通用网络名。
很多网上的攻略会让你直接传某个固定网络名，但实际上test-network的Docker网络名称是根据Compose项目的实际运行环境动态生成的——只要你的test-network目录名不是basicnetwork，脚本默认硬编码的basicnetwork_basic网络名肯定不存在；而自己靠直觉猜的net_test、net_basic这类名称，也大概率和实际环境对不上，这就是反复报“网络不存在”的核心原因。 #

• 第一步：确认Fabric测试网络已经正常启动
  先跑命令docker ps，检查列表里有没有peer0.org1.example.com、orderer.example.com这类Fabric核心容器。如果没有这类容器，先在test-network目录下执行./network.sh up拉起基础环境，再进行后续操作。
• 第二步：提取正确的Docker网络名
  执行命令查看peer节点关联的网络，直接获取真实网络名，不要靠猜测：
  docker inspect peer0.org1.example.com --format '{{json .NetworkSettings.Networks}}'
  输出内容里的键值，就是peer节点所在的网络名称，也就是需要传给monitordocker.sh的正确参数。通常官方原版test-network启动完成后，这个网络名是test-network目录拼接默认fabric网络段生成的，和脚本内置的默认网络名有明显差异。
• 第三步：带正确参数执行脚本
  把上一步查到的网络名作为参数传入脚本，比如查到的网络名是test-network_fabric_test，就执行：
  ./monitordocker.sh test-network_fabric_test
• 第四步：验证修复效果
  1. 跑docker ps | grep logspout，确认logspout容器状态是Up，没有重启或者异常退出
  2. 再执行curl 127.0.0.1:8000/logs，正常情况下会持续输出关联网络内所有容器的日志流，连接拒绝的报错会自动消失。

• 不要靠脑补编造网络名：Docker Compose的网络命名规则是<项目名>_<compose文件内定义的网络名>，项目名会根据你启动网络时的所在目录、环境变量动态变化，没有固定值，必须从运行的容器配置里取实际值。
• 不要遇到端口不通就改端口映射：8000端口连接拒绝是logspout启动失败的连锁结果，不是端口本身被占用或者不可用，改端口只会额外增加和文档命令的匹配成本。
• 如果脚本执行时提示权限问题，先给脚本加执行权限：chmod +x monitordocker.sh，避免因为没有执行权限导致脚本逻辑没跑完就提前退出。

内容的提问来源于stack exchange，提问作者Satheesh Srinivasan