Kebijakan MessageLogging

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat dokumentasi Apigee Edge.

Apa

Kebijakan MessageLogging memungkinkan Anda mencatat pesan kustom ke Cloud Logging atau syslog. Anda dapat menggunakan informasi dalam log untuk berbagai tugas, seperti melacak masalah di lingkungan runtime API.

Kebijakan ini adalah Kebijakan yang dapat diperluas dan penggunaan kebijakan ini mungkin memiliki implikasi biaya atau penggunaan, bergantung pada lisensi Apigee Anda. Untuk informasi tentang jenis kebijakan dan implikasi penggunaan, lihat Jenis kebijakan.

Ada dua cara untuk menggunakan kebijakan MessageLogging:

• Elemen <CloudLogging> mencatat log pesan ke Cloud Logging. Untuk menggunakan metode ini, Anda harus mengaktifkan Cloud Logging API untuk project Google Cloud Anda. Untuk mengetahui informasi selengkapnya tentang cara mengaktifkan API untuk project Google Cloud, lihat Mengaktifkan dan Menonaktifkan Layanan.
• Elemen <Syslog> mencatat pesan ke syslog, protokol standar untuk mengirim log sistem atau pesan peristiwa ke server tertentu. Untuk menggunakan metode ini, Anda harus memiliki server syslog. Jika tidak, Anda dapat menggunakan layanan pengelolaan log publik, seperti Splunk, Sumo Logic, dan Loggly. Lihat Mengonfigurasi layanan pengelolaan log pihak ketiga.

Catatan: Anda tidak dapat menggunakan elemen <CloudLogging> dan elemen <Syslog> dalam kebijakan yang sama.

Elemen <MessageLogging>

Menentukan kebijakan <MessageLogging>.

Nilai default	Lihat tab Kebijakan Default, di bawah
Wajib?	Wajib
Jenis	JENIS
Elemen Induk	t/a
Elemen Turunan	<CloudLogging> <Syslog> <logLevel>

Elemen <MessageLogging> menggunakan sintaksis berikut:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging continueOnError="false" enabled="true" name="Message-Logging-1">
    <DisplayName>Message Logging-1</DisplayName>
    <Syslog>
<!-- Note: You cannot use both the <Syslog> element and the <CloudLogging> element in the same policy. -->
        <Message>Some message for syslog</Message>
        <Host>localhost</Host>
        <Port>514</Port>
    </Syslog>
    <CloudLogging>
<!-- Note: You cannot use both the <CloudLogging> and the <Syslog> element in the same policy. -->
        <LogName>projects/{organization.name}/logs/{log.id}</LogName>
        <Message contentType="application/json">{"{message.queryparam.key}": "{message.queryparam.value}"}</Message>
        <Labels>
            <Label>
                <Key>key1</Key>
                <Value>value1</Value>
            </Label>
            <Label>
                <Key>key2</Key>
                <Value>value2</Value>
            </Label>
        </Labels>
        <ResourceType>api</ResourceType>
    </CloudLogging>
    <logLevel>ALERT</logLevel>
</MessageLogging>

Elemen ini memiliki atribut berikut yang umum untuk semua kebijakan:

Atribut	Default	Wajib?	Deskripsi
name	T/A	Wajib	Nama internal kebijakan. Nilai atribut name dapat berisi huruf, angka, spasi, tanda hubung, garis bawah, dan titik. Nilai ini tidak boleh melebihi 255 karakter. Secara opsional, gunakan elemen <DisplayName> untuk memberi label pada kebijakan di editor proxy UI pengelolaan dengan nama bahasa alami yang berbeda.
continueOnError	false	Opsional	Tetapkan ke false untuk menampilkan error saat kebijakan gagal. Perilaku ini wajar terjadi untuk sebagian besar kebijakan. Tetapkan ke true agar eksekusi alur berlanjut meskipun setelah kebijakan gagal. Lihat juga: Aturan error HANYA dipicu dalam status error (tentang continueOnError) Menangani error dalam alur saat ini
enabled	benar	Opsional	Tetapkan ke true untuk menerapkan kebijakan. Tetapkan ke false untuk menonaktifkan kebijakan. Kebijakan tidak akan diterapkan meskipun tetap terlampir ke alur.
async	false	Tidak digunakan lagi	Atribut ini tidak digunakan lagi.

Tabel berikut memberikan deskripsi tingkat tinggi tentang elemen turunan <MessageLogging>:

