Theo dõi 4.000 máy chủ Discord: Grafana, PostHog và những gì chúng cho chúng tôi thấy

AlphaCloud chạy trên hơn 4.000 máy chủ Discord một chút, chia ra bốn shard. Đó là bốn tiến trình, mỗi tiến trình phục vụ một phần các máy chủ, và tất cả đều nói chuyện với cùng một API.

Ở quy mô này, một vấn đề hiếm khi tự lộ diện bằng cách làm hỏng thứ gì đó. Thường thì mọi thứ vẫn chạy, chỉ là tốn kém hơn, chậm hơn hoặc ồn ào hơn mức cần thiết. Đó là lý do chúng tôi xây dựng lại hệ thống giám sát vào tháng 9 năm 2026. Bài viết này cho thấy nó trông thế nào và nó đã cho chúng tôi thấy gì trong những tuần đầu tiên.

Hai công cụ, hai câu hỏi

Grafana trả lời câu hỏi: bot đang làm gì? Bot và API báo cáo số liệu cho Prometheus (yêu cầu, thời gian phản hồi, tỷ lệ lỗi, phản hồi từ Discord, mức sử dụng AI), còn nhật ký được đưa vào Loki. Mỗi nút máy chủ có bộ công cụ riêng, và Grafana chỉ truy cập được qua một mạng riêng, không phải từ internet.

PostHog trả lời câu hỏi: mọi người trải nghiệm gì trên các trang web của chúng tôi? Lượt xem trang, lỗi trình duyệt, thời gian tải và, nếu có sự đồng ý, các phiên được ghi lại. PostHog chỉ khởi động sau khi bạn đồng ý trong biểu ngữ cookie.

Sự phân chia này là có chủ đích. Grafana nhìn vào máy móc, PostHog nhìn vào giao diện. Nhồi cả hai vào một công cụ thì bạn sẽ có hoặc dữ liệu người dùng trong nhật ký máy chủ, hoặc tải máy chủ trong phân tích sản phẩm.

Những gì nó tìm thấy

Một vòng lặp tạo ra một nửa lưu lượng

Các cuộc bình chọn có thời điểm kết thúc được đóng bởi một tác vụ nền, cứ mỗi phút lại kiểm tra xem có gì đã hết hạn chưa. Nó làm việc đó cho từng máy chủ riêng lẻ. Với khoảng 1.000 máy chủ mỗi shard và bốn shard, con số lên tới khoảng 70 yêu cầu mỗi giây, gần như tất cả đều trả lời "không có gì hết hạn".

Chúng tôi chỉ nhận ra trong Grafana, khi chia các yêu cầu từ bot đến API theo đường dẫn: riêng endpoint này chiếm hơn một nửa toàn bộ lưu lượng. Mọi thứ vẫn chạy. Chỉ là nó gánh một khối tải mà không ai yêu cầu.

Giờ mỗi shard hỏi một lần mỗi phút: "Những máy chủ nào có cuộc bình chọn đã hết hạn?" và chỉ lấy chi tiết cho những máy chủ đó. Khoảng 4.200 yêu cầu mỗi phút giảm còn khoảng bốn.

Ba triệu lần "chưa thiết lập"

Cùng khuôn mẫu, khác chỗ: một số mô-đun (lượt hỗ trợ, vắng mặt, danh sách đội ngũ, thống kê bot, bản tin) thường xuyên đọc cài đặt của mọi máy chủ trong vòng lặp của chúng. Trên phần lớn máy chủ, một mô-đun nhất định hoàn toàn chưa được thiết lập, nên câu trả lời là "không tìm thấy". Khoảng ba triệu lần mỗi ngày.

Cách sửa chẳng có gì hoành tráng: một kết quả "chưa thiết lập" giờ được ghi nhớ trong 30 phút. Điều đó chỉ an toàn vì mỗi mô-đun này đều gửi cho bot một cập nhật ngay lúc nó được lưu trong bảng điều khiển web, nên thiết lập một mô-đun không bao giờ có nghĩa là phải đợi 30 phút.

Sự cố của Discord không phải lỗi của chúng tôi

