关于微服务内部频繁打印与注册中心心跳错误的日志

[diwenzheng]

2021-08-25 08:23:22.473 - [ERROR] - [registry-vert.x-eventloop-thread-0] - [o.a.s.s.client.http.RestUtils] - [RestUtils.java:95] - GET /v4/default/registry/instances?rev=098714c3c29a8fde9ff7f36aa69045799053b65a&appId=redtea-es&global=true&serviceName=Alarm&env=development&version=0.0.0%2B fail, endpoint is 10.0.1.156:30100, message: Connection was closed

2021-08-25 08:23:22.474 - [WARN] - [registry-vert.x-eventloop-thread-0] - [o.a.s.s.c.h.ServiceRegistryClientImpl] - [ServiceRegistryClientImpl.java:110] - invoke service [/v4/default/registry/instances] failed, retry.

2021-08-25 08:27:22.474 - [ERROR] - [registry-vert.x-eventloop-thread-0] - [io.vertx.core.net.impl.ConnectionBase] - [ConnectionBase.java:216] - Connection reset by peer

2021-08-25 08:27:22.475 - [ERROR] - [registry-vert.x-eventloop-thread-0] - [o.a.s.s.client.http.RestUtils] - [RestUtils.java:95] - GET /v4/default/registry/instances?rev=098714c3c29a8fde9ff7f36aa69045799053b65a&appId=redtea-es&global=true&serviceName=Alarm&env=development&version=0.0.0%2B fail, endpoint is 10.0.1.47:30100, message: Connection reset by peer

2021-08-25 08:27:22.475 - [WARN] - [registry-vert.x-eventloop-thread-0] - [o.a.s.s.c.h.ServiceRegistryClientImpl] - [ServiceRegistryClientImpl.java:110] - invoke service [/v4/default/registry/instances] failed, retry.

2021-08-25 08:27:22.476 - [ERROR] - [registry-vert.x-eventloop-thread-0] - [o.a.s.s.client.http.RestUtils] - [RestUtils.java:95] - GET /v4/default/registry/instances?rev=098714c3c29a8fde9ff7f36aa69045799053b65a&appId=redtea-es&global=true&serviceName=Alarm&env=development&version=0.0.0%2B fail, endpoint is 10.0.1.47:30100, message: Connection was closed

2021-08-25 08:27:22.476 - [WARN] - [registry-vert.x-eventloop-thread-0] - [o.a.s.s.c.h.ServiceRegistryClientImpl] - [ServiceRegistryClientImpl.java:110] - invoke service [/v4/default/registry/instances] failed, retry.

[diwenzheng]

微服务测配置的是60s,错误次数是6次,注册中心有三个副本,每个副本采用一个etcd,因部署方式是swarm的,所以我们在指定注册中心地址的地方指定的是对内的集群VIP,可以理解成有三个注册中心然后外面有个nginx,服务内部配置的是nginx的ip.
目前实例数不是很多,大概20多个的微服务实例,发现不是很频发的打印这些日志.

[diwenzheng]

这种必定是可靠性隐患,考虑的后续实例数平滑扩容,注册中心是否会有性能瓶颈,有没有关于注册中心性能瓶颈的用例?又或者如何能优化这样的现象,还是说我们指定的注册中心ip,必须是像官方那样提供的配置多个注册中心的IP.

[diwenzheng]

@liubao68

[liubao68]

单纯从日志内容判断， “Connection reset by peer” 一般表示的是服务端主动关闭连接，通常和网络、性能有关系。 由于你提供的信息有限，无法给出详细的建议。

从经验来说， service-center在实际系统中支撑过10000+的实例管理，所以你的管理规模是非常小的。尽管如此， 你们是自行组网和安装， 影响因素是不确定的。

service-center提供了REST API，如果你需要做性能测试，可以挑选其中的REST API进行测试。运行过程中， 包括你反馈的日志，只是发送心跳， 会调用心跳接口。

[diwenzheng]

10000+那应该肯定没问题啊,可是这个日志 会周期性 在各个服务 打印,是否是我哪个参数设置不合理.还需要我提供什么相关信息.目前没想到有关的. liubao68 ***@***.***> 于2021年8月26日周四 上午9:30写道：

…

单纯从日志内容判断， “Connection reset by peer” 一般表示的是服务端主动关闭连接，通常和网络、性能有关系。 由于你提供的信息有限，无法给出详细的建议。 从经验来说， service-center在实际系统中支撑过10000+的实例管理，所以你的管理规模是非常小的。尽管如此， 你们是自行组网和安装， 影响因素是不确定的。 service-center提供了REST API，如果你需要做性能测试，可以挑选其中的REST API进行测试。运行过程中， 包括你反馈的日志，只是发送心跳， 会调用心跳接口。 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2529 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOOOHBZI5PNL5W3MHD5BYW3T6WKNDANCNFSM5CYOJ4LA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[diwenzheng]

