Bạn đang xem tài liệu về Apigee Edge.
Xem tài liệu
Apigee X.
Chính sách MessageLogging của Apigee Edge cho phép các nhà phát triển API Proxy ghi nhật ký các thông báo tuỳ chỉnh vào nhật ký hệ thống hoặc ổ đĩa (chỉ dành cho Đám mây riêng tư). Mọi thông tin quan trọng liên quan đến yêu cầu API như các thông số đầu vào, tải trọng yêu cầu, mã phản hồi, thông báo lỗi (nếu có), v.v. đều có thể được ghi lại để tham khảo sau này hoặc để gỡ lỗi. Mặc dù chính sách này sử dụng quy trình trong nền để thực hiện việc ghi nhật ký, nhưng có một số điểm cần lưu ý khi sử dụng chính sách này.
Mẫu
Chính sách MessageLogging cung cấp một cách hiệu quả để lấy thêm thông tin về yêu cầu API và gỡ lỗi mọi vấn đề gặp phải với yêu cầu API. Tuy nhiên, việc sử dụng cùng một chính sách MessageLogging nhiều lần hoặc có nhiều chính sách MessageLogging sẽ ghi lại dữ liệu theo từng phần trong cùng một proxy API trong các luồng không phải là PostClientFlow. Điều này có thể gây ra ảnh hưởng tiêu cực. Điều này là do Apigee Edge mở kết nối tới một máy chủ hỗ trợ ghi nhật ký hệ thống bên ngoài cho chính sách MessageLogging. Nếu chính sách sử dụng TLS qua TCP, sẽ phát sinh thêm chi phí thiết lập kết nối TLS.
Hãy giải thích điều này với sự trợ giúp của một Proxy API mẫu.
Proxy API
Trong ví dụ sau, một chính sách MessageLogging có tên "LogRequestInfo" được đặt trong quy trình Yêu cầu, và một chính sách MessageLogging khác có tên "LogResponseInfo" được thêm vào quy trình Phản hồi. Cả hai đều nằm trong ProxyEndpoint PreFlow. Chính sách LogRequestInfo thực thi trong nền ngay khi proxy API nhận được yêu cầu và chính sách LogResponseInfo thực thi sau khi proxy nhận được phản hồi từ máy chủ mục tiêu nhưng trước khi proxy trả về phản hồi cho ứng dụng API. Điều này sẽ tiêu tốn thêm tài nguyên hệ thống vì hai kết nối TLS có thể đang được thiết lập.
Ngoài ra, có một chính sách MessageLogging có tên "LogErrorInfo" chỉ được thực thi nếu xảy ra lỗi trong quá trình thực thi proxy API.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ProxyEndpoint name="default"> ... <FaultRules> <FaultRule name="fault-logging"> <Step> <Name>LogErrorInfo</Name> </Step> </FaultRule> </FaultRules> <PreFlow name="PreFlow"> <Request> <Step> <Name>LogRequestInfo</Name> </Step> </Request> </PreFlow> <PreFlow name="PreFlow"> <Response> <Step> <Name>LogResponseInfo</Name> </Step> </Response> </PreFlow> ... </ProxyEndpoint>
Chính sách ghi nhật ký thư
Trong các cấu hình chính sách mẫu sau đây, dữ liệu đang được ghi vào máy chủ nhật ký của bên thứ ba bằng TLS qua TCP. Nếu có nhiều chính sách trong số này được sử dụng trong cùng một proxy API, thì việc thiết lập và quản lý các kết nối TLS sẽ làm tiêu tốn thêm bộ nhớ hệ thống và chu kỳ CPU, dẫn đến các vấn đề về hiệu suất trên quy mô lớn.
Chính sách LogRequestInfo
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <MessageLogging name="LogRequestInfo"> <Syslog> <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {request.queryparam.w}.</Message> <Host>logs-01.loggly.com</Host> <Port>6514</Port> <Protocol>TCP</Protocol> <FormatMessage>true</FormatMessage> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </Syslog> <logLevel>INFO</logLevel> </MessageLogging>
Chính sách LogResponseInfo
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <MessageLogging name="LogResponseInfo"> <Syslog> <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Status: {response.status.code}, Response {response.content}.</Message> <Host>logs-01.loggly.com</Host> <Port>6514</Port> <Protocol>TCP</Protocol> <FormatMessage>true</FormatMessage> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </Syslog> <logLevel>INFO</logLevel> </MessageLogging>
Chính sách LogErrorInfo
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <MessageLogging name="LogErrorInfo"> <Syslog> <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Fault name: {fault.name}.</Message> <Host>logs-01.loggly.com</Host> <Port>6514</Port> <Protocol>TCP</Protocol> <FormatMessage>true</FormatMessage> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </Syslog> <logLevel>ERROR</logLevel> </MessageLogging>
Mức độ tác động
- Tăng chi phí kết nối mạng do thiết lập kết nối tới máy chủ nhật ký nhiều lần trong quy trình API Proxy.
- Nếu máy chủ hỗ trợ ghi nhật ký hệ thống chậm hoặc không thể xử lý khối lượng lớn do nhiều lệnh gọi nhật ký hệ thống gây ra, thì máy chủ sẽ gây áp lực ngược cho bộ xử lý thông báo, dẫn đến việc xử lý yêu cầu chậm và có thể có độ trễ cao hoặc lỗi Thời gian chờ cổng 504.
- Tăng số lượng chỉ số mô tả tệp đồng thời do trình xử lý tin nhắn mở trên các thiết lập Cloud Private nơi sử dụng tính năng ghi nhật ký tệp.
Nếu chính sách MessageLogging được đặt trong các luồng khác với luồng PostClient, thì có khả năng thông tin đó sẽ không được ghi lại, vì chính sách MessageLogging sẽ không được thực thi nếu xảy ra lỗi trước khi thực thi chính sách này.
Trong ví dụ về ProxyEndpoint trước đó, thông tin đó sẽ không được ghi trong các trường hợp sau:
- Nếu có bất kỳ chính sách nào được đặt trước chính sách LogRequestInfo trong luồng yêu cầu sẽ không thành công.
hoặc - Nếu máy chủ đích gặp lỗi (HTTP 4XX, 5XX). Trong trường hợp này, khi không trả về phản hồi thành công, chính sách LogResponseInfo sẽ không được thực thi.
Trong cả hai trường hợp, chính sách LogErrorInfo sẽ được thực thi và chỉ ghi lại những thông tin liên quan đến lỗi.
- Nếu có bất kỳ chính sách nào được đặt trước chính sách LogRequestInfo trong luồng yêu cầu sẽ không thành công.
Phương pháp hay nhất
- Sử dụng chính sách ExtractVariables hoặc chính sách JavaScript để thiết lập tất cả các biến flow sẽ được ghi lại, qua đó cung cấp các biến đó cho chính sách MessageLogging.
- Sử dụng một chính sách MessageLogging duy nhất để ghi nhật ký tất cả dữ liệu cần thiết trong PostClientFlow, được thực thi vô điều kiện.
- Sử dụng giao thức UDP, trong đó bạn không bắt buộc phải gửi thư tới máy chủ syslog và TLS/SSL là không bắt buộc.
Chính sách MessageLogging được thiết kế để tách khỏi chức năng API thực tế, bao gồm cả hoạt động xử lý lỗi. Do đó, việc gọi API này trong PostClientFlow, nằm ngoài phạm vi xử lý yêu cầu/phản hồi, có nghĩa là sẽ luôn ghi lại dữ liệu bất kể API có bị lỗi hay không.
Dưới đây là ví dụ về việc gọi Chính sách ghi nhật ký thông báo trong PostClientFlow:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> ... <PostClientFlow> <Request/> <Response> <Step> <Name>LogInfo</Name> </Step> </Response> </PostClientFlow> ...
Dưới đây là ví dụ về chính sách LogLogging, LogInfo, ghi lại tất cả dữ liệu:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <MessageLogging name="LogInfo"> <Syslog> <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {woeid} Status: {weather.response.code}, Response {weather.response}, Fault: {fault.name:None}.</Message> <Host>logs-01.loggly.com</Host> <Port>6514</Port> <Protocol>TCP</Protocol> <FormatMessage>true</FormatMessage> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </Syslog> <logLevel>INFO</logLevel> </MessageLogging>
Vì biến phản hồi không có trong PostClientFlow sau một Luồng lỗi, nên bạn cần phải đặt rõ ràng các biến woeid
và weather.response*
bằng cách sử dụng chính sách ExtractVariables hoặc JavaScript.
Tài liệu đọc thêm
- Chính sách JavaScript
- Chính sách ExtractVariables
- Việc thực thi mã sau khi xử lý proxy, bao gồm cả thời điểm xảy ra lỗi với PostClientFlow