Cloudflare Traces : tìm nơi một truy vấn bị chậm

Một trang theo dõi đơn hàng mất nhiều thời gian để phản hồi. Ứng dụng của bạn không báo lỗi, nhưng người dùng vẫn phải chờ. Thời gian chậm này có phải do máy chủ, do quyết định lưu cache hay do một bước trung gian không? Cloudflare Traces, được công bố ở phiên bản thử nghiệm vào ngày 2 tháng 10 năm 2026, cho phép xem xét nhiều bước hơn. Để đưa ra chẩn đoán, bạn vẫn phải liên kết các quan sát với lộ trình đúng.

Bắt đầu bằng một yêu cầu mà bạn có thể nhận ra

Hãy lấy một ứng dụng giả tưởng phía sau Cloudflare. Một trình duyệt yêu cầu một trang, yêu cầu đi qua nền tảng rồi đến máy chủ của ứng dụng, được gọi là máy chủ gốc (origin). Máy chủ này có thể truy vấn cơ sở dữ liệu hoặc một dịch vụ bên ngoài trước khi phản hồi. Mỗi lớp chỉ thấy một phần công việc.

Một nhật ký ứng dụng có thể chỉ ra rằng một trang đã được phục vụ mà không giải thích một khoảng thời gian chờ xảy ra trước khi trang đó đến. Ngược lại, một chỉ số mạng không nhất thiết cho thấy thao tác nào của ứng dụng đã mất thời gian. Một dấu vết tập hợp các bước liên quan đến cùng một yêu cầu. Mỗi bước được quan sát, thường được gọi là một span, xác định một thao tác và vị trí của nó trong lộ trình.

Để suy luận, hãy bắt đầu với một yêu cầu tổng hợp mà bạn kiểm soát được nội dung. Ghi chú đường đi đã sử dụng, giờ phát hành và các yếu tố giúp tìm lại nó. Phân tách các quan sát với các giả thuyết: « máy chủ gốc đã nhận yêu cầu » là một quan sát; « cơ sở dữ liệu làm chậm trang » vẫn là một giả thuyết cho đến khi có bằng chứng cho thấy công việc này.

Phiếu chẩn đoán của bạn phải có khả năng chứa các ô trống. Một lớp vắng mặt có thể tương ứng với một phần không được đo đạc hoặc không được bảo tồn. Nó không chứng minh rằng không có thao tác nào đã diễn ra ở đó. Nguyên tắc này vẫn hữu ích ngay cả khi đã có công cụ giám sát được cài đặt: tên của một chế độ xem không bao giờ đảm bảo phạm vi của bằng chứng.

Các thông báo ngày 2 tháng 10, kèm theo trạng thái của chúng

Cloudflare Traces đã được công bố ở phiên bản beta mở vào ngày 2 tháng 10. Nhà phát hành mô tả một lộ trình bao quát các hoạt động được hỗ trợ về bảo mật, chuyển đổi, bộ nhớ đệm, định tuyến, của Workers và xử lý tại máy chủ gốc. Nó thông báo sự lan truyền của bối cảnh W3C traceparent, việc lấy mẫu và xuất dữ liệu tương thích với OTLP, giao thức truyền tải của OpenTelemetry. Phạm vi không nên được mở rộng cho tất cả các sản phẩm theo suy luận. Thông báo Cloudflare Traces.

Cùng ngày đó, Cloudflare đã trình bày tám tiến triển về Khả năng quan sát, bao gồm một không gian chung cho nhật ký, một API SQL thống nhất và các cảnh báo ở phiên bản beta. Các truy vấn chéo giữa nhiều bộ dữ liệu vẫn được thông báo sẽ có sau. Mô hình định giá mới dự kiến từ ngày 1 tháng 12 năm 2026, với áp dụng khi gia hạn cho Enterprise. Thông báo Khả năng quan sát.

Bảng này tóm tắt các trạng thái đã được thông báo, không phải là một kho kiểm tra trên tài khoản Partitech. Nó được dùng để chọn những gì thử nghiệm thí điểm của bạn sẽ phải xác nhận. Hãy tránh xây dựng một quy trình sự cố xung quanh một tính năng vẫn còn trong tương lai.

