Sentry đã phát hiện gì: khả năng quan sát, độ ổn định và chi phí theo dõi mã nguồn

Trước đây, các nhóm kỹ thuật hoặc đầu tư quá mức vào khả năng quan sát (cả một đội SRE dựng dashboard mà chẳng ai đọc), hoặc bỏ qua hoàn toàn (chỉ biết dịch vụ ngừng hoạt động khi khách hàng gửi email). Năm 2026, cả hai thái cực đều không thể chấp nhận. Bạn cần biết điều gì đang hỏng, nhưng cũng cần biết mà không phải trả mức giá doanh nghiệp cho một sản phẩm độc lập.

Bài hướng dẫn này trình bày cách tích hợp Sentry giúp chúng tôi phát hiện lỗi sản xuất, những gì chúng tôi đã thay đổi để xử lý và cách cấu hình giám sát nhằm kiểm soát nhiễu cũng như mức sử dụng. Bài viết cũng xem xét sự thay đổi của các công cụ quan sát dành cho nhóm kỹ thuật nhỏ.

Vì sao cảnh báo bỏ sót lỗi trên trình duyệt

Backend của chúng tôi đã kết nối với Sentry từ tháng 3. DSN nằm trong Google Secret Manager, bí mật được gắn vào Cloud Run và sentry_sdk.init chạy mỗi khi khởi động. Email cảnh báo vẫn đến. Nhìn từ bên ngoài, mọi thứ có vẻ ổn.

Nhưng bên trong thì không. Frontend chưa được kết nối với Sentry. Lỗi trình duyệt, lỗi hydration và lỗi tải từng phần đều vô hình. Backend lại gửi lỗi Python vào dự án mang nhãn javascript-nextjs, vì đó là dự án duy nhất trong tổ chức. Stack trace dồn vào sai chỗ, việc gom nhóm vô ích và dashboard trở thành luồng sự kiện trộn nhiều ngôn ngữ.

Khắc phục khoảng trống này đồng nghĩa với việc tách lỗi trình duyệt khỏi lỗi backend trước khi xử lý từng lỗi cụ thể.

Dữ liệu cho thấy điều gì

Chúng tôi lấy các sự kiện lỗi trong 90 ngày gần nhất. Một vài mẫu nổi bật:

Sự cố cũ tự biến mất sau khi được sửa

Lỗi xuất hiện nhiều nhất trong khoảng thời gian này là StringDataRightTruncation của Postgres — 16 sự kiện trong 22 giây — từ endpoint đăng ký qua mạng xã hội. Nguyên nhân là lỗi lệch schema điển hình: định nghĩa model cho phép tiểu sử dài 800 ký tự, nhưng cột trong cơ sở dữ liệu sản xuất vẫn là VARCHAR(500) từ một migration trước đó. Người dùng gửi tiểu sử dài hơn 500 ký tự một chút, lớp Pydantic chấp nhận, rồi lệnh INSERT thất bại.

Migration mở rộng cột lên 800 đã được viết và triển khai vào sáng hôm sau. Nhưng vấn đề gốc — model và schema cơ sở dữ liệu có thể lệch nhau mà không ai nhận ra cho đến khi khách hàng gặp lỗi — vẫn chưa được giải quyết.

Chúng tôi làm hai việc. Thứ nhất, siết chặt schema yêu cầu cho đăng ký mạng xã hội: đặt max_length rõ ràng cho email, tên hiển thị và token để dữ liệu bất thường được trả về dưới dạng 422 thay vì đi tới cơ sở dữ liệu. Thứ hai, mở rộng script kiểm tra tính toàn vẹn DB để so sánh information_schema.columns.character_maximum_length với độ dài mà ứng dụng mong đợi. Giờ đây, nếu một migration sau này thu hẹp cột xuống dưới độ dài dữ liệu mà model có thể tạo ra, lần triển khai tiếp theo sẽ thất bại ở bước kiểm tra tính toàn vẹn.

Một phiên làm việc không thể rollback

