背景
我有一个运行时间较长的 discord 机器人(3 年以上),discord.py
它一直在 GCP 上运行,区域为 us-east4-a。该机器人k8s
使用 discord.py 1.7.2 和 python 3.9 运行。
问题
在过去一两个月里,我开始看到越来越多的连接中断,[错误 104] 对等方重置连接。重置与机器人上的活动量没有直接关系。它们在生产过程中全天间歇性发生(平均每隔几分钟)。
这些重置会导致 discord HTTP API 随机故障,并导致 WebSocket 上出现大量断开连接的情况。许多此类分片断开连接都能够恢复,但许多(每天约 200 次)最终会导致 IDENTIFY 调用(如新连接),有时会触发延长的退避等待和部分中断。
例子
以下是断开连接的一个例子:
Traceback (most recent call last):
File "/opt/venv/lib/python3.9/site-packages/discord/shard.py", line 187, in reconnect
self.ws = await asyncio.wait_for(coro, timeout=60.0)
File "/usr/local/lib/python3.9/asyncio/tasks.py", line 481, in wait_for
return fut.result()
File "/opt/venv/lib/python3.9/site-packages/discord/gateway.py", line 305, in from_client
gateway = gateway or await client.http.get_gateway()
File "/opt/venv/lib/python3.9/site-packages/discord/http.py", line 967, in get_gateway
data = await self.request(Route('GET', '/gateway'))
File "/opt/venv/lib/python3.9/site-packages/discord/http.py", line 192, in request
async with self.__session.request(method, url, **kwargs) as r:
File "/opt/venv/lib/python3.9/site-packages/aiohttp/client.py", line 1117, in __aenter__
self._resp = await self._coro
File "/opt/venv/lib/python3.9/site-packages/aiohttp/client.py", line 544, in _request
await resp.start(conn)
File "/opt/venv/lib/python3.9/site-packages/aiohttp/client_reqrep.py", line 890, in start
message, payload = await self._protocol.read() # type: ignore
File "/opt/venv/lib/python3.9/site-packages/aiohttp/streams.py", line 604, in read
await self._waiter
aiohttp.client_exceptions.ClientOSError: [Errno 104] Connection reset by peer
进行实验以找出问题
我进行了一项实验来找出导致问题的原因。我将一个包含我的机器人的容器部署到虚拟机(不是k8s
),并将其隔离,使其仅与 discord 通信(没有外部数据库),并自动向其发送命令以模拟用户行为和负载(我在同一台服务器中每分钟发送大约 60 条命令 - 远低于我的生产负载)。我运行它 20 分钟或直到我观察到连接是否重置,然后我看到以下内容:
- 在 中
us-east4-a
,我能够重现间歇性连接重置。 - 在 中
us-east4-b
,我能够重现间歇性连接重置。 - 在 中
us-east4-c
,我能够重现间歇性连接重置。 - 在
us-central1-a
,我是无法重现任何连接重置(即使 3 小时后 - 也没有任何分片断开连接)。 - 在
us-east1-b
,我是无法重现任何连接重置。 - 在我的笔记本电脑上(东海岸的住宅互联网),我无法重现任何连接重置。
所有实验均使用相同的容器、相同的机器类型和相同的测试程序。
us-east4-a
我使用多种类型的机器(最多 8 个 vCPU)以及高级和标准网络层重复了实验,但仍然看到重置。我还尝试了另一个项目中的另一台虚拟机,但连接问题始终存在us-east4
。
我有一个与 GCP 相关的支持案例,因为它似乎是一个特定于地区的问题。
我是否可以提供其他实验来尝试缩小导致此问题的原因?是否有任何常见的 GCP 配置问题可能导致此问题?
除非搬到另一个地区,否则我感觉自己没有其他选择了。
答案1
答案2
我查看了过去的答案中提到的公共问题跟踪器,但是它已经关闭,因为它缺少足够的元素来复制该问题。
此外,由于我们不了解您的 VPC 配置或防火墙规则,因此使用给定的信息进一步排除故障听起来有点棘手。
这可能不是解决您问题的方法,但我建议您向 GCP 支持部门开具支持单以便更好地解决您的问题。