Kết nối các lớp mà không suy diễn những gì chúng không hiển thị

Ngữ cảnh theo dõi là một thông tin được truyền giữa các dịch vụ để nhận diện một hành trình chung. OpenTelemetry cung cấp một tập hợp các quy ước và công cụ để thực hiện việc theo dõi một ứng dụng, tức là khiến ứng dụng đó mô tả các hoạt động của nó. Một định dạng chung giúp việc đối chiếu trở nên dễ dàng; nó không tự động tạo ra các quan sát còn thiếu bên trong mã của bạn.

Đối với một ứng dụng Symfony hoặc Laravel, trước tiên hãy tìm xem những gì đã được tích hợp sẵn: đầu vào của yêu cầu, truy cập cơ sở dữ liệu, lời gọi bên ngoài, hàng đợi bất đồng bộ. Hãy tạo một sơ đồ đơn giản về các ranh giới: trình duyệt đến nền tảng, nền tảng đến ứng dụng, ứng dụng đến các phụ thuộc. Đối với mỗi điểm chuyển, xác định ai nhận, truyền hoặc làm mới bối cảnh. Đừng thêm một bộ thu thứ hai trước khi hiểu rõ đường đi hiện có.

Một định danh do người gọi cung cấp không phải là một danh tính đã được xác thực. Trong giao thức của chúng tôi, nó không bao giờ được sử dụng để cho phép một hành động hay để chọn hồ sơ của khách hàng. Xác định các ranh giới nơi một ngữ cảnh bên ngoài có thể được sử dụng lại, các định dạng được chấp nhận và các điều kiện mà bạn quay lại với ngữ cảnh nội bộ. Khuyến nghị kiến trúc này cần được điều chỉnh phù hợp với công cụ đo lường thực tế của bạn.

Cũng hãy xem xét các nhánh không đồng bộ. Nếu trang khởi động một công việc sau khi đã phản hồi, thời gian của nó không nên bị nhầm lẫn với thời gian chờ trong trình duyệt. Mối liên hệ giữa hai hoạt động có thể vẫn hữu ích, nhưng cần giải thích những gì bạn đang đo lường. Nếu không phân biệt được điều này, một nhiệm vụ phụ kéo dài có thể trở thành lời giải thích sai về sự chậm của trang.

Chọn dữ liệu trước khi chọn dung lượng

Một bản ghi chi tiết có thể chứa thông tin mà việc chẩn đoán không cần đến. Đối với trang giả tưởng của chúng tôi, giữ lại một đường dẫn chuẩn hóa như "theo dõi đơn hàng" thường hữu ích hơn là giữ nguyên URL đầy đủ với tên cá nhân và các tham số. Tên của thao tác có thể đủ mà không cần nội dung nghiệp vụ của nó.

Viết một danh sách các trường được phép và một danh sách các trường loại trừ: bí mật, cookie, tiêu đề xác thực, nội dung biểu mẫu và thân phản hồi. Kiểm tra những gì được thu thập tự động, những gì được thêm bởi mã của bạn và những gì được gửi đến đích xuất. Việc làm sạch trên màn hình không đảm bảo rằng dữ liệu xuất ra cũng được làm sạch.

Lấy mẫu bao gồm việc giữ lại một phần các yêu cầu. Bạn đang tìm kiếm sự thỏa hiệp giữa các quan sát hữu ích, khối lượng và chi phí. Trong điều kiện bình thường, hãy đặt ra một quy tắc dễ hiểu. Trong quá trình điều tra, bạn có thể đề xuất thu thập tập trung hơn vào một tuyến tổng hợp hoặc lưu lượng thử nghiệm. Cloudflare thông báo chính xác các quy tắc cho phép sửa đổi việc chọn các truy vấn đã theo dõi. Quy tắc Lấy mẫu và Theo dõi.

