Phản mẫu: Gọi chính sách MessageLogging nhiều lần trong một proxy API

Bạn đang xem tài liệu về Apigee Edge.
Truy cập vào tài liệu Apigee X. thông tin

Chính sách MessageLogging của Apigee Edge cho phép nhà phát triển API Proxy ghi nhật ký các thông báo tuỳ chỉnh vào syslog hoặc vào ổ đĩa (chỉ Edge cho Đám mây riêng tư). Mọi thông tin quan trọng liên quan đến yêu cầu API, chẳng hạn như các tham 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 một quy trình 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.

Antipattern

Chính sách MessageLogging cung cấp một cách hiệu quả để biết 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 ghi dữ liệu theo khối trong cùng một API proxy trong các luồng khác với PostClientFlow có thể gây ra những tác động tiêu cực. Điều này là do Apigee Edge mở một kết nối đến máy chủ syslog bên ngoài cho chính sách MessageLogging. Nếu chính sách sử dụng TLS qua TCP, thì sẽ có thêm chi phí thiết lập một kết nối TLS.

Hãy giải thích điều này bằng cách sử dụng một ví dụ về Proxy API.

API proxy

Trong ví dụ sau, một chính sách MessageLogging có tên là "LogRequestInfo" được đặt trong luồng Yêu cầu và một chính sách MessageLogging khác có tên là "LogResponseInfo" được thêm vào luồng Phản hồi. Cả hai đều nằm trong PreFlow của ProxyEndpoint. Chính sách LogRequestInfo sẽ thực thi ở chế độ nền ngay khi proxy API nhận được yêu cầu và chính sách LogResponseInfo sẽ thực thi sau khi proxy nhận được phản hồi từ máy chủ đích 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ì có thể thiết lập hai kết nối TLS.

Ngoài ra, còn có một chính sách MessageLogging có tên là "LogErrorInfo" chỉ được thực thi nếu có 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 về việc ghi nhật ký tin nhắn

Trong các cấu hình chính sách ví dụ sau đây, dữ liệu đang được ghi vào các máy chủ nhật ký của bên thứ ba bằng TLS qua TCP. Nếu bạn dùng nhiều chính sách trong số này trong cùng một proxy API, thì chi phí thiết lập và quản lý các kết nối TLS sẽ chiếm thêm bộ nhớ hệ thống và chu kỳ CPU, dẫn đến các vấn đề về hiệu suất ở 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>

Tác động

  • Tăng chi phí mạng do thiết lập kết nối với máy chủ nhật ký nhiều lần trong quy trình API Proxy.
  • Nếu máy chủ syslog hoạt động chậm hoặc không xử lý được khối lượng lớn do nhiều lệnh gọi syslog gây ra, thì điều này sẽ gây ra áp lực ngược lên trình xử lý thông báo, dẫn đến quá trình xử lý yêu cầu diễn ra chậm và có thể gây ra độ trễ cao hoặc lỗi 504 Gateway Timeout.
  • Tăng số lượng bộ mô tả tệp đồng thời do trình xử lý thông báo mở trên các chế độ thiết lập Đám mây riêng tư 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ó thể thông tin sẽ không được ghi nhật ký, vì chính sách MessageLogging sẽ không được thực thi nếu có bất kỳ lỗi nào xảy ra trước khi thực thi chính sách này.

    Trong ví dụ ProxyEndpoint trước đó, thông tin sẽ không được ghi lại trong các trường hợp sau:

    • Nếu có chính sách nào được đặt trước chính sách LogRequestInfo trong luồng yêu cầu 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 có phản hồi thành công nào được trả về, 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 thông tin liên quan đến lỗi.

Phương pháp hay nhất

  • Sử dụng chính sách ExtractVariables hoặc chính sách JavaScript để đặt tất cả các biến luồng cần được ghi nhật ký, giúp các biến này có sẵ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 bắt buộc trong PostClientFlow, được thực thi vô điều kiện.
  • Sử dụng giao thức UDP, trong đó không bắt buộc phải đảm bảo việc gửi thư đến máy chủ syslog và không bắt buộc phải sử dụng TLS/SSL.

Chính sách MessageLogging được thiết kế để tách biệt với chức năng API thực tế, bao gồm cả việc xử lý lỗi. Do đó, việc gọi phương thức này trong PostClientFlow (nằm ngoài quá trình xử lý yêu cầu/phản hồi) có nghĩa là phương thức này sẽ luôn ghi nhật ký dữ liệu, bất kể API có thất bại hay không.

Sau đây là ví dụ về cách gọi Chính sách MessageLogging trong PostClientFlow:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 ...
<PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>LogInfo</Name>
            </Step>
        </Response>
</PostClientFlow>
 ...

Sau đây là ví dụ về chính sách MessageLogging, 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ì các biến phản hồi không có trong PostClientFlow sau Error Flow, nên bạn cần đặ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