Cấu hình ghi log Cloudflare AI Gateway nên bắt đầu từ bằng chứng đội ngũ cần và nội dung cần tránh giữ lại. Bảng điều khiển có thể làm yêu cầu dễ quan sát, đồng thời tạo thêm kho lời nhắc, phản hồi và siêu dữ liệu. Thiết lập đúng phụ thuộc cả vào mục đích vận hành lẫn hợp đồng ghi log hiện tại của tài khoản.
Xác lập gateway dùng cơ chế Workers Logs hiện hành hay Legacy Logs, rồi chủ động cấu hình thu thập và lưu nội dung. Thử đường yêu cầu thực tế bằng dấu hiệu giả lập và kiểm tra bản ghi tạo ra. Giữ siêu dữ liệu vận hành hữu ích ở nơi phù hợp, nhưng đừng cho rằng tắt lưu nội dung sẽ xóa dữ liệu khỏi mọi hệ thống khác.
Hãy hình dung trợ lý hỗ trợ có lời nhắc chứa thư từ khách hàng. Kỹ sư cần chẩn đoán lỗi nhà cung cấp và quy việc sử dụng về đúng nguồn. Họ không nhất thiết cần sao chép toàn bộ thư từ vào kho chẩn đoán chung. Đây là vấn đề cấu hình và bằng chứng, không phải lý do từ bỏ khả năng quan sát.
Hướng dẫn này tập trung vào thiết lập vận hành được đề xuất. Nó không cung cấp chứng nhận tuân thủ pháp luật hoặc mặc định mọi tài khoản có cùng cơ chế giá, lưu giữ và xuất dữ liệu.
Cấu hình ghi log Cloudflare AI Gateway phụ thuộc điều kiện tài khoản
Tài liệu ghi log AI Gateway hiện tại phân biệt khách hàng theo thời điểm tạo gateway đầu tiên. Khách hàng tạo gateway đầu tiên vào hoặc sau ngày 24 tháng 9 năm 2026 tuân theo giá và thời gian lưu giữ Workers Logs; khách hàng trước đó dùng Legacy Logs. Kiểm chứng điều kiện đó cho tài khoản bạn đang cấu hình.
Đừng lấy thời gian lưu giữ hoặc hạn mức log từ bài cũ rồi áp dụng cho mọi bản triển khai. Ghi cơ chế dịch vụ áp dụng, thiết lập đã chọn và ngày kiểm tra. Kiểm tra lại khi tài khoản hoặc kiến trúc ghi log thay đổi.
Cùng tài liệu đó tách thu thập toàn bộ bản ghi log khỏi lưu nội dung yêu cầu và phản hồi. Phân biệt này cho phép thảo luận chính xác hơn việc chỉ hỏi ghi log đang bật hay tắt.
| Quyết định | Câu hỏi cần giải quyết |
|---|---|
| Cơ chế ghi log | Hợp đồng hiện tại hay cũ nào áp dụng cho tài khoản? |
| Thu thập toàn bản ghi | Có nên tồn tại bản ghi chẩn đoán cho lớp yêu cầu này? |
| Lưu nội dung | Có cần giữ nội dung lời nhắc và phản hồi không? |
| Truy cập | Ai được kiểm tra hoặc xuất bản ghi? |
| Lưu giữ | Khi nào bản chính và bản xuất hết hạn? |
Xác định câu hỏi sự cố trước
Ghi rõ câu hỏi người vận hành phải trả lời. Khối lượng công việc nào thất bại? Đã dùng nhà cung cấp và đường mô hình nào? Ứng dụng có thử lại không? Có phản hồi trước khi người dùng ngừng chờ không? Tác vụ đích còn chưa được giải quyết không?
Nhiều câu hỏi trong số đó có thể trả lời bằng siêu dữ liệu có giới hạn và mã tham chiếu thao tác của ứng dụng. Chúng không luôn cần toàn bộ lời nhắc. Ngược lại, điều tra chất lượng nội dung có thể cần mẫu được kiểm soát rõ ràng mà siêu dữ liệu yêu cầu chung không giải thích được.
Tách các trường hợp sử dụng này. Chẩn đoán thường lệ của ứng dụng hỗ trợ có thể theo một chính sách thu thập, trong khi điều tra được chấp thuận dùng quy trình bằng chứng khác đã xem xét. Đừng giữ mãi văn bản của mọi khách hàng chỉ vì một ngày nào đó có thể hữu ích để tái hiện lỗi.
Hướng dẫn AI Gateway hiện có của chúng tôi trình bày vai trò proxy và kiểm soát chi phí rộng hơn. Công việc cấu hình ở đây nhằm xác lập bằng chứng nào thực sự tồn tại và chứng minh hành vi thu thập đã chọn.
Cấu hình riêng kiểm soát toàn bản ghi và nội dung
Cloudflare mô tả cf-aig-collect-log cho thu thập toàn bản ghi và cf-aig-collect-log-payload cho lưu nội dung yêu cầu và phản hồi. Đặt kiểm soát nội dung thành false có thể giữ siêu dữ liệu mà không lưu phần thân thô; tắt toàn bản ghi sẽ loại bỏ bản ghi, gồm cả siêu dữ liệu. Đọc ngữ nghĩa header hiện tại trước khi áp dụng.
Dưới đây là chính sách header minh họa, không phải yêu cầu hoàn chỉnh hay bằng chứng kết quả đã triển khai:
1cf-aig-collect-log-payload: false
Áp dụng chính sách trong thành phần ứng dụng đáng tin cậy. Người gọi không đáng tin không được thay đổi chính sách bằng chứng của tổ chức bằng cách chèn header kiểm soát gateway tùy ý. Quyết định header nào được máy chủ chuyển tiếp, đặt hoặc loại bỏ.
Đừng suy ra mặc định từ một yêu cầu thành công. Kiểm chứng riêng thiết lập cấp gateway và đường ghi đè theo từng yêu cầu. Cấu hình hoạt động cho đường mô hình chính vẫn có thể khác qua phương án dự phòng hoặc máy khách khác.
Lưu hồ sơ chính sách có hiệu lực
Gắn phiên bản cho cấu hình phía ứng dụng và ghi các thiết lập gateway liên quan. Mô tả lớp yêu cầu nào giữ nội dung, lớp nào chỉ giữ siêu dữ liệu và lớp nào bị tắt thu thập.
Khi nhà phát triển thêm tích hợp mô hình khác, quá trình xem xét cần bao gồm đường ghi log của nó. Nếu không, ứng dụng có thể tích lũy nhiều đường có hành vi lưu giữ khác nhau trong khi đội ngũ tưởng chỉ có một chính sách toàn cục.
Dùng siêu dữ liệu không trở thành nội dung sao chép khác
Mã tham chiếu tác vụ và yêu cầu không mang nội dung có thể nối bằng chứng gateway với bản ghi riêng của ứng dụng. Mã vụ hỗ trợ có thể đủ để tìm nguồn theo mô hình truy cập hiện có. Chép tiêu đề thư hoặc email khách hàng vào trường siêu dữ liệu có thể làm mất mục đích loại phần thân lời nhắc.
Xác định lược đồ siêu dữ liệu được phép. Kiểm tra giá trị bên cạnh tên trường. Trường tên label vẫn có thể chứa nội dung cá nhân hoặc bí mật nếu ứng dụng điền văn bản người dùng vào đó.
| Lựa chọn siêu dữ liệu | Công dụng vận hành | Điểm cần xem xét |
|---|---|---|
| Mã khối lượng công việc không mang nội dung | Quy việc sử dụng về tính năng ứng dụng | Tránh nhúng nội dung khách hàng |
| Tham chiếu thao tác | Nối sự cố với trạng thái tác vụ | Truy cập bản ghi liên kết vẫn được kiểm soát |
| Phiên bản cấu hình | Tái hiện đường thực tế | Giữ bí mật ngoài giá trị |
| Loại lỗi | Nhóm vấn đề có thể xử lý | Tránh nội dung ngoại lệ thô có dữ liệu nguồn |
Giữ tham chiếu ứng dụng và gateway đủ nhất quán cho điều tra. Người vận hành phải truy vết được lỗi mà không chép toàn bộ lời nhắc giữa các công cụ hoặc cấp cho mọi kỹ sư quyền vào hệ thống khách hàng.
Kiểm chứng thu thập bằng dấu hiệu giả lập
Gửi yêu cầu thử không nhạy cảm chứa dấu hiệu riêng biệt. Kiểm tra đích ghi log áp dụng và xác nhận dấu hiệu có xuất hiện trong kho nội dung, siêu dữ liệu, bản xuất hoặc log ứng dụng liên quan theo chính sách dự định hay không.
Thử phản hồi bình thường, lỗi phía nhà cung cấp và đường dự phòng nếu ứng dụng sử dụng. Xử lý lỗi là nơi phần thân yêu cầu thường bị chép vào trường chẩn đoán ngoài đường thu thập bình thường.
| Phép thử | Bằng chứng dự kiến theo chính sách chỉ siêu dữ liệu |
|---|---|
| Suy luận bình thường | Siêu dữ liệu yêu cầu hữu ích không có dấu hiệu phần thân giả lập |
| Lỗi nhà cung cấp | Loại lỗi và mã tương quan không có nội dung sao chép |
| Ứng dụng thử lại | Liên hệ được các lần thử mà không chép nội dung vào nhãn |
| Yêu cầu gateway trái phép | Từ chối theo chính sách truy cập gateway |
| Xuất hoặc đích log phía sau | Chính sách nội dung và lưu giữ đã thống nhất vẫn giữ nguyên |
Tài liệu gateway có xác thực của Cloudflare là tham chiếu cho kiểm soát truy cập đó. Kiểm tra thông tin xác thực và đường thực tế trong triển khai, thay vì cho rằng thiết lập ghi log cũng bảo vệ điểm cuối.
Đưa bản xuất và các kho khác vào xem xét
Chặn lưu nội dung gateway không chứng minh ứng dụng, nhà cung cấp mô hình hay dịch vụ quan sát bên ngoài không giữ gì. Vẽ đường dữ liệu thực tế và xem từng kho theo hợp đồng riêng.
Nếu xuất log, ghi ai có thể đọc đích và khi nào các bản sao hết hạn. Xóa bản ghi ở một dịch vụ không chứng minh bản xuất trước đó đã bị xóa. Hướng dẫn vận hành cần nêu hệ thống nào sở hữu bằng chứng nào.
Cũng xem xét dấu vết, công cụ theo dõi ngoại lệ và ảnh chụp hỗ trợ. Đội ngũ có thể cấu hình gateway đúng nhưng vẫn dán lời nhắc khách hàng vào phiếu mà nhóm rộng hơn xem được.
Dùng trường hợp giả lập cho kiểm thử hồi quy thường lệ. Khi cần nội dung thật để điều tra lỗi, thiết lập mục đích thu thập cụ thể và truy cập có kiểm soát, thay vì đổi chính sách chung mà không lưu hồ sơ.
Dự trù bằng chứng hữu ích và việc duy trì
Chi phí triển khai gồm xem xét đường dữ liệu, kết nối chính sách yêu cầu, lược đồ siêu dữ liệu, thiết lập truy cập và kiểm chứng. Chi phí định kỳ phụ thuộc cơ chế ghi log áp dụng, khối lượng và kho phía sau, nên kiểm tra giá tài khoản hiện tại trước khi ước tính.
Yêu cầu đề xuất bằng GBP xác định cơ chế gateway và các phép thử bàn giao. Tác vụ chỉ cấu hình khác với xây lại ghi log ứng dụng trên nhiều đường mô hình và đích xuất.
Bàn giao cần có chính sách thực tế, người chịu trách nhiệm, kết quả thử giả lập và quy trình điều tra bằng chứng thiếu. Bao gồm thay đổi cấu hình buộc kiểm chứng lại, nhất là máy khách, đường hoặc đích log mới.
Chúng tôi có thể xem xét ranh giới này trong thử nghiệm thí điểm tích hợp AI có phạm vi . Yêu cầu đánh giá ghi log gateway kèm điều kiện tài khoản, đường mô hình, đích hiện tại và câu hỏi sự cố. Nhờ vậy, khả năng quan sát hữu ích mà không thu nội dung chỉ vì mặc định cho phép.
Câu hỏi thường gặp
Mọi tài khoản AI Gateway dùng cùng cơ chế ghi log sao? Không. Tài liệu hiện tại phân biệt khách hàng tạo gateway đầu tiên vào hoặc sau ngày 24 tháng 9 năm 2026 với khách hàng trước đó. Kiểm chứng Workers Logs hay Legacy Logs áp dụng trước khi dựa vào giả định giá hoặc lưu giữ.
Có thể giữ siêu dữ liệu mà không giữ phần thân lời nhắc và phản hồi không? Kiểm soát thu thập nội dung được mô tả hỗ trợ bản ghi chỉ siêu dữ liệu khi cấu hình phù hợp. Kiểm chứng chính sách có hiệu lực ở gateway và theo yêu cầu, rồi kiểm tra kết quả thử tại đích log thực tế.
Hai header thu thập khác nhau thế nào? Kiểm soát toàn bản ghi quyết định có thu bản ghi log không. Kiểm soát nội dung quyết định lưu phần thân yêu cầu và phản hồi thô trong khi siêu dữ liệu có thể còn. Tắt toàn bản ghi cũng bỏ siêu dữ liệu của nó, nên chọn theo bằng chứng bạn cần.
Chặn lưu nội dung có nghĩa không dịch vụ nào giữ dữ liệu của chúng tôi không? Không. Log ứng dụng khác, nhà cung cấp, bản xuất và công cụ quan sát có hành vi cùng hợp đồng riêng. Xem xét toàn đường dữ liệu thay vì coi một thiết lập gateway là bảo đảm lưu giữ toàn cục.
Thử ghi log mà không dùng dữ liệu khách hàng bằng cách nào? Dùng dấu hiệu giả lập trong yêu cầu không nhạy cảm và kiểm tra bản ghi cùng bản xuất liên quan. Bao gồm kết quả bình thường, lỗi, thử lại và đường dự phòng. Xác nhận siêu dữ liệu không gián tiếp chứa dấu hiệu.
Có nên cho máy khách chọn chính sách ghi log không? Chỉ khi quyền đó là có chủ đích. Áp dụng chính sách tổ chức trong thành phần máy chủ đáng tin cậy và xác định header kiểm soát nào được nhận hoặc ghi đè. Người gọi thông thường không được âm thầm thay đổi chính sách bằng chứng.
Đánh giá cần bàn giao những gì? Nó cần xác định hợp đồng áp dụng, kho dữ liệu, chính sách thu thập thực tế, người quản lý truy cập và quyết định lưu giữ. Bao gồm kết quả kiểm chứng giả lập và quy trình lặp lại được để kiểm tra đường mô hình hoặc đích log mới.