Một quy tắc tạm thời phải có chủ sở hữu, ngày rút lại và lý do. Nếu không, sự cố sẽ kết thúc, nhưng việc thu thập mở rộng vẫn tiếp tục. Cũng cần xác định ai có thể đọc các bản ghi, chúng được truy cập trong bao lâu và ai có thể kích hoạt xuất dữ liệu. Đây là các lựa chọn vận hành; không có cấp độ tuân thủ nào được suy ra từ việc áp dụng một định dạng kỹ thuật.

Ba lộ trình tổng hợp để so sánh

Đề xuất về việc phân loại của chúng tôi bắt đầu bằng ba truy vấn trên một ứng dụng trình diễn. Truy vấn đầu tiên sử dụng một phản hồi mà bạn đã thiết kế để lấy từ bộ nhớ đệm. Truy vấn thứ hai liên kết trở về máy chủ gốc. Truy vấn thứ ba kích hoạt một thao tác nội bộ được thiết kế khác biệt, ví dụ như một cuộc gọi tới một dịch vụ giả. Bài viết này không cung cấp bất kỳ tài khoản khách hàng nào, không có đơn đặt hàng thực sự và không đo lường độ trễ.

Đối với mỗi lộ trình, hãy kiểm tra rằng hành vi mong đợi thực sự đã xảy ra: đừng gọi một truy vấn là “cache” chỉ vì bạn muốn nó như vậy. Sau đó, hãy tìm lại dấu vết của nó, các bước có thể thấy và các quan sát ứng dụng liên quan. Một lộ trình không tìm thấy phải được giải thích bằng các cài đặt, phạm vi hoặc một cuộc điều tra bổ sung; đừng tự động coi đó là một thành công.

Lặp lại các lộ trình với quy tắc thông thường rồi với quy tắc mục tiêu. Ghi lại khối lượng được tạo ra và tỷ lệ lộ trình được tìm thấy trong các điều kiện thử nghiệm. Kiểm tra một vài bản xuất dữ liệu để xác nhận sự thiếu vắng các trường bị loại trừ. Những bước đo lường này sẽ giúp quyết định; việc chỉ hiển thị một vết truy xuất sẽ không đủ để đánh giá chẩn đoán.

Chuyển từ sơ đồ sang quy trình vận hành

Bước tiếp theo là một bảng hướng dẫn có thể sử dụng trong trường hợp sự cố: nơi tìm kiếm yêu cầu, các lớp cần so sánh và ai có thể tạm thời mở rộng việc thu thập. Hãy để một người chưa chuẩn bị bản thử nghiệm đọc lại. Nếu người đó không thể tìm thấy một yêu cầu thử nghiệm với những hướng dẫn này, hãy cải thiện quy trình trước khi mở rộng phạm vi.

Cũng chuẩn bị tính khả đảo. Hãy biết cách gỡ bỏ một quy tắc, vô hiệu hóa một luồng xuất dữ liệu và giữ lại chỉ những bằng chứng cần thiết cho phân tích. Ước lượng việc lưu trữ và khối lượng dựa trên việc sử dụng quan sát được, sau đó xem lại ước lượng này khi đến gần thời hạn áp dụng mức giá đã công bố. Điều kiện của đề nghị có thể thay đổi trong thời gian thử nghiệm beta.

Lựa chọn có lợi cho Cloudflare Traces dựa trên một mối tương quan đã được chứng minh giữa các lớp hữu ích cho ứng dụng của bạn, một việc thu thập dữ liệu được kiểm soát và một quy trình dễ hiểu. Nếu các hoạt động quyết định vẫn còn vắng mặt, hãy cải thiện công cụ đo lường trước khi hy vọng một chẩn đoán tốt hơn. Công cụ mang lại một phạm vi quan sát mới; nhóm của bạn biến những quan sát này thành bằng chứng có thể sử dụng.

Nguồn và ngày kiểm tra

Nguồn chính mở ngày 6 tháng 10 năm 2026: Cloudflare Khả năng quan sát và Cloudflare Traces, được công bố vào ngày 2 tháng 10. Lộ trình giả tưởng, hồ sơ và các quy tắc được đề xuất tạo thành một phương pháp độc đáo, không có thử nghiệm thực hiện hay lợi ích giải quyết được đo lường.