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 các nhà phát triển API Proxy ghi nhật ký thông báo tuỳ chỉnh vào nhật ký hệ thống hoặc ổ đĩa (chỉ áp dụng cho Edge 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, chẳng hạn 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., đề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 bạn cần lưu ý một số điều khi sử dụng chính sách này.

Phản 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 sự cố gặp phải với yêu cầu API này. Tuy nhiên, việc sử dụng cùng một chính sách MessageLogging nhiều lần hoặc việc có nhiều dữ liệu nhật ký của chính sách MessageLogging trong nhiều đoạn trong cùng một proxy API ở những luồng khác với PostClientFlow có thể gây ra những ảnh hưởng xấu. Lý do là Apigee Edge mở kết nối với một máy chủ nhật ký hệ thống bên ngoài cho một chính sách MessageLogging. Nếu chính sách này sử dụng TLS qua TCP, thì việc thiết lập kết nối TLS sẽ phát sinh thêm.

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 vào quy trình Yêu cầu và một chính sách MessageLogging khác có tên "LogResponseInfo" sẽ đượ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 ở chế độ 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. Việc này sẽ tốn thêm tài nguyên hệ thống vì 2 kết nối TLS có thể được thiết lập.

Ngoài ra, có 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ông báo

Trong các cấu hình ví dụ sau về chính sách, 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 nhiều chính sách này được dùng 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ỳ CPU, dẫn đến các vấn đề về hiệu suất trên quy mô lớn.

Chính sách về 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 về 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

  • Mức hao tổn kết nối mạng gia tăng do thiết lập kết nối với máy chủ nhật ký nhiều lần trong luồng Proxy API.
  • Nếu máy chủ 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 ra áp lực ngược trên 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 vào 504.
  • Tăng số lượng chỉ số 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ư có 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 không thể được ghi lại vì chính sách MessageLogging sẽ không được thực thi nếu có bất cứ 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 đó, 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 quy trình yêu cầu không thành công.
      hoặc
    • Nếu máy chủ đích gặp lỗi với bất kỳ lỗi nào (HTTP 4XX, 5XX). Trong trường hợp 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 đượ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.

Phương pháp hay nhất

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

Chính sách MessageLogging được thiết kế để tách biệt khỏi chức năng API thực tế, bao gồm cả chức năng 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à API này sẽ luôn ghi lại dữ liệu bất kể API có thất bại hay không.

Dưới đây là ví dụ về cách gọi Chính sách ghi nhật ký tin nhắn 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) của chính sách sẽ 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 một Luồng lỗi, nên bạn cần phải thiết lập rõ ràng các biến woeid và weather.response* bằng cách sử dụng các chính sách ExtractVariables hoặc JavaScript.

Tài liệu đọc thêm