Nama Kolom	Deskripsi Kolom
CloudLogging	Mengonfigurasi pesan untuk dicatat ke Cloud Logging.
Syslog	Konfigurasikan pesan untuk dicatat ke dalam log ke syslog.

Sampel

CloudLogging

<MessageLogging name="LogToCloudLogging">
    <CloudLogging>
        <LogName>projects/{organization.name}/logs/{log.id}</LogName>
        <Message contentType="application/json">{"{message.queryparam.key}": "{message.queryparam.value}"}</Message>
        <Labels>
            <Label>
                <Key>key1</Key>
                <Value>value1</Value>
            </Label>
            <Label>
                <Key>key2</Key>
                <Value>value2</Value>
            </Label>
        </Labels>
        <ResourceType>api</ResourceType>
    </CloudLogging>
</MessageLogging>

Contoh ini mengilustrasikan penggunaan template pesan. Karena elemen Message berisi variabel alur

{"{message.queryparam.key}": "{message.queryparam.value}"}

saat seseorang memanggil proxy dengan nilai message.queryparam.key = "fruit" dan message.queryparam.value = "apple", entri log yang dihasilkan akan berupa {"fruit": "apple"}.

Syslog

<MessageLogging name="LogToSyslog">
  <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>514</Port>
    <Protocol>TCP</Protocol>
    <FormatMessage>true</FormatMessage>
    <DateFormat>yyMMdd-HH:mm:ss.SSS</DateFormat>
  </Syslog>
  <logLevel>ALERT</logLevel>
</MessageLogging>

Dalam contoh ini, misalkan Anda perlu mencatat informasi tentang setiap pesan permintaan yang diterima API dari aplikasi konsumen. Nilai 3f509b58 mewakili nilai kunci khusus untuk layanan loggly. Jika Anda memiliki akun Loggly, ganti kunci Loggly Anda. Pesan log yang dihasilkan akan diisi dengan empat nilai: organisasi, proxy API, dan nama lingkungan yang terkait dengan transaksi, beserta nilai untuk parameter kueri pada pesan permintaan. Format stempel waktu akan mirip dengan 230704-13:42:17.376, sesuai dengan format yang ditentukan dalam elemen DateFormat.

Catatan: Elemen Host dan Port tidak dapat merujuk ke variabel. Nilai ini harus berisi nilai statis.

Syslog melalui TLS/SSL

<MessageLogging name="LogToSyslog">
  <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>WARN</logLevel>
</MessageLogging>

Anda dapat mengirim pesan ke penyedia logging pesan pihak ketiga melalui TLS/SSL dengan menambahkan blok <SSLInfo>.

Referensi elemen turunan

Bagian berikut menjelaskan elemen turunan <MessageLogging>.

<CloudLogging>

Gunakan elemen <CloudLogging> untuk mencatat pesan ke Cloud Logging.

Catatan: Untuk menggunakan <CloudLogging>, Anda harus mengaktifkan Cloud Logging API untuk project Google Cloud Anda. Untuk mengaktifkan API untuk project Google Cloud, lihat Mengaktifkan dan Menonaktifkan Layanan. Elemen <CloudLogging> kebijakan MessageLogging tersedia di Apigee dan Apigee hybrid versi v1.7.0 dan yang lebih baru.

Nama Kolom	Wajib?	Deskripsi
LogName	Ya	Nama log. Nama log harus dalam format projects/{PROJECT_ID}/logs/{LOG_ID}. Anda dapat menggunakan variabel sebagai pengganti {PROJECT_ID} dan {LOG_ID}.
Message	Ya	Pesan yang akan dicatat dalam log. Pesan memiliki atribut contentType, yang nilainya dapat berupa text/plain atau application/json untuk pesan teks dan JSON. Lihat Contoh. Catatan: Variabel respons tidak akan tersedia di PostClientFlow setelah Flow Error. Gunakan message. untuk mencatat informasi respons untuk situasi error dan keberhasilan. Lihat juga Catatan penggunaan. Catatan: Elemen <Message> mendukung fitur penggantian string dinamis yang disebut template pesan,
Label	Tidak	Label yang akan dilampirkan ke pesan log, jika ada. Ini akan berupa pasangan nilai kunci seperti berikut: <Label> <Key>key1</Key> <Value>value1</Value> </Label>
ResourceType	Tidak (defaultnya global)	Merepresentasikan resource yang dipantau yang menghasilkan log.

