Kebijakan MessageLogging

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat Dokumentasi Apigee Edge.

Apa

Kebijakan {i>MessageLogging<i} memungkinkan Anda mencatat pesan khusus ke Cloud Logging atau syslog. Anda dapat menggunakan informasi di log untuk berbagai tugas, seperti seperti melacak masalah di lingkungan runtime API.

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

Ada dua cara untuk menggunakan kebijakan MessageLogging:

• <CloudLogging> membuat log pesan elemen ke Cloud Logging. Untuk menggunakan metode ini, Anda harus mengaktifkan Cloud Logging API untuk project Google Cloud Anda. Untuk selengkapnya informasi tentang cara mengaktifkan API untuk project Google Cloud, lihat Mengaktifkan dan Menonaktifkan Layanan.
• Log elemen <Syslog> pesan ke syslog, protokol standar untuk mengirim log sistem atau pesan peristiwa ke server tertentu. Untuk menggunakan metode ini, Anda harus memiliki server syslog yang tersedia. 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> secara bersamaan dan <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>gce_instance</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 dari <MessageLogging>:

Nama Kolom	Deskripsi Kolom
CloudLogging	Mengonfigurasi pesan untuk dicatat ke dalam log Cloud.
Syslog	Konfigurasi pesan untuk dicatat ke dalam log 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>gce_instance</ResourceType>
    </CloudLogging>
</MessageLogging>

Contoh ini menggambarkan penggunaan template pesan. Karena elemen Message berisi flow variabel

