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 mengetahui informasi tentang jenis kebijakan dan implikasi penggunaannya, lihat Jenis kebijakan.

Ada dua cara untuk menggunakan kebijakan MessageLogging:

• Elemen <CloudLogging> mencatat 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 pesan log atau peristiwa sistem 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 umum tentang elemen turunan dari <MessageLogging>:

Nama Kolom	Deskripsi Kolom
CloudLogging	Mengonfigurasi pesan yang akan dicatat ke Cloud Logging.
Syslog	Konfigurasi pesan yang akan dicatat 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 adalah {"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 Anda dari aplikasi konsumen. Nilai 3f509b58 merepresentasikan nilai kunci khusus untuk layanan loggly. Jika Anda memiliki akun loggly, ganti kunci loggly Anda. Pesan log yang dihasilkan akan diisi dengan empat nilai: nama organisasi, proxy API, dan 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. 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> dari 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}. Catatan: LogName menentukan nama resource log Cloud Logging untuk mengirim entri log. Dengan menggunakan variabel, kebijakan MessageLogging memungkinkan Anda menyisipkan nilai nama yang berbeda dan unik secara dinamis untuk setiap entri LogName ; namun, kami tidak menyarankan praktik ini, dan merekomendasikan agar Anda tidak membuat nama log unik secara dinamis dengan nilai yang dapat berubah dari permintaan ke permintaan, karena dapat menyebabkan masalah kardinalitas tinggi. Sebagai gantinya, sebaiknya gunakan nama tetap yang bermakna dari kumpulan nama tetap untuk LogName.
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 Error Flow. 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 pada pesan log, jika ada. Nilai ini akan berbentuk pasangan nilai kunci seperti berikut: <Label> <Key>key1</Key> <Value>value1</Value> </Label>
ResourceType	Tidak (default ke global)	Mewakili 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 saat waktu deployment harus memiliki peran dengan izin logging.logEntries.create. Kecuali jika Anda memerlukan kontrol yang lebih terperinci, sebaiknya gunakan peran bawaan yang lebih inklusif, yaitu roles/logging.logWriter, untuk akun layanan. Untuk mengetahui informasi selengkapnya tentang peran Identity and Access Management (IAM) untuk <CloudLogging>, lihat Panduan kontrol akses.

Deployment proxy di Apigee hybrid

Jika Anda menggunakan Apigee Hybrid, akun layanan runtime yang Anda buat untuk Apigee Hybrid harus meniru identitas akun layanan proxy untuk melakukan panggilan yang diautentikasi atas namanya. Oleh karena itu, akun layanan runtime Apigee Hybrid harus memiliki peran iam.serviceAccountTokenCreator untuk akun layanan proxy.

<Syslog>

Gunakan elemen <Syslog> untuk mengonfigurasi pesan yang akan dicatat ke syslog. Saat Anda menggunakan <Syslog>, proxy API 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 pembuatan template pesan, Catatan: Variabel respons tidak akan tersedia di PostClientFlow setelah Error Flow. 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 harus dikirim. Jika Anda tidak menyertakan elemen ini, 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 lebih berperforma, 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 dihasilkan Apigee yang ditambahkan ke pesan. Jika disetel ke benar (true), pesan syslog akan diawali dengan sejumlah karakter tetap, yang memungkinkan Anda memfilter informasi tersebut dari pesan. Berikut 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 Syslog Protocol) 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 false (default), pesan tidak akan diawali dengan karakter tetap tersebut. Catatan: Jika Anda menetapkan <FormatMessage>false</FormatMessage>, pesan log tetap mencakup 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: menyetel <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 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 nomor 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> dengan cara yang 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 (menetapkannya ke benar), setelan <logLevel> Anda akan memengaruhi skor prioritas yang dihitung (angka di dalam tanda kurung sudut) dalam informasi yang dihasilkan Apigee yang ditambahkan ke 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 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, sehingga nilai tersebut akan ditetapkan terlepas dari apakah status error adalah konteks sebelumnya atau tidak. Untuk mengetahui informasi dan contoh selengkapnya, lihat Referensi variabel alur.

PostClientFlow bersifat khusus dalam dua hal:

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

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

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

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

Di bawah ini adalah definisi ProxyEndpoint yang mencakup 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 dari tempat permintaan dikirim, dan sebagainya.

Apigee mencatat pesan secara asinkron: respons akan ditampilkan saat log masih ditulis. Akibatnya, tidak ada latensi yang terjadi pada API Anda dengan memblokir panggilan. Mungkin ada saat ketika log tidak ditulis tanpa error yang ditampilkan, tetapi peristiwa ini 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. Setiap tujuan memiliki buffer-nya sendiri.

Catatan: Panggilan proxy berhasil saat logging gagal

Karena pencatatan pesan pertama-tama ditulis ke buffer, proxy API akan terus berhasil dieksekusi meskipun pencatatan pesan pada akhirnya gagal (misalnya, jika terjadi kegagalan koneksi ke tujuan).

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

• Menggunakan <CloudLogging>:

  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 responsdi Apigee tidak tersedia dari Alur Error. Variabel ini juga tidak tersedia di PostClientFlow jika alur sebelumnya adalah Alur Error. Jika Anda ingin mencatat informasi respons dari PostClientFlow, gunakan message. Anda dapat menggunakan objek ini untuk mendapatkan header dan informasi lain dari respons, baik ada kesalahan maupun tidak. Lihat Referensi variabel alur untuk mengetahui informasi dan contoh selengkapnya.

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 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 diselesaikan 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 dengan tepat.

Lihat dokumentasi berikut untuk konfigurasi pengelolaan log pihak ketiga:

• Splunk (pilih versi produk)
  Lihat juga postingan Komunitas Apigee ini: Log messages into Splunk
• Sumo Logic
  • Lihat juga postingan Komunitas Apigee ini: Menyiapkan Logging dengan Sumo Logic
  • Untuk contoh lengkap yang menggunakan Sumo Logic sebagai layanan logging, lihat postingan Komunitas Apigee berikut. Solusi ini menggunakan satu kebijakan JavaScript untuk membuat permintaan POST HTTP ke Pengumpul Sumber HTTP Sumo Logic: Logging ke Sumo Logic menggunakan JavaScript dan HTTP
• Loggly
  Saat menggunakan Loggly, <FormatMessage>true</FormatMessage> diperlukan dalam kebijakan sebagai turunan elemen <Syslog>.
  Lihat juga postingan Komunitas Apigee ini untuk mengetahui informasi selengkapnya tentang logging pesan ke Loggly: Log Messages into 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 dijalankan.

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 mengetahui 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 jika kebijakan itu sendiri gagal, bukan jika logging pesan gagal. Karena pencatatan pesan ditulis terlebih dahulu ke buffer, proxy API akan terus berhasil dieksekusi meskipun pencatatan pesan pada akhirnya gagal (misalnya, jika ada kegagalan koneksi ke penyedia syslog eksternal). Pastikan untuk memeriksa log Anda secara rutin untuk memastikan logging berjalan seperti yang diharapkan.

---

Topik terkait

• Variabel yang diekspos oleh Apigee: Referensi variabel alur