Antipola: Memanggil kebijakan MessageLogging beberapa kali dalam proxy API

Anda sedang melihat dokumentasi Apigee dan Apigee hybrid.
Lihat Dokumentasi Apigee Edge.

Kebijakan MessageLogging Apigee memungkinkan developer Proxy API mencatat pesan kustom ke Cloud logging atau endpoint syslog. 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 membuka koneksi ke endpoint eksternal untuk kebijakan MessageLogging. Jika kebijakan menggunakan TLS melalui TCP, seperti halnya endpoint syslog, ada overhead tambahan pembuatan 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 yang 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. Serupa efek negatif terjadi jika menggunakan MessageLogging untuk melakukan log ke endpoint Cloud Logging.

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 overhead jaringan karena membuat koneksi ke beberapa endpoint 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.

  • 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

  • Dalam alur proxy, gunakan satu atau beberapa instance kebijakan ExtractVariables atau kebijakan JavaScript untuk menetapkan semua alur variabel yang perlu dicatat ke dalam variabel konteks; ini akan menyediakannya untuk kebijakan {i> MessageLogging<i} yang dijalankan nanti.
  • Gunakan satu kebijakan MessageLogging untuk mencatat semua data yang diperlukan di PostClientFlow, yang dieksekusi tanpa syarat.
  • Jika Anda menggunakan syslog, gunakan protokol UDP jika pengiriman pesan yang dijamin ke server syslog tidak 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, apakah API berhasil 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