Antipola: Memanggil kebijakan MessageLogging beberapa kali dalam proxy API

Anda sedang melihat dokumentasi Apigee Edge.
Buka Dokumentasi Apigee X. info

Kebijakan MessageLogging Apigee Edge memungkinkan developer Proxy API mencatat pesan kustom ke syslog atau ke disk (khusus Edge untuk Private Cloud). Informasi penting apa pun yang terkait dengan API seperti parameter input, payload permintaan, kode respons, pesan error (jika ada), dan seterusnya, dapat dicatat untuk referensi di lain waktu atau untuk {i>debugging<i}. Meskipun kebijakan tersebut menggunakan latar belakang untuk melakukan {i>logging<i}, ada syarat untuk menggunakan kebijakan tersebut.

Anti-pola

Kebijakan MessageLogging menyediakan cara yang efisien untuk mendapatkan informasi lebih lanjut tentang permintaan API dan proses debug setiap masalah yang ditemukan dengan permintaan API. Namun, menggunakan kebijakan MessageLogging yang sama lebih dari sekali atau memiliki beberapa Kebijakan MessageLogging mencatat data dalam potongan-potongan di proxy API yang sama dalam alur selain PostClientFlow mungkin memiliki implikasi yang merugikan. Hal ini karena Apigee Edge membuka koneksi ke server syslog eksternal untuk kebijakan {i>MessageLogging<i}. Jika kebijakan ini menggunakan TLS melalui TCP, terdapat overhead tambahan saat membuat koneksi TLS.

Mari kita jelaskan hal ini dengan bantuan Proxy API contoh.

Proxy API

Pada contoh berikut, kebijakan MessageLogging bernama "LogRequestInfo" ditempatkan dalam Alur permintaan, dan kebijakan MessageLogging lainnya bernama "LogResponseInfo" ditambahkan ke Alur respons. Keduanya berada di ProxyEndpoint PreFlow. Kebijakan LogRequestInfo dijalankan di latar belakang segera setelah proxy API menerima permintaan, dan LogResponseInfo kebijakan dijalankan setelah proxy menerima respons dari server target tetapi sebelum proxy menampilkan respons ke klien API. Ini akan memakai sumber daya sistem tambahan karena dua koneksi TLS berpotensi sedang dibuat.

Selain itu, ada kebijakan MessageLogging bernama "LogErrorInfo" yang hanya dieksekusi jika terjadi error saat eksekusi 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>

Kebijakan Logging Pesan

Pada contoh konfigurasi kebijakan berikut, data dicatat ke dalam log server log menggunakan TLS melalui TCP. Jika lebih dari satu kebijakan ini digunakan di proxy API yang sama, biaya pembuatan dan pengelolaan koneksi TLS akan menghabiskan memori sistem dan siklus CPU, yang menyebabkan masalah kinerja dalam skala besar.

Kebijakan 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>

Kebijakan 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>

Kebijakan 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>

Dampak

  • Peningkatan {i>overhead<i} jaringan karena membuat koneksi ke beberapa server log selama alur Proxy API.
  • Jika server syslog lambat atau tidak dapat menangani volume tinggi yang disebabkan oleh beberapa syslog maka akan menyebabkan tekanan balik pada pemroses pesan, yang mengakibatkan permintaan lambat latensi tinggi atau error 504 Gateway Timeout.
  • Peningkatan jumlah deskriptor file serentak yang dibuka oleh pemroses pesan di Penyiapan Private Cloud yang menggunakan logging file.

  • Jika kebijakan MessageLogging ditempatkan di alur selain alur PostClient, ada kemungkinan bahwa informasi mungkin tidak dicatat, karena kebijakan {i>MessageLogging<i} tidak dijalankan jika terjadi kegagalan sebelum kebijakan ini dijalankan.

    Pada contoh ProxyEndpoint sebelumnya, informasi tersebut akan tidak dicatat dalam keadaan berikut:

    • Jika ada kebijakan yang ditempatkan sebelum kebijakan LogRequestInfo di alur permintaan gagal.
      atau
    • Jika server target gagal disertai error (HTTP 4XX, 5XX). Dalam situasi ini, ketika respons yang berhasil tidak ditampilkan, kebijakan LogResponseInfo tidak akan dieksekusi.

    Dalam kedua kasus tersebut, kebijakan LogErrorInfo akan dieksekusi dan hanya mencatat log yang terkait tidak akurat atau tidak sesuai.

Praktik terbaik

  • Gunakan kebijakan ExtractVariables atau kebijakan JavaScript untuk menetapkan semua alur variabel yang dicatat, membuatnya tersedia untuk kebijakan {i>MessageLogging<i}.
  • Gunakan satu kebijakan MessageLogging untuk mencatat semua data yang diperlukan di PostClientFlow, yang dieksekusi tanpa syarat.
  • Gunakan protokol UDP, yang tidak menjamin pengiriman pesan ke server syslog wajib dan TLS/SSL tidak wajib.

Kebijakan {i>MessageLogging<i} dirancang untuk dipisahkan dari fungsi API sebenarnya, termasuk penanganan {i>error<i}. Oleh karena itu, panggil metode tersebut di PostClientFlow, yang berada di luar pemrosesan permintaan/respons, berarti proses ini akan selalu mencatat data, membuat API gagal atau tidak.

Berikut adalah contoh pemanggilan Kebijakan MessageLogging di PostClientFlow:

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

Berikut adalah contoh kebijakan MessageLogging, LogInfo, yang mencatat semua data ke dalam log:

<?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>

Karena respons variabel tidak tersedia di PostClientFlow setelah Terjadi Error. Hal ini penting untuk menetapkan variabel woeid dan weather.response* secara eksplisit menggunakan ExtractVariables atau kebijakan JavaScript.

Bacaan lebih lanjut