Kênh lỗi của đội ngũ chúng tôi đăng mọi thao tác thất bại dưới dạng "Runtime Error", kèm mã tham chiếu duy nhất và đủ thứ. Kể cả những lúc chính Discord trả về lỗi máy chủ. Đó không phải lỗi phía chúng tôi cũng không phải thứ chúng tôi sửa được, vậy mà nó nằm trong kênh trông y hệt một lỗi thật.

Ngày nay nó được ghi nhận như một cảnh báo, và thành viên được nhắc thử lại sau vài giây thay vì được đưa liên kết để gửi báo cáo lỗi. Một kênh lỗi mà một nửa tin nhắn không phải lỗi thì sớm muộn cũng sẽ không còn ai đọc. Rồi bạn bỏ lỡ lỗi thật.

Một cuộc tấn công kéo dài một phút

Một buổi chiều cuối tháng 9, trang chủ của chúng tôi nhận hơn 500.000 yêu cầu một chút chỉ trong một phút, từ nhiều quốc gia cùng lúc. Phần lớn bị chặn trước khi đến được máy chủ của chúng tôi, và một phút sau lưu lượng đã trở lại bình thường.

Chúng tôi thấy nó không phải vì có gì đó sập. Chúng tôi thấy nó vì con số không khớp với phần còn lại của biểu đồ. Đó mới là nhiệm vụ thực sự của giám sát: không phải báo động khi mọi thứ đang bốc cháy, mà là chỉ ra chỗ nào không khớp với bình thường.

Những gì hệ thống giám sát của chúng tôi cố ý không thấy

Các quy tắc ở đây quan trọng ngang với bảng điều khiển số liệu:

• Không có địa chỉ IP của khách truy cập trong nhật ký. Chính sách quyền riêng tư của chúng tôi cam kết điều đó, nên chúng tôi xóa chúng ở hai chỗ: khi nhật ký truy cập được ghi và một lần nữa trước khi nó được lưu trữ.
• Không có ID máy chủ, người dùng hay tin nhắn trong số liệu. Mỗi số liệu chỉ được chia theo các thuộc tính thô (mô-đun, nhóm trạng thái, shard). Điều đó bảo vệ dữ liệu và giữ cho cơ sở dữ liệu số liệu nhỏ gọn.
• Bản ghi phiên hiển thị giao diện của chúng tôi, không phải nội dung của bạn. Chỉ văn bản lấy nguyên văn từ các tệp dịch của chúng tôi mới đọc được. Tên máy chủ, kênh và người dùng, dữ liệu nhập vào và bản xem trước đều bị che. Nếu danh sách văn bản được phép không tải được, mọi thứ đều bị che.
• Mọi thứ trên trang web chỉ sau khi có sự đồng ý. Điều đó cũng khiến các con số ở đó chỉ là giới hạn dưới. Để có số lượt xem trang thật, chúng tôi xem tổng số ẩn danh từ nhà cung cấp mạng của mình.

Chi tiết có trong chính sách quyền riêng tư.

Điều chúng tôi rút ra

Thứ tốn kém hiếm khi là thứ bị hỏng. Không phát hiện nào ở trên gây ra lỗi. Chúng gây ra tải, chi phí và nhiễu, và nếu không đo lường thì bạn sẽ chẳng bao giờ thấy những thứ đó.

Hỏi theo từng máy chủ không mở rộng được. Cả hai phát hiện lớn đều cùng một khuôn mẫu: một vòng lặp qua mọi máy chủ và hỏi riêng từng máy chủ. Câu trả lời gần như luôn là cùng một câu hỏi, hỏi một lần cho tất cả.

Một cảnh báo phải hiếm, nếu không thì nó không còn là cảnh báo. Đó là lý do chỉ Grafana ping đội ngũ, và chỉ cho những thứ cần ai đó can thiệp. Các loại lỗi mới từ PostHog được đưa vào kênh mà không ping.

Nếu bạn tự quản lý một máy chủ Discord và muốn xem các mô-đun được nhắc đến ở đây: bình chọn, lượt hỗ trợ và vắng mặt có trong bảng điều khiển web, và được mô tả trong tài liệu.