{"{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 {"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, anggaplah Anda perlu mencatat informasi tentang setiap pesan permintaan yang API yang diterima dari aplikasi konsumen. Nilai 3f509b58 mewakili nilai kunci khusus untuk layanan loggly. Jika Anda memiliki akun loggly, ganti kunci loggly Anda. Tujuan pesan log yang dibuat akan diisi dengan empat nilai: organisasi, API proxy, dan nama lingkungan yang terkait dengan transaksi, bersama dengan nilai untuk kueri pada pesan permintaan. Format stempel waktu akan mirip dengan 230704-13:42:17.376, sesuai dengan format yang ditentukan dalam DateFormat .

Catatan: Elemen Host dan Port tidak boleh merujuk ke variabel. Class tersebut 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 atribut Blok <SSLInfo>.

Referensi elemen turunan

Bagian berikut menjelaskan elemen turunan dari <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. Kepada mengaktifkan API untuk project Google Cloud, lihat Mengaktifkan dan Menonaktifkan Layanan. Tujuan Elemen <CloudLogging> kebijakan MessageLogging tersedia di Apigee dan Apigee versi hybrid 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. Pesan ini memiliki atribut contentType, yang nilainya dapat berupa text/plain atau application/json untuk pesan teks dan JSON. Lihat Contoh. Catatan: Variabel respons akan tidak tersedia di PostClientFlow mengikuti Alur Error. Gunakan message. untuk mencatat informasi respons baik untuk situasi {i>error<i} dan keberhasilan. Lihat juga Catatan penggunaan. Catatan: Elemen <Message> mendukung string dinamis fitur substitusi yang disebut menjadi template pesan,
Label	Tidak	Label yang akan dilampirkan ke pesan log, jika ada. Kode ini akan dalam bentuk pasangan nilai kunci seperti berikut: <Label> <Key>key1</Key> <Value>value1</Value> </Label>
ResourceType	Tidak (default-nya adalah global)	Mewakili resource yang dimonitor yang membuat log.

Autentikasi untuk Cloud Logging

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

&lt;Syslog&gt;

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

Nama Kolom	Wajib?	Deskripsi Kolom
Message	Ya	Pesan yang akan dicatat. Pesan ini memiliki atribut contentType, yang nilainya dapat berupa text/plain atau application/json untuk pesan teks dan JSON. Lihat Contoh. Catatan: Elemen <Message>> mendukung string dinamis fitur substitusi yang disebut menjadi template pesan, Catatan: Variabel respons akan tidak tersedia di PostClientFlow mengikuti Alur Error. Gunakan message. untuk mencatat informasi respons baik untuk situasi {i>error<i} dan keberhasilan. Lihat juga Catatan penggunaan.
Host	Tidak	Nama host atau alamat IP server tempat syslog harus dikirim. Jika Anda tidak menyertakan elemen ini, defaultnya adalah {i>localhost<i}.
Port	Tidak	Port tempat syslog berjalan. Jika Anda tidak menyertakan elemen ini, defaultnya adalah 514.
Protocol	Tidak	TCP atau UDP (default). Meskipun UDP lebih berperforma tinggi, Protokol TCP menjamin pengiriman log pesan ke server {i>syslog<i}. Untuk mengirim syslog pesan melalui TLS/SSL, hanya TCP yang didukung.
FormatMessage	Tidak, tetapi <FormatMessage>true</FormatMessage> wajib diisi untuk digunakan dengan Loggly.	true atau false (default) Elemen ini memungkinkan Anda mengontrol format konten buatan Apigee yang ditambahkan ke untuk membuat pesan email baru. Jika diatur ke benar (true), pesan {i>syslog<i} diawali dengan sejumlah karakter yang tetap, yang memungkinkan Anda untuk memfilter informasi tersebut dari pesan. Berikut contoh untuk konfigurasi format: <14>1 2023-03-20T09:24:39.039+0000 e49cd3a9-4cf6-48a7-abb9-7ftfe4d97d00 Apigee - - - Message starts here Informasi yang dibuat Apigee mencakup: <14> - Skor prioritas (lihat Protokol Syslog) yang didasarkan pada tingkat log dan tingkat fasilitas pesan. 1 - Versi syslog saat ini. Tanggal dengan selisih UTC (UTC = +0000). UUID pemroses pesan. "Apigee - - - " Jika ditetapkan ke salah (default), pesan tidak akan ditambahkan dengan yang telah diperbaiki karakter. Catatan: Jika Anda menetapkan <FormatMessage>false</FormatMessage>, pesan log tetap berisi 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 memuat isi pesan syslog, tanpa karakter tambahan yang ditentukan oleh FormatMessage. Jika Anda tidak menyertakan elemen ini atau membiarkannya kosong, nilai defaultnya adalah false. Lihat FormatMessage. Catatan: setelan <PayloadOnly>true</PayloadOnly> mengganti setelan FormatMessage.
DateFormat	Tidak	String template pemformatan yang akan digunakan untuk memformat stempel waktu setiap pesan log. Secara default, Apigee menggunakan yyyy-MM-dd'T'HH:mm:ss.SSSZ. Perilaku template ini dijelaskan dalam dokumentasi untuk Class SimpleDateFormat Java. Menurut definisi itu, yyyy dalam format string akan diganti dengan tahun yang terdiri dari 4 digit, MM akan menjadi 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 false (tidak TLS/SSL). <SSLInfo> <Enabled>true</Enabled> </SSLInfo> Anda dapat mengonfigurasi tag &lt;SSLInfo&gt; dengan cara yang sama dapat dilakukan di TargetEndpoint, termasuk mengaktifkan TLS/SSL dua arah, seperti yang dijelaskan dalam Referensi konfigurasi proxy API. Hanya protokol TCP yang didukung.

---

&lt;logLevel&gt;

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

Menyetel tingkat informasi tertentu untuk disertakan dalam log pesan.

Jika Anda menggunakan elemen FormatMessage (menyetelnya ke true), elemen Setelan <logLevel> memengaruhi skor prioritas yang dihitung (angka di dalam tanda kurung siku) ditambahkan sebelum informasi yang dihasilkan Apigee pada pesan.

Catatan penggunaan

Saat melampirkan kebijakan MessageLogging ke alur proxy API, pertimbangkan untuk menempatkannya di 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 penggunaan PostClientFlow, lihat Referensi konfigurasi proxy API.

Catatan: Penting untuk diperhatikan bahwa alur respons tidak tersedia di PostClientFlow setelah pemrosesan memasuki status error. Sebagai gantinya, Anda dapat menggunakan variabel message untuk menetapkan nilai di MessageLogging di PostClientFlow, memastikan bahwa kebijakan akan disetel terlepas dari apakah status error konteks sebelumnya. Untuk informasi dan contoh selengkapnya, lihat Referensi variabel flow.

PostClientFlow istimewa dalam dua hal:

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

Karena dijalankan terlepas dari apakah {i>proxy<i} berhasil atau gagal, Anda dapat menempatkan Kebijakan MessageLogging di PostClientFlow dan dijamin selalu dieksekusi.

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

Dalam contoh ini, kebijakan Verify API Key menyebabkan kesalahan karena tombol.

Di bawah ini adalah definisi ProxyEndpoint yang menyertakan PostClientFlow:

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

Apigee mencatat pesan ke dalam log 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 asal permintaan dikirim, dan seterusnya.

Pesan log Apigee secara asinkron: responsnya dikembalikan selagi log sedang ditulis. Akibatnya, tidak ada latensi yang diperkenalkan ke API Anda dengan memblokir info. Mungkin ada terkadang {i>log<i} tidak ditulis tanpa menampilkan {i>error<i}, tetapi peristiwa jarang terjadi.

Kebijakan MessageLogging menulis pesan yang dicatat dalam memori ke buffer. Pencatat pesan membaca pesan dari buffer, lalu menulis ke tujuan yang Anda konfigurasi. Masing-masing tujuan memiliki buffer-nya sendiri.

Catatan: Panggilan proxy berhasil saat logging gagal

Karena logging pesan pertama kali ditulis ke buffer, proxy API akan tetap berhasil eksekusi meskipun logging pesan pada akhirnya gagal (misalnya, jika ada koneksi gagal ke tujuannya).

Jika kecepatan tulis ke {i>buffer<i} meningkat melebihi kecepatan baca, {i>buffer<i} akan meluber dan pencatatan log akan gagal. Jika hal ini terjadi, Anda mungkin menemukan salah satu pesan berikut di log file:

• 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 bagian File message-logging.properties.

Catatan: Pesan respons variabel di Apigee tidak tersedia dari Alur Error. Variabel-variabel ini juga bukan tersedia di PostClientFlow jika alur sebelumnya adalah Alur Error. Jika Anda ingin mencatat respons informasi dari PostClientFlow, gunakan message. Anda dapat gunakan objek ini untuk mendapatkan header dan informasi lain dari respons, terlepas dari adalah {i>error<i}. Lihat Referensi variabel flow untuk mengetahui informasi selengkapnya dan contoh.

Nilai default untuk variabel dalam template pesan

Nilai default dapat ditentukan untuk setiap variabel di template pesan secara terpisah. Misalnya, jika variabel request.header.id tidak dapat diselesaikan, 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 di 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 {i>MessageLogging<i} memungkinkan Anda mengirim pesan syslog ke manajemen log pihak ketiga seperti Splunk, Sumo Logic, dan Loggly. Jika Anda ingin mengirim {i> syslog<i} ke salah satu layanan, lihat dokumentasi layanan itu untuk mengkonfigurasi {i>host<i}, porta, dan protokol layanan, kemudian 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 Splunk
• Sumo Logika
  • Lihat juga postingan Komunitas Apigee ini: Menyiapkan Logging dengan Sumo Logic
  • Untuk contoh lengkap penggunaan Sumo Logic sebagai layanan logging, lihat contoh berikut Postingan Komunitas Apigee. Solusi ini menggunakan kebijakan JavaScript tunggal untuk membuat HTTP POST permintaan ke Kolektor Sumber HTTP Sumo Logic: Logging ke Sumo Logic menggunakan JavaScript dan HTTP
• Loggly
  Saat menggunakan Loggly, <FormatMessage>true</FormatMessage> diperlukan di 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 kesalahan dan pesan error yang ditampilkan dan variabel kesalahan yang disetel oleh Apigee saat kebijakan ini memicu error. Informasi ini penting untuk diketahui apakah Anda mengembangkan aturan kesalahan untuk menangani kesalahan. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Menangani kesalahan.

Error runtime

Error ini dapat terjadi saat kebijakan dieksekusi.

Kode kesalahan	Status HTTP	Penyebab
steps.messagelogging.StepDefinitionExecutionFailed	500	Lihat string kesalahan.
steps.messagelogging.InvalidGoogleCloudLogName	500	Error ini ditampilkan jika LogName tidak dievaluasi ke format projects/{project}/logs/{logid} yang valid.
steps.messagelogging.InvalidJsonMessage	500	Error ini ditampilkan jika nilai atribut contentType telah dipilih sebagai application/json, tetapi nilai pesan yang sebenarnya bukanlah string JSON yang valid.
steps.messagelogging.TooManyPendingLoggingRequest	500	Error ini ditampilkan jika ada lebih dari 2.500 permintaan tertunda yang belum ditulis ke Cloud Logging. Batas 2.500 ditujukan untuk setiap pod runtime Apigee. Misalnya, jika traffic didistribusikan ke 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 mengetahui informasi pemecahan masalah selengkapnya.

Nama error	Penyebab	Perbaikan
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 kesalahan

Variabel ini ditetapkan saat terjadi error runtime. Untuk 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 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 Anda secara teratur untuk memastikan logging terjadi seperti yang diharapkan.

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

Contoh respons error

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

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

Contoh aturan kesalahan

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

---

Variabel flow

Variabel berikut akan diisi jika kebijakan gagal.

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

Catatan: Panggilan proxy berhasil saat logging gagal

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

---

Topik terkait

• Variabel yang diekspos oleh Apigee: Referensi variabel flow