Thấp hơn trong danh sách là một chuỗi lỗi: một OperationalError: server closed the connection unexpectedly trên POST /v1/upload, sau đó là hàng loạt PendingRollbackError từ cùng luồng mã. Postgres đã ngắt kết nối giữa truy vấn, phiên SQLAlchemy rơi vào trạng thái không hợp lệ và dịch vụ tải lên cố lưu một phần kết quả trên chính phiên đó. Mọi thao tác tiếp theo trong phiên đều kéo theo lỗi.

Cách sửa nhỏ nhưng dễ làm sai. Khi pipeline tải lên bắt được ngoại lệ, việc đầu tiên nó làm lúc này là db.rollback() — được bọc trong try/except riêng để rollback thất bại không che mất lỗi ban đầu. Sau đó, logic lưu một phần kết quả chạy trên phiên sạch.

Nhật ký tự xóa mất thông tin

Trình xử lý kết thúc WebSocket ghi log err=%s cùng ngoại lệ đã bắt. Với hầu hết ngoại lệ, cách này in ra thông tin hữu ích. Nhưng một số kiểu ngoại lệ có __str__ trả về chuỗi rỗng, khiến log chỉ có err= mà không có gì phía sau. Sự kiện Sentry cho biết thao tác lưu thất bại nhưng không nêu lý do.

Chuyển sang logger.exception(...) và err=%r không tốn gì mà giúp mọi sự kiện sau này tự mô tả đầy đủ hơn.

Nhiễu mà chúng tôi không muốn phải trả phí

Các mục còn lại trong hàng đợi không phải lỗi sản phẩm. Uvloop đôi khi phát sinh RuntimeError: unable to perform operation on <TCPTransport closed=True> khi client ngắt kết nối giữa SSL. Đó là hành vi đúng, không phải điều chúng tôi có thể sửa; với hạn mức miễn phí 5.000 lỗi mỗi tháng, các sự kiện đó làm lãng phí ngân sách. Chúng tôi thêm bộ lọc before_send để loại bỏ các sự kiện khớp với những mẫu ngoại lệ/giá trị cụ thể đó. Frontend cũng áp dụng cách tương tự cho ResizeObserver loop limit exceeded và các nhiễu trình duyệt tương tự.

Điều chỉnh cho gói miễn phí

Gói Developer của Sentry cung cấp miễn phí mỗi tháng 5.000 lỗi, 10.000 đơn vị hiệu năng và 50 lượt replay. Con số đó đủ cho ngân sách lỗi của chúng tôi, nhưng chỉ khi không bật tùy tiện mọi tính năng SDK hỗ trợ.

Các thiết lập của chúng tôi:

• tracesSampleRate: 0 ở cả backend và frontend. Theo dõi phân tán thực sự hữu ích, nhưng với 10K đơn vị hiệu năng mỗi tháng, chúng tôi có thể dùng hết hạn mức chỉ trong một buổi chiều có sự cố. Có thể bật lại với tỷ lệ lấy mẫu thấp khi cần điều tra một vấn đề cụ thể.
• profilesSampleRate: 0 ở backend. Cùng lý do.
• Tắt Session Replay trên frontend. Chúng tôi giữ mã tích hợp nhưng đặt cả hai tỷ lệ lấy mẫu bằng 0. Nếu cần ngữ cảnh replay để gỡ lỗi nghiêm trọng, có thể đặt replaysOnErrorSampleRate thành 0.05 trong một ngày rồi tắt lại.
• Bộ lọc before_send trên cả hai môi trường để loại bỏ các sự kiện mà chúng tôi đã biết là không thể xử lý.

Các thay đổi backend giảm nhiễu từ lỗi có thể xử lý, trong khi cấu hình SDK trình duyệt được chuẩn bị để kích hoạt. Đây là hai cột mốc khác nhau: chỉ có mã và thiết lập lấy mẫu không chứng minh rằng sự kiện trình duyệt đã đến đúng dự án.

Thị trường khả năng quan sát đang thay đổi

Chúng tôi tối ưu cho gói miễn phí vì gói miễn phí của Sentry khá hào phóng so với một dịch vụ lưu trữ, nhưng cũng nên hiểu bức tranh rộng hơn vì bài toán kinh tế ở đây đang thay đổi.

Một số thay đổi trong 12 đến 18 tháng qua:

• Tiêu chuẩn mở giảm công việc chuyển đổi, nhưng không xóa hết. Công cụ hỗ trợ OTLP có thể giảm sự phụ thuộc vào backend giám sát. Truy vấn, dashboard, quy tắc cảnh báo và tính năng SDK riêng của từng nhà cung cấp vẫn cần được lên kế hoạch và kiểm thử khi chuyển đổi.
• Tự lưu trữ làm thay đổi phép tính chi phí. Các lựa chọn như GlitchTip và các hệ thống dùng OTLP làm gốc mở ra hướng giám sát khác. Hãy so sánh lưu trữ, sao lưu, nâng cấp và thời gian kỹ thuật với gói dịch vụ, chứ không chỉ so hóa đơn máy ảo với phí đăng ký.
• Gỡ lỗi có AI hỗ trợ mở rộng quy trình. Seer của Sentry đề xuất nguyên nhân gốc và bản vá, còn tích hợp MCP được cấp quyền có thể đưa ngữ cảnh lỗi vào trợ lý lập trình. Bản sửa được đề xuất vẫn cần tái hiện và kiểm thử hồi quy trước khi phát hành.
• Giới hạn gói cần được chú ý như tính năng. Số lượng lỗi, thời gian lưu giữ, lấy mẫu và quyền truy cập nhóm có thể ảnh hưởng đến hóa đơn. Hãy bắt đầu với các tín hiệu cần thiết và ngân sách sự kiện có đo lường, rồi so sánh các gói theo khối lượng đó.

Ở thời điểm của bản phát hành này, Sentry đáp ứng nhu cầu giám sát lỗi trước mắt của chúng tôi. Dùng các giao diện mở ở nơi có thể giúp nhóm có thêm lựa chọn về sau, nhưng việc chuyển nhà cung cấp vẫn cần kiểm tra định tuyến dự án, cảnh báo, dữ liệu còn lưu và tính năng riêng của nhà cung cấp.

Kiểm tra triển khai hoàn tất thiết lập giám sát

Tại thời điểm của bài viết ngày 17 tháng 5 năm 2026, vẫn còn hai việc triển khai:

1. Tạo một dự án Sentry Python riêng để lỗi backend không còn được ghi dưới javascript-nextjs. DSN sẽ được thay trong cùng mục Secret Manager mà backend đang đọc.
2. Thêm DSN frontend vào thiết lập dự án Vercel để lỗi phía client bắt đầu được gửi đến. Mã đã có sẵn và chỉ khởi tạo khi được bật; hiện chỉ còn thiếu biến môi trường.

Với mọi lần triển khai giám sát, hãy gửi một sự kiện kiểm thử có kiểm soát từ từng môi trường rồi xác nhận dự án, môi trường, cách gom nhóm và ngữ cảnh trước khi xem tích hợp là hoàn tất. Tách dự án và thêm biến môi trường là bước thiết lập, không phải bằng chứng sự kiện đã đến nơi.

Vì sao điều này quan trọng

Khi không nhìn thấy lỗi, bạn sẽ đầu tư quá mức vào mã phòng thủ, hoặc đầu tư quá ít rồi phát hành lỗi. Cả hai đều tốn kém. Khả năng quan sát rẻ và đáng tin cậy giúp một nhóm nhỏ vận hành như nhóm lớn hơn: phát hiện hồi quy trước khi khách hàng nhận ra, sửa mà không phải đoán và dành giờ kỹ thuật để xây dựng tính năng mới.

Bài học hữu ích là phải xác minh cả hai phía: các sửa đổi trong ứng dụng và đường đi của hệ thống giám sát vốn được kỳ vọng sẽ phát hiện lần hồi quy tiếp theo. Gói Developer hiện tại của Sentry, được kiểm tra ngày 13 tháng 10 năm 2026, miễn phí 5.000 lỗi, 5 triệu tracing span và 50 lượt replay mỗi tháng. Tracing được tính bằng span, không phải đơn vị hiệu năng theo cách tính cũ. Hãy kiểm tra giới hạn gói hiện tại trước khi chọn tỷ lệ lấy mẫu: hạn mức lỗi không phải ngân sách cho mọi tín hiệu SDK có thể gửi.