Liên kết quan trọng
*Bảng điều khiển Tình trạng dịch vụ hiện chỉ khả dụng cho khách hàng API Enterprise.
Bắt đầu với các mặc định phù hợp
Khi bạn mở bảng điều khiển Tình trạng dịch vụ, mặc định sẽ là:
Tất cả dự án
30 ngày gần nhất
Độ phân giải theo giờ
Chế độ xem này chỉ hữu ích để định hướng. Việc khắc phục sự cố có ý nghĩa luôn cần lọc dữ liệu.
Lọc trước khi điều tra
Lọc đúng là bước quan trọng nhất. Hầu hết các diễn giải sai đều đến từ việc trộn lẫn mô hình, tầng dịch vụ hoặc dự án.
Lọc theo mô hình (mỗi lần một mô hình)
Luôn lọc về một mô hình duy nhất.
Lý do:
Sự cố ở các mô hình có lưu lượng thấp có thể bị che khuất bởi lưu lượng lớn hơn
Các mô hình lưu lượng lớn có thể khiến sự cố cục bộ trông như sự cố toàn cục
Các mô hình khác nhau có mục tiêu hiệu suất khác nhau
Lưu ý: chọn nhiều mô hình sẽ gộp chúng lại — không phải chuyển đổi giữa chúng.
Lọc theo tầng dịch vụ
Nếu bạn dùng nhiều hơn một tầng (standard, priority, scale), hãy luôn lọc theo tầng bạn đang điều tra.
Lý do:
Các tầng có đặc tính hiệu suất khác nhau
Các tầng priority và scale có SLA được xác định
Việc trộn các tầng làm che khuất hiệu suất của tầng trả phí
Điều này đặc biệt quan trọng khi phân tích độ trễ.
Lọc theo dự án
Theo mặc định, Tình trạng dịch vụ hiển thị tất cả dự án.
Để khắc phục sự cố, hãy lọc theo (các) dự án nơi quan sát thấy sự cố.
Lý do:
Một dự án đơn lẻ có lưu lượng lớn có thể chi phối các chỉ số
Các dự án bị ảnh hưởng nhỏ hơn có thể bị che khuất bởi lưu lượng không liên quan
Chỉ để chọn "Tất cả dự án" nếu bạn tin rằng sự cố thực sự ảnh hưởng toàn bộ tổ chức.
Khắc phục sự cố lỗi
Sử dụng chế độ xem Yêu cầu HTTP
Để điều tra lỗi:
Lọc theo mô hình và tầng dịch vụ
Để chuyển từ Uptime sang HTTP Requests, hãy nhấp vào tab HTTP Requests
Chế độ xem này hiển thị tổng số yêu cầu và số lỗi theo mã trạng thái HTTP. Phóng to đến độ phân giải theo phút để xác định các đợt tăng đột biến hoặc thay đổi chi tiết.
Diễn giải tỷ lệ lỗi, không phải số lượng
Một số lỗi là điều được dự kiến trong bất kỳ hệ thống production nào. Hãy tập trung vào tỷ lệ phần trăm lỗi, không phải tổng số thô.
Tổng lưu lượng của bạn càng lớn thì số lỗi tiềm năng càng cao, ngay cả khi tỷ lệ lỗi cực thấp.
Khi lỗi không xuất hiện trong Tình trạng dịch vụ
Nếu bạn thấy lỗi phía máy khách nhưng không có dữ liệu tương ứng trong Tình trạng dịch vụ:
Các yêu cầu có thể đã không đến được OpenAI
Vấn đề thường nằm ở phía thượng nguồn (timeout, proxy, mạng)
Điều này thường gặp với timeout phía máy khách được đặt quá gắt.
Khắc phục sự cố độ trễ
Phân tích độ trễ có ý nghĩa nhất trên các tầng priority và scale, vốn có SLA được xác định. Tầng standard có thể cho thấy biến động độ trễ lớn hơn và không có độ trễ được đảm bảo.
Các chỉ số chính
Để xem từng chỉ số này, hãy nhấp vào tab tương ứng:
Tốc độ token
Số token được tạo ra mỗi giây.
Không phụ thuộc vào kích thước câu lệnh.
Thời gian yêu cầu
Tổng thời lượng yêu cầu.
Bị ảnh hưởng mạnh bởi kích thước đầu ra và suy luận.
Thời gian đến token đầu tiên (TTFT)
Thời gian cho đến khi token đầu tiên được tạo ra.
Bị ảnh hưởng mạnh bởi kích thước câu lệnh đầu vào chưa được lưu đệm và suy luận.
Luôn xem các phân vị P50 / P75 / P95. Giá trị trung bình có thể che giấu tác động thực tế đến người dùng.
6. Liên hệ độ trễ với mức sử dụng token
Tình trạng dịch vụ cho biết hành vi thay đổi khi nào. Dữ liệu mức sử dụng giúp giải thích tại sao.
Trong bảng điều khiển Mức sử dụng, hãy làm như sau để đảm bảo bạn đang xem dữ liệu liên quan đến chế độ xem của mình trong Bảng điều khiển Tình trạng dịch vụ:
Lọc theo cùng dự án, mô hình
Nhóm theo tầng dịch vụ nếu áp dụng
Tập trung vào token đầu ra, vì chúng ảnh hưởng mạnh nhất đến độ trễ
Để phân tích sâu hơn, hãy xuất Dữ liệu hoạt động và kiểm tra số token trên mỗi yêu cầu theo thời gian.
7. Cần chia sẻ gì với bộ phận hỗ trợ (nếu cần)
Nếu bạn liên hệ bộ phận hỗ trợ, hãy bao gồm:
Các Org ID bị ảnh hưởng (điều này quan trọng)
Các điểm cuối bị ảnh hưởng (Chat Completions, Responses, v.v.) (điều này quan trọng)
Các mô hình bị ảnh hưởng (điều này quan trọng)
Đây là trên tầng scale hay priority? (điều này quan trọng)
Khoảng thời gian kèm múi giờ của độ trễ hoặc lỗi (điều này quan trọng)
x-request-id hoặc X-Client-Request-Id liên quan (thường quan trọng; hãy bao gồm nếu có thể)
Dấu thời gian kèm múi giờ (hoặc ít nhất là ngày) của các yêu cầu được cung cấp
Độ trễ - nếu chia sẻ ví dụ về các yêu cầu chậm, hãy cho biết phía bạn mất bao lâu. Lý tưởng nhất là cũng bao gồm dấu thời gian khi yêu cầu được gửi đi và khi được nhận lại.
Lỗi - vui lòng chia sẻ tỷ lệ phần trăm gần đúng của các yêu cầu thất bại/gặp lỗi, (các) mã phản hồi, (các) thông báo lỗi và mất bao lâu để nhận được phản hồi lỗi
ID dự án liên quan đến các yêu cầu
Điều này có ảnh hưởng đến các yêu cầu nơi lưu trú dữ liệu không? Nếu có, là những yêu cầu nào?
Mô tả về các xu hướng bạn đang thấy
Lỗi: % gần đúng của các yêu cầu thất bại/gặp lỗi
Độ trễ: Những phân vị nào bị ảnh hưởng (p50 / p90 / p95 / p99), và chúng cao hơn bao nhiêu so với mức cơ sở của khách hàng
Cả hai: Ảnh chụp màn hình hoặc bảng dữ liệu lỗi hoặc độ trễ (Bạn đã xác định tỷ lệ lỗi hoặc độ trễ cao hơn kỳ vọng như thế nào?)
Các tình huống khắc phục sự cố thường gặp
Xảy ra timeout nhưng Tình trạng dịch vụ trông bình thường
Nguyên nhân có thể: các yêu cầu bị timeout trước khi đến được OpenAI.
Kiểm tra:
Cài đặt timeout của máy khách hoặc proxy
Các thay đổi ở mạng cục bộ hoặc bộ cân bằng tải
Sự hiện diện của lỗi 499 trong bảng điều khiển Tình trạng dịch vụ (chúng có thể hiển thị thành lỗi 5xx trong hệ thống của riêng bạn).
Độ trễ tăng mà không có đợt triển khai
Nguyên nhân có thể: Kích thước token đầu ra hoặc mức sử dụng suy luận tăng và\hoặc lưu lượng đã dịch chuyển giữa các tầng dịch vụ
Kiểm tra:
Số token đầu ra trung bình trên mỗi yêu cầu trong bảng điều khiển Mức sử dụng (yêu cầu tải dữ liệu xuống và chia số token đầu ra cho tổng số yêu cầu).
Các phân vị Request Time và TTFT trong bảng điều khiển Tình trạng dịch vụ.
Tầng Priority hoặc Scale có vẻ chậm
Nguyên nhân có thể: các chỉ số bị trộn lẫn giữa các tầng (nghĩa là lưu lượng tầng standard đang che khuất hiệu suất của tầng trả phí)
Kiểm tra:
Bộ lọc được giới hạn ở một tầng và một mô hình duy nhất
So sánh tốc độ token giữa các tầng
Tăng đột biến lỗi 5XX
Nguyên nhân có thể: các lỗi thoáng qua ảnh hưởng đến một tỷ lệ nhỏ lưu lượng.
Kiểm tra:
Tỷ lệ phần trăm lỗi
Liệu lưu lượng có thay đổi cùng thời điểm hay không
Sự cố chỉ ảnh hưởng đến một dự án
Nguyên nhân có thể: cấu hình hoặc kiểu sử dụng riêng của dự án.
Kiểm tra:
Lọc ở cấp dự án
So sánh với các dự án không bị ảnh hưởng
Kết luận chính
Lọc theo mô hình, tầng và dự án liên quan trước khi diễn giải các chỉ số
Dùng phân vị, không phải giá trị trung bình, để phân tích độ trễ
Tỷ lệ lỗi nhỏ là điều được dự kiến
Thiếu dữ liệu thường cho thấy các vấn đề phía thượng nguồn
Dữ liệu mức sử dụng có thể giúp giải thích tại sao độ trễ thay đổi; Tình trạng dịch vụ giúp cho biết khi nào