Autentikasi untuk Cloud Logging

Untuk menggunakan elemen <CloudLogging>, Anda harus men-deploy proxy API untuk menggunakan autentikasi Google. Apigee akan menggunakan kredensial yang sesuai dengan identitas akun layanan yang Anda tentukan dalam permintaan keluar ke Cloud Logging. Untuk mengetahui detail selengkapnya, lihat Menggunakan Autentikasi Google. Akun layanan yang Anda lampirkan ke proxy API pada waktu deployment harus memiliki peran dengan izin logging.logEntries.create. Untuk mengetahui informasi selengkapnya tentang peran Identity and Access Management (IAM) untuk <CloudLogging>, lihat Panduan kontrol akses.

<Syslog>

Gunakan elemen <Syslog> untuk mengonfigurasi pesan yang akan dicatat ke syslog. Saat Anda menggunakan <Syslog>, proxy API akan meneruskan pesan log dari Apigee ke server syslog jarak jauh. Untuk menggunakan metode ini, Anda harus memiliki server syslog. Jika tidak, layanan pengelolaan log publik, seperti Splunk, Sumo Logic, dan Loggly, tersedia. Lihat Mengonfigurasi layanan pengelolaan log pihak ketiga.

Nama Kolom	Wajib?	Deskripsi Kolom
Message	Ya	Pesan yang akan dicatat dalam log. Pesan memiliki atribut contentType, yang nilainya dapat berupa text/plain atau application/json untuk pesan teks dan JSON. Lihat Contoh. Catatan: Elemen <Message>> mendukung fitur penggantian string dinamis yang disebut template pesan, Catatan: Variabel respons tidak akan tersedia di PostClientFlow setelah Flow Error. Gunakan message. untuk mencatat informasi respons untuk situasi error dan keberhasilan. Lihat juga Catatan penggunaan.
Host	Tidak	Nama host atau alamat IP server tempat syslog akan dikirim. Jika Anda tidak menyertakan elemen ini, setelan defaultnya adalah localhost.
Port	Tidak	Port tempat syslog berjalan. Jika Anda tidak menyertakan elemen ini, defaultnya adalah 514.
Protocol	Tidak	TCP atau UDP (default). Meskipun UDP memiliki performa yang lebih baik, protokol TCP menjamin pengiriman log pesan ke server syslog. Untuk mengirim pesan syslog melalui TLS/SSL, hanya TCP yang didukung.
FormatMessage	Tidak, tetapi <FormatMessage>true</FormatMessage> diperlukan untuk digunakan dengan Loggly.	true atau false (default) Elemen ini memungkinkan Anda mengontrol format konten yang dibuat Apigee yang ditambahkan ke pesan. Jika ditetapkan ke true, pesan syslog akan diawali dengan sejumlah karakter tetap, yang memungkinkan Anda memfilter informasi tersebut dari pesan. Berikut adalah contoh untuk format tetap: <14>1 2023-03-20T09:24:39.039+0000 e49cd3a9-4cf6-48a7-abb9-7ftfe4d97d00 Apigee - - - Message starts here Informasi yang dihasilkan Apigee mencakup: <14> - Skor prioritas (lihat Protokol Syslog) berdasarkan tingkat log dan tingkat fasilitas pesan. 1 - Versi syslog saat ini. Tanggal dengan selisih waktu UTC (UTC = +0000). UUID pemroses pesan. "Apigee - - - " Jika disetel ke salah (default), pesan tidak diawali dengan karakter tetap tersebut. Catatan: Jika Anda menetapkan <FormatMessage>false</FormatMessage>, pesan log masih menyertakan skor prioritas dan tanggal. Untuk memformat pesan log agar hanya menyertakan isi pesan, tetapkan <PayloadOnly>true</PayloadOnly>. Lihat PayloadOnly.
PayloadOnly	Tidak	true atau false (default) Elemen ini menetapkan format pesan yang dihasilkan Apigee agar hanya berisi isi pesan syslog, tanpa karakter yang ditambahkan di awal yang ditentukan oleh FormatMessage. Jika Anda tidak menyertakan elemen ini atau membiarkannya kosong, nilai defaultnya adalah false. Lihat FormatMessage. Catatan: setelan <PayloadOnly>true</PayloadOnly> akan menggantikan setelan FormatMessage.
DateFormat	Tidak	String template pemformatan yang akan digunakan untuk memformat stempel waktu untuk setiap pesan log. Secara default, Apigee menggunakan yyyy-MM-dd'T'HH:mm:ss.SSSZ. Perilaku dari template ini dijelaskan dalam dokumentasi untuk class SimpleDateFormat Java. Menurut definisi tersebut, yyyy dalam string format akan diganti dengan tahun 4 digit, MM akan diganti dengan angka bulan 2 digit, dan seterusnya.
SSLInfo	Tidak	Memungkinkan Anda mencatat pesan melalui SSL/TLS. Gunakan dengan sub-elemen <Enabled>true</Enabled>. Jika Anda tidak menyertakan elemen ini atau membiarkannya kosong, nilai defaultnya adalah salah (tidak ada TLS/SSL). <SSLInfo> <Enabled>true</Enabled> </SSLInfo> Anda dapat mengonfigurasi tag <SSLInfo> sama seperti yang dapat Anda lakukan di TargetEndpoint, termasuk mengaktifkan TLS/SSL dua arah, seperti yang dijelaskan dalam referensi konfigurasi proxy API. Hanya protokol TCP yang didukung.

