Điểm:1

Thiết lập lại kết nối 104 không liên tục bằng ngang hàng trong GCP us-east4

lá cờ br

LAI LỊCH

Tôi có một bot bất hòa đã chạy từ lâu (hơn 3 năm) được viết bằng bất hòa.py vốn luôn chạy trên GCP, zone us-east4-a. bot chạy vào k8s sử dụng discord.py 1.7.2 và python 3.9.

VẤN ĐỀ

Trong một hoặc hai tháng qua, tôi bắt đầu nhận thấy số lần gián đoạn kết nối ngày càng tăng, [Lỗi 104] Thiết lập lại kết nối bởi máy ngang hàng. Việc đặt lại không được liên kết trực tiếp với lượng hoạt động trên bot. Chúng xảy ra không liên tục trong ngày trong quá trình sản xuất (trung bình cứ sau vài phút).

Các lần đặt lại này gây ra lỗi ngẫu nhiên đối với API HTTP bất hòa và dẫn đến mức độ ngắt kết nối cao trên WebSocket. Nhiều trường hợp ngắt kết nối phân đoạn này có thể TIẾP TỤC nhưng nhiều trường hợp (~200 mỗi ngày) kết thúc dẫn đến lệnh gọi XÁC ĐỊNH giống như một kết nối mới và đôi khi kích hoạt thời gian chờ dự phòng kéo dài và mất điện một phần.

VÍ DỤ

Đây là một ví dụ về ngắt kết nối:

Traceback (cuộc gọi gần đây nhất cuối cùng):
  Tệp "/opt/venv/lib/python3.9/site-packages/discord/shard.py", dòng 187, trong kết nối lại
    self.ws = đang chờ asyncio.wait_for(coro, timeout=60.0)
  Tệp "/usr/local/lib/python3.9/asyncio/tasks.py", dòng 481, trong wait_for
    trả lại fut.result()
  Tệp "/opt/venv/lib/python3.9/site-packages/discord/gateway.py", dòng 305, trong from_client
    cổng = cổng hoặc đang chờ client.http.get_gateway()
  Tệp "/opt/venv/lib/python3.9/site-packages/discord/http.py", dòng 967, trong get_gateway
    dữ liệu = đang chờ self.request(Route('GET', '/gateway'))
  Tệp "/opt/venv/lib/python3.9/site-packages/discord/http.py", dòng 192, theo yêu cầu
    không đồng bộ với self.__session.request(method, url, **kwargs) như r:
  Tệp "/opt/venv/lib/python3.9/site-packages/aiohttp/client.py", dòng 1117, trong __aenter__
    self._resp = đang chờ self._coro
  Tệp "/opt/venv/lib/python3.9/site-packages/aiohttp/client.py", dòng 544, trong _request
    đang chờ resp.start(conn)
  Tệp "/opt/venv/lib/python3.9/site-packages/aiohttp/client_reqrep.py", dòng 890, bắt đầu
    tin nhắn, tải trọng = đang chờ self._protocol.read() # gõ: bỏ qua
  Tệp "/opt/venv/lib/python3.9/site-packages/aiohttp/streams.py", dòng 604, ở dạng đọc
    chờ đợi chính mình._waiter
aiohttp.client_exceptions.ClientOSError: [Errno 104] Thiết lập lại kết nối bởi ngang hàng 

THÍ NGHIỆM GIẢI QUYẾT VẤN ĐỀ

Tôi đã thực hiện một thử nghiệm để tách biệt nguyên nhân gây ra sự cố. Tôi đã triển khai vùng chứa có bot của mình lên máy ảo (không phải k8s) và cô lập nó sao cho nó chỉ giao tiếp với discord (không có cơ sở dữ liệu bên ngoài) và tự động gửi cho nó các lệnh để mô phỏng hành vi và tải của người dùng (tôi gửi khoảng 60 lệnh mỗi phút trong cùng một máy chủ -- dưới mức tải sản xuất của tôi). Tôi chạy chương trình này trong 20 phút hoặc cho đến khi tôi quan sát xem có xảy ra hiện tượng đặt lại kết nối hay không và tôi thấy như sau:

  • Trong chúng tôi-đông4-a, Tôi có thể tạo lại các lần đặt lại kết nối không liên tục.
  • Trong chúng tôi-đông4-b, Tôi có thể tạo lại các lần đặt lại kết nối không liên tục.
  • Trong chúng tôi-đông4-c, Tôi có thể tạo lại các lần đặt lại kết nối không liên tục.
  • Trong chúng tôi-trung tâm1-a, Tôi là không thể tái tạo bất kỳ thiết lập lại kết nối nào (thậm chí sau 3 giờ - không có phân đoạn nào bị ngắt kết nối).
  • Trong chúng tôi-đông1-b, Tôi là không thể tái tạo bất kỳ thiết lập lại kết nối nào.
  • Trên máy tính xách tay của tôi (internet khu dân cư ở bờ biển phía đông), tôi không thể tái tạo bất kỳ thiết lập lại kết nối nào.

Tất cả các thí nghiệm đều sử dụng cùng một thùng chứa, cùng loại máy và cùng một quy trình thử nghiệm.

Tôi lặp lại thí nghiệm trong chúng tôi-đông4-a với nhiều loại máy lên đến 8 vCPU và với cả tầng mạng cao cấp và tiêu chuẩn, tôi vẫn thấy các lần đặt lại. Tôi cũng đã thử một máy ảo khác trong một dự án khác, nhưng vấn đề kết nối luôn tồn tại chúng tôi-đông4.

Tôi có một trường hợp hỗ trợ đang mở với GCP vì đây có vẻ là một vấn đề cụ thể của khu vực.

Có bất kỳ thử nghiệm bổ sung nào tôi có thể cung cấp để cố gắng thu hẹp nguyên nhân của việc này không? Có bất kỳ sự cố cấu hình GCP phổ biến nào có thể dẫn đến sự cố này không?

Không thể chuyển đến một khu vực khác, tôi cảm thấy như thể mình không còn lựa chọn nào khác.

Priya Gaikwad avatar
lá cờ us
Bạn có thể xác nhận xem sự cố của mình đã được giải quyết chưa hoặc nếu bạn vẫn đang gặp phải bất kỳ sự cố nào?
Điểm:0
lá cờ gh

Như đã đề cập trong Nhóm Google thảo luận, “Nhóm Google Cloud Compute Engine đang điều tra sự cố khu vực này xảy ra trên 'us-east4â. Bạn có thể mong đợi một bản cập nhật khác liên quan đến RCA (nếu có) trong báo cáo theo dõi vấn đề công khai. Vui lòng bình luận ở đó nữa.â Như đã đề cập trong bản cập nhật của một kênh hỗ trợ khác, tiến trình của vấn đề này có thể được theo dõi thông qua vấn đề công khai người theo dõi.

Điểm:0
lá cờ pe

Tôi đã xem xét trình theo dõi Vấn đề công khai được đề cập trong câu trả lời trước đây nhưng nó đã bị đóng vì thiếu các yếu tố để tái tạo vấn đề.

Ngoài ra, vì chúng tôi không biết về cấu hình VPC hoặc quy tắc tường lửa của bạn, nên có vẻ hơi khó để khắc phục thêm sự cố với thông tin đã cho.

Đây có thể không phải là giải pháp cho vấn đề của bạn nhưng tôi khuyên bạn nên mở một vé hỗ trợ với sự hỗ trợ của GCP để giải quyết vấn đề của bạn theo cách tốt hơn.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.