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.
Chuyển đến Tài liệu về 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 nhật ký hệ thống hoặc ổ đĩa (chỉ Edge dành cho Đám mây riêng tư). Mọi thông tin quan trọng liên quan đến API yêu cầu như 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.v. có thể được ghi nhật ký để tham khảo sau hoặc để gỡ lỗi. Mặc dù chính sách sử dụng để thực hiện quá trình ghi nhật ký, có một số điều cần lưu ý khi sử dụng chính sách này.

Phản mẫu

Chính sách MessageLogging mang đến một cách hiệu quả để nhận thêm thông tin về Yêu cầu API và gỡ lỗi mọi sự cố 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 Dữ liệu nhật ký của chính sách MessageLogging theo các phân đoạn trong cùng một proxy API trong các luồng không phải là PostClientFlow có thể có tác động bất lợi. Lý do là vì Apigee Edge mở ra 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 này sử dụng TLS qua TCP, thì sẽ phát sinh thêm chi phí khi 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, chính sách MessageLogging có tên "LogRequestInfo" được đặt trong Luồng 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à LogResponseInfo chính sách này 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. Thao tác này sẽ sử dụng tài nguyên hệ thống bổ sung do hai kết nối TLS có thể đang được thiết lập.

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 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ý tin nhắn

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

Tác động

  • Chi phí kết nối mạng gia tăng do thiết lập kết nối tới nhiều máy chủ nhật ký trong luồng Proxy API.
  • Nếu máy chủ nhật ký hệ thống bị chậm hoặc không thể xử lý khối lượng lớn do nhật ký hệ thống nhiều lần cuộc gọi thì sẽ gây áp lực ngược trở lại cho trình xử lý thư, dẫn đến yêu cầu chậm và có thể có độ trễ cao hoặc lỗi Thời gian chờ cổng vào 504.
  • Tăng số lượng chỉ số mô tả tệp đồng thời mà trình xử lý thông báo mở trên Những chế độ thiết lập Đám mây riêng tư có sử dụng tính năng ghi nhật ký tệp.

  • Nếu bạn đặt chính sách MessageLogging trong các luồng khác với luồng PostClient, thì sẽ có khả năng thông tin không được ghi lại, vì chính sách MessageLogging sẽ không sẽ đượ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ụ về ProxyEndpoint trước đây, thông tin sẽ không được ghi lại 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 không thành công.
      hoặc
    • Nếu máy chủ đích gặp lỗi (HTTP 4XX, 5XX). Trong tình huống này, khi một phản hồi thành công không được trả về, chính sách LogResponseInfo sẽ không sẽ đượ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 thông tin liên quan đến lỗi của bạn.

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ả quy trình các biến đã được ghi nhật ký, 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 mà trong đó việc phân phối thông báo được đảm bảo đến máy chủ nhật ký hệ thống không được hỗ trợ là bắt buộc và TLS/SSL không bắt buộc.

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 đó, gọi hàm trong PostClientFlow, vốn nằm ngoài của quá trình xử lý yêu cầu/phản hồi, nghĩa là sẽ luôn ghi nhật ký dữ liệu bất kể API có lỗi hay không.

Dưới đây là ví dụ về việc 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>
 ...

Dưới đâ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ì phản hồi các biến không có sẵn trong PostClientFlow theo Luồng lỗi. Điều này rất quan trọng để đặ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