---

<logLevel>

Nilai yang valid untuk elemen <logLevel> adalah: INFO (default), ALERT, WARN, ERROR.

Menetapkan tingkat informasi tertentu yang akan disertakan dalam log pesan.

Jika Anda menggunakan elemen FormatMessage (menyetelnya ke true), setelan <logLevel> akan memengaruhi skor prioritas yang dihitung (angka di dalam tanda kurung sudut) dalam informasi yang dibuat Apigee yang ditambahkan ke pesan.

Catatan penggunaan

Saat melampirkan kebijakan MessageLogging ke alur proxy API, pertimbangkan untuk menempatkannya dalam respons ProxyEndpoint, dalam alur khusus yang disebut PostClientFlow. PostClientFlow dieksekusi setelah respons dikirim ke klien yang meminta, yang memastikan bahwa semua metrik tersedia untuk logging. Untuk mengetahui detail tentang cara menggunakan PostClientFlow, lihat referensi konfigurasi proxy API.

Catatan: Perlu diperhatikan bahwa variabel alur respons tidak tersedia di PostClientFlow setelah pemrosesan memasuki status error. Sebagai gantinya, Anda dapat menggunakan variabel message untuk menetapkan nilai dalam kebijakan MessageLogging di PostClientFlow, memastikan bahwa nilai tersebut akan ditetapkan terlepas dari apakah status errornya adalah konteks sebelumnya atau bukan. Untuk mengetahui informasi dan contoh selengkapnya, lihat Referensi variabel alur.

PostClientFlow istimewa dalam dua hal:

1. Fungsi ini hanya dieksekusi sebagai bagian dari alur respons.
2. Ini adalah satu-satunya alur yang dijalankan setelah proxy memasuki status error.

Karena kebijakan ini dijalankan terlepas dari apakah proxy berhasil atau gagal, Anda dapat menempatkan kebijakan MessageLogging di PostClientFlow dan dijamin bahwa kebijakan tersebut selalu dijalankan.

Gambar Debug berikut menunjukkan kebijakan MessageLogging yang dijalankan sebagai bagian dari PostClientFlow, setelah DefaultFaultRule dijalankan:

Dalam contoh ini, kebijakan Verifikasi Kunci API menyebabkan error karena kunci yang tidak valid.

Di bawah ini ditampilkan definisi ProxyEndpoint yang menyertakan PostClientFlow:

<ProxyEndpoint name="default">
  ...
  <PostClientFlow>
    <Response>
      <Step>
        <Name>Message-Logging-1</Name>
      </Step>
    </Response>
  </PostClientFlow>
  ...
</ProxyEndpoint>

Apigee mencatat pesan sebagai teks sederhana, dan Anda dapat mengonfigurasi logging untuk menyertakan variabel, seperti tanggal dan waktu saat permintaan atau respons diterima, identitas pengguna pada permintaan, alamat IP sumber tempat permintaan dikirim, dan sebagainya.

Apigee mencatat pesan secara asinkron: respons ditampilkan saat log masih ditulis. Akibatnya, tidak ada latensi yang diperkenalkan ke API Anda dengan memblokir info. Mungkin ada kalanya log tidak ditulis tanpa error yang ditampilkan, tetapi peristiwa ini jarang terjadi.