这是注册中心的日志 看着好像是 客户端连接断开? 默认心跳的 超时时间 是多少

2021-08-26T02:13:31.259Z INFO logutil/logger.go:48 transport: loopyWriter.run returning. connection error: desc = "transport is closing"

2021-08-26T02:13:31.259Z ERROR etcd/listwatch_inner.go:76 watch prefix /cse-sr/ms/rules/ failed, start rev: 231226+1->231226->0 {"error": "rpc error: code = Canceled desc = grpc: the client connection is closing"}

2021-08-26T02:13:31.259Z ERROR etcd/listwatch_inner.go:76 watch prefix /cse-sr/ms/tags/ failed, start rev: 231226+1->231226->0 {"error": "rpc error: code = Canceled desc = grpc: the client connection is closing"}

2021-08-26T02:13:31.259Z ERROR etcd/listwatch_inner.go:76 watch prefix /cse-sr/ms/schema-sum/ failed, start rev: 231226+1->231226->0 {"error": "rpc error: code = Canceled desc = grpc: the client connection is closing"}

2021-08-26T02:13:31.259Z ERROR etcd/listwatch_inner.go:76 watch prefix /cse-pact/pact-version/ failed, start rev: 231226+1->231226->0 {"error": "rpc error: code = Canceled desc = grpc: the client connection is closing"}

2021-08-26T02:13:31.259Z ERROR etcd/listwatch_inner.go:76 watch prefix /cse-pact/version/ failed, start rev: 231226+1->231226->0 {"error": "rpc error: code = Canceled desc = grpc: the client connection is closing"}

2021-08-26T02:13:31.259Z ERROR etcd/listwatch_inner.go:76 watch prefix /cse-sr/ms/rule-indexes/ failed, start rev: 231226+1->231226->0 {"error": "rpc error: code = Canceled desc = grpc: the client connection is closing"}

2021-08-26T02:13:31.259Z ERROR etcd/listwatch_inner.go:76 watch prefix /cse-pact/verification/ failed, start rev: 231226+1->231226->0 {"error": "rpc error: code = Canceled desc = grpc: the client connection is closing"}

2021-08-26T02:13:31.259Z ERROR etcd/listwatch_inner.go:76 watch prefix /cse-sr/inst/files/ failed, start rev: 231226+1->231226->0 {"error": "rpc error: code = Canceled desc = grpc: the client connection is closing"}

2021-08-26T02:13:31.259Z ERROR etcd/listwatch_inner.go:76 watch prefix /cse-sr/ms/files/ failed, start rev: 231226+1->231226->0 {"error": "rpc error: code = Canceled desc = grpc: the client connection is closing"}

2021-08-26T02:13:31.259Z ERROR etcd/listwatch_inner.go:76 wat

[diwenzheng]

从官方配置文档中看到 默认读超时时间是 3000毫秒,所以有这样的日志 我可以理解为 心跳超时时间在3S的时候,注册中心会有读超时的可能,所以客户端中断连接,这个对吗？

[diwenzheng]

还有个疑问在service-center那边一直没人回复, apache/servicecomb-service-center#1065 ,这个能麻烦帮忙解答下吗.

[diwenzheng]

还有这种日志 切换了注册中心了.这种可以理解为vip的问题?。官方推荐的的部署注册中心的形态是什么样的.是否是1个注册中心对应一个etcd,然后总共部署三个这样的,随后在注册中心地址的地方,配上这三个注册中心的地址?我这样的vip形态是否推荐.

[diwenzheng]

目前我首先更改了,关于心跳的超时时间为12000,即12秒,至此来回观察服务,老的服务会间断性打印上述的连接失败拒绝等日志,更改心跳时间的至少目前我尚未看到,所以我个人建议是否可以考虑将默认参数的时间调高.

[liubao68]

看你上面提供的信息，更像是 service-center 和 ETCD 之间的连接问题导致的。

[diwenzheng]

所以是因为etcd连接不稳定导致的心跳时间到达客户端设置3秒,从而客户端断联？

[diwenzheng]

目前是这样指定的。

etcd的部署方案

etcd 采用的是集群方案部署的.

[liubao68]

建议你到 service-center 提一个问题咨询下， 我没法解答这块的技术问题。

[diwenzheng]

建议你到 service-center 提一个问题咨询下， 我没法解答这块的技术问题。

好的感谢