Kebijakan MessageLogging menulis pesan yang dicatat ke dalam memori ke buffering. Logger pesan membaca pesan dari buffering, lalu menulis ke tujuan yang Anda konfigurasi. Setiap tujuan memiliki buffer-nya sendiri.

Catatan: Panggilan proxy berhasil saat logging gagal

Karena logging pesan pertama kali ditulis ke buffering, proxy API akan terus menjalankan eksekusi yang berhasil meskipun logging pesan pada akhirnya gagal (misalnya, jika ada kegagalan koneksi ke tujuan).

Jika kecepatan tulis ke buffer meningkat di luar kecepatan baca, buffer akan meluap dan logging akan gagal. Jika hal ini terjadi, Anda mungkin menemukan salah satu pesan berikut dalam file log:

• Menggunakan <CloudLoggingg>:

  steps.messagelogging.TooManyPendingLoggingRequest

• Menggunakan <Syslog>:

  Log message size exceeded. Increase the max message size setting

Tingkatkan properti max.log.message.size.in.kb (nilai default = 128 KB) di file message-logging.properties.

Catatan: Variabel pesan respons di Apigee tidak tersedia dari Alur Error. Variabel ini juga tidak tersedia di PostClientFlow jika alur sebelumnya adalah Error Flow. Jika Anda ingin mencatat informasi respons dari PostClientFlow, gunakan message. Anda dapat menggunakan objek ini untuk mendapatkan header dan informasi lainnya dari respons, baik ada error maupun tidak. Lihat Referensi variabel alur untuk mengetahui informasi selengkapnya dan contoh.

Nilai default untuk variabel dalam template pesan

Nilai default dapat ditentukan untuk setiap variabel dalam template pesan secara terpisah. Misalnya, jika variabel request.header.id tidak dapat di-resolve, nilainya akan diganti dengan nilai unknown.

<Message>This is a test message. id = {request.header.id:unknown}</Message>

Nilai default umum dapat ditentukan untuk semua variabel yang belum terselesaikan dengan menetapkan atribut defaultVariableValue pada elemen Message:

<Message defaultVariableValue="unknown">This is a test message. id = {request.header.id}</Message>

Catatan: Nilai variabel default tidak boleh berisi spasi.

Mengonfigurasi layanan pengelolaan log pihak ketiga

Kebijakan MessageLogging memungkinkan Anda mengirim pesan syslog ke layanan pengelolaan log pihak ketiga, seperti Splunk, Sumo Logic, dan Loggly. Jika Anda ingin mengirim syslog ke salah satu layanan tersebut, lihat dokumentasi layanan tersebut untuk mengonfigurasi host, port, dan protokol layanan, lalu tetapkan elemen Syslog pada kebijakan ini sebagaimana mestinya.

Lihat dokumentasi berikut untuk konfigurasi pengelolaan log pihak ketiga:

• Splunk (pilih versi produk)
  Lihat juga postingan Komunitas Apigee ini: Mencatat pesan ke dalam Splunk
• Sumo Logic
  • Lihat juga postingan Komunitas Apigee ini: Menyiapkan Logging dengan Sumo Logic
  • Untuk mengetahui contoh lengkap penggunaan Sumo Logic sebagai layanan logging, lihat posting Komunitas Apigee berikut. Solusi ini menggunakan satu kebijakan JavaScript untuk membuat permintaan POST HTTP ke Sumo Logic HTTP Source Collector: Mencatat ke Sumo Logic menggunakan JavaScript dan HTTP
• Loggly
  Saat menggunakan Loggly, <FormatMessage>true</FormatMessage> diperlukan dalam kebijakan sebagai turunan dari elemen <Syslog>.
  Lihat juga postingan Komunitas Apigee ini untuk mengetahui informasi selengkapnya tentang logging pesan ke Loggly: Mencatat Pesan ke Loggly

Referensi error

Bagian ini menjelaskan kode error dan pesan error yang ditampilkan serta variabel error yang ditetapkan oleh Apigee saat kebijakan ini memicu error. Informasi ini penting untuk diketahui jika Anda mengembangkan aturan error untuk menangani error. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Menangani error.

Error runtime

Error ini dapat terjadi saat kebijakan dieksekusi.

Kode kerusakan	Status HTTP	Penyebab
steps.messagelogging.StepDefinitionExecutionFailed	500	Lihat string error.
steps.messagelogging.InvalidGoogleCloudLogName	500	Error ini ditampilkan saat LogName tidak dievaluasi ke format project/{project}/logs/{logid} yang valid.
steps.messagelogging.InvalidJsonMessage	500	Error ini ditampilkan saat nilai atribut contentType telah dipilih sebagai application/json, tetapi nilai pesan yang sebenarnya bukan string JSON yang valid,
steps.messagelogging.TooManyPendingLoggingRequest	500	Error ini ditampilkan saat ada lebih dari 2.500 permintaan tertunda yang belum ditulis ke Cloud Logging. Batas 2.500 adalah untuk setiap pod runtime Apigee. Misalnya, jika traffic didistribusikan di dua instance pod runtime Apigee, batas efektifnya adalah 5.000 permintaan.

-

Error saat deployment

Error ini dapat terjadi saat Anda men-deploy proxy yang berisi kebijakan ini.

Tips: Perlu bantuan untuk mengatasi error? Klik di kolom Perbaiki untuk mendapatkan informasi pemecahan masalah mendetail.

Nama error	Penyebab	Perbaiki
InvalidProtocol	Deployment kebijakan MessageLogging dapat gagal dengan error ini jika protokol yang ditentukan dalam elemen <Protocol> tidak valid. Protokol yang valid adalah TCP dan UDP. Untuk mengirim pesan syslog melalui TLS/SSL, hanya TCP yang didukung.
InvalidPort	Deployment kebijakan MessageLogging dapat gagal dengan error ini jika nomor port tidak ditentukan dalam elemen <Port> atau jika tidak valid. Nomor port harus berupa bilangan bulat yang lebih besar dari nol.

Variabel error

Variabel ini ditetapkan saat error runtime terjadi. Untuk mengetahui informasi selengkapnya, lihat Yang perlu Anda ketahui tentang error kebijakan.

Catatan: Panggilan proxy berhasil saat logging gagal

Ada perbedaan antara error kebijakan dan error logging pesan. Variabel alur di sini hanya diisi saat kebijakan itu sendiri gagal, bukan saat logging pesan gagal. Karena logging pesan pertama kali ditulis ke buffering, proxy API akan melanjutkan eksekusi yang berhasil meskipun logging pesan pada akhirnya gagal (misalnya, jika ada kegagalan koneksi ke penyedia syslog eksternal). Pastikan untuk memeriksa log secara rutin untuk memastikan logging terjadi seperti yang diharapkan.

Variabel	Dari mana	Contoh
fault.name="fault_name"	fault_name adalah nama error, seperti yang tercantum dalam tabel Runtime errors di atas. Nama error adalah bagian terakhir dari kode error.	fault.name Matches "StepDefinitionExecutionFailed"
messagelogging.policy_name.failed	policy_name adalah nama kebijakan yang ditentukan pengguna yang menampilkan error.	messagelogging.ML-LogMessages.failed = true

Contoh respons error

Catatan: Untuk penanganan error, praktik terbaiknya adalah menangkap bagian errorcode dari respons error. Jangan mengandalkan teks di faultstring, karena teks tersebut dapat berubah.

{  
   "fault":{
      "detail":{
         "errorcode":"steps.messagelogging.StepDefinitionExecutionFailed"
      },
      "faultstring":"Execution failed"
   }
}

Contoh aturan error

<FaultRule name="MessageLogging">
    <Step>
        <Name>ML-LogMessages</Name>
        <Condition>(fault.name Matches "StepDefinitionExecutionFailed") </Condition>
    </Step>
    <Condition>(messagelogging.ML-LogMessages.failed = true) </Condition>
</FaultRule>

---

Variabel alur

Variabel berikut diisi saat kebijakan gagal.

• messagelogging.failed
• messagelogging.{stepdefinition-name}.failed

Catatan: Panggilan proxy berhasil saat logging gagal

Ada perbedaan antara error kebijakan dan error logging pesan. Variabel alur di sini hanya diisi saat kebijakan itu sendiri gagal, bukan saat logging pesan gagal. Karena logging pesan pertama kali ditulis ke buffering, proxy API akan melanjutkan eksekusi yang berhasil meskipun logging pesan pada akhirnya gagal (misalnya, jika ada kegagalan koneksi ke penyedia syslog eksternal). Pastikan untuk memeriksa log secara rutin untuk memastikan logging terjadi seperti yang diharapkan.

---

Topik terkait

• Variabel yang ditampilkan oleh Apigee: Referensi variabel alur