Panduan pemecahan masalah Message Processor

Topik ini membahas langkah-langkah yang dapat Anda lakukan untuk memecahkan masalah dan memperbaiki masalah pada pemroses pesan. Prosesor pesan adalah bagian dari komponen apigee-runtime. Lihat juga Ringkasan konfigurasi layanan runtime.

Pemeriksaan kesiapan gagal dengan kode status HTTP 500

Gejala

Satu atau beberapa pod apigee-runtime tidak dalam status Siap.

Pesan error

Saat menggunakan kubectl untuk mendeskripsikan pod apigee-runtime yang gagal, Anda akan melihat error:

Readiness probe failed: HTTP probe failed with statuscode: 500

Contoh:

kubectl describe pod -n hybrid \
apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7

...
apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7  Readiness probe failed: HTTP probe
failed with statuscode: 500
...

Kemungkinan penyebab

Error ini berarti tidak ada kontrak aktif yang tersedia bagi pemroses pesan untuk melayani traffic. Dalam status ini, pemroses pesan tidak dapat menyebut dirinya "siap".

Penyebab Deskripsi
Masalah koneksi Synchronizer ke bidang pengelolaan Penyinkron tidak dapat terhubung ke bidang pengelolaan. Masalah ini biasanya terjadi jika Anda mengganti URL contractProvider dan mengaitkan akun layanan yang salah dengannya. Misalnya, jika Anda mengonfigurasi akun layanan untuk deployment staging dengan URL contractProvider yang mengarah ke server produksi.
Masalah koneksi pemroses pesan ke penyinkron Jika MP baru muncul sebagai bagian dari penskalaan otomatis atau mulai ulang pod, Anda mungkin akan melihat error ini. Umumnya, masalah ini terjadi saat sinkronisasi tidak berfungsi dan MP tidak dapat memuat kontraknya.

Diagnosis: Masalah koneksi bidang pengelolaan ke sinkronisasi

Untuk mendiagnosis masalah koneksi sinkronisasi ke bidang pengelolaan, lakukan hal berikut:

  1. Mencantumkan pod di cluster: 
    kubectl get pods -n namespace
  2. Buka shell di pod apigee-synchronizer: 
    kubectl exec -it -n namespace synchronizer-pod-name bash

    Contoh:

    kubectl exec -it -n apigee apigee-synchronizer-apigee-gcp-prod1-test-blue-cnj5x bash
  3. Buka direktori berikut: 
    cd /opt/apigee/var/log/apigee-synchronizer
ls

  dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750
  drwxr-sr-x 2 apigee apigee  4096 Sep 12 16:52 cachedFiles
  -rw-r--r-- 1 apigee apigee 22295 Sep 12 16:52 config.log
  -rw-r--r-- 1 apigee apigee    76 Sep 12 16:52 versions.properties
  4. Periksa versi aktif di version.properties. Contoh: 
    cat versions.properties

  #active repository version
  #Sat Dec 14 19:45:00 GMT 2019
  active.version=749
  5. Pastikan nilai active.version cocok dengan nama folder kontrak nomor. Dalam contoh di atas (juga ditampilkan di bawah), nama foldernya adalah 750; oleh karena itu, nama tersebut tidak cocok: 
    dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750
  6. Keluar dari shell pod.

Resolusi

Jika version.properties tidak ada, atau jika ada perbedaan versi seperti yang dijelaskan di atas, periksa log sinkronisasi untuk mencoba menentukan alasan kontrak terbaru tidak didownload. Contoh:

kubectl logs -f -n namespace synchronizer-pod-name

Untuk mengetahui informasi tentang cara menafsirkan log sinkronisasi, lihat Log sinkronisasi. Jika sinkronisasi tidak berfungsi, coba mulai ulang menggunakan apigeectl. Contoh: 

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name

Diagnosis: Masalah koneksi pemroses pesan ke sinkronisasi

Untuk mendiagnosis masalah koneksi prosesor pesan ke sinkronisasi, lakukan hal berikut:

  1. Mencantumkan pod di cluster: 
    kubectl get pods -n namespace
  2. Periksa log runtime untuk mencoba mencari tahu alasan kontrak tidak didownload: 
    kubectl logs -f -n namespace pod-name

    Contoh:

    kubectl logs -f -n apigee apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7

    Hal ini dapat terjadi jika MP baru muncul sebagai bagian dari penskalaan otomatis atau memulai ulang pod, sehingga MP mungkin tidak memuat kontrak. Secara umum, masalah ini terjadi saat sinkronisasi tidak berfungsi, sehingga MP tidak dapat memuat kontrak. Contoh: 

    2019-09-13 16:59:24,331 podName:N/A ipAddress:N/A dpColor:N/A
HttpClient@331886186-301 DEBUG o.e.j.c.AbstractConnectionPool - AbstractConnectionPool$1.failed() :
Connection 1/64 creation failed
java.net.UnknownHostException: apigee-synchronizer-apigee-gcp-prod1-test.hybrid.svc.cluster.local
at java.net.InetAddress.getAllByName0(InetAddress.java:1281)
at java.net.InetAddress.getAllByName(InetAddress.java:1193)
at java.net.InetAddress.getAllByName(InetAddress.java:1127)
at org.eclipse.jetty.util.SocketAddressResolver$Async.lambda$resolve$1(SocketAddressResolver.java:167)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
at java.lang.Thread.run(Thread.java:748)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
	at java.lang.Thread.run(Thread.java:748)

Resolusi

Coba mulai ulang sinkronisasi. Contoh: 

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name

Pemeriksaan kesiapan gagal karena kunci enkripsi tidak valid

Gejala

Pod apigee-runtime tidak dalam status Siap.

Diagnosis

Saat Anda menggunakan kubectl untuk mendeskripsikan pod apigee-runtime yang gagal, Anda akan melihat error ini: Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed. Contoh: 

$ kubectl describe pod -n namespace apigee-runtime-pod-name

...
Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed due to
com.apigee.probe.model.ProbeFailedException{ code = hybrid.encryption.key.InvalidEncryptionKey,
message = Invalid encryption key. Please check the length of the encryption key, associated
contexts = []}
...

Resolusi

Panjang kunci enkripsi yang didukung adalah 16 atau 24 atau 32 byte dan nilai kunci harus dienkode dengan base64. Untuk mengetahui informasi selengkapnya tentang cara membuat kunci yang diformat dengan benar, lihat Enkripsi data.

Melihat log pemroses pesan

Untuk mengetahui detail tentang cara melihat dan menafsirkan log pemroses pesan, lihat Log runtime.

Memanggil proxy API dari pod runtime

Dalam beberapa situasi untuk membantu mengisolasi masalah, Anda mungkin ingin memeriksa apakah Anda dapat melakukan panggilan proxy API langsung dari dalam pod apigee-runtime, dan dengan demikian melewati gateway ingress.

  1. Jalankan perintah berikut untuk meneruskan ke port 8443. Hal ini memungkinkan Anda memanggil API di pod: 
    kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
  2. Panggil proxy API yang di-deploy. Misalnya, jika basepath proxy adalah ilove-apis: 
    curl -k -v https://0:8443//ilove-apis

    < HTTP/1.1 200 OK
    < X-Powered-By: Apigee
    < Access-Control-Allow-Origin: *
    < X-Frame-Options: ALLOW-FROM RESOURCE-URL
    < X-XSS-Protection: 1
    < X-Content-Type-Options: nosniff
    < Content-Type: text/html; charset=utf-8
    < Content-Length: 18
    < ETag: W/"12-Jb9QP1bUxNSmZkxQGt5KLQ"
    < Date: Fri, 13 Sep 2019 18:33:46 GMT
    < Via: 1.1 google
    < X-Apigee.Message-ID: 016f5f7f-c59e-404c-86e8-7b0737833f982
    < X-Apigee.dp.color: blue
    < X-Apigee.proxy: /organizations/my-org/environments/test/apiproxies/i-loveapis/revisions/1
    < X-Apigee.proxy.basepath: /ilove-apis
    < X-Apigee.target-latency: 9
    <
    * Connection #0 to host 0 left intact
    <H2>I <3 APIs

Memeriksa Management API

Anda dapat menggunakan API yang dijelaskan di bawah untuk memeriksa apakah Management API berfungsi dengan baik.

  1. Dapatkan nama pod di cluster Anda: 
    kubectl get pods -n namespace
  2. Gunakan port forwarding untuk mendapatkan akses ke pod apigee-runtime. Sintaksis untuk penerusan porta adalah sebagai berikut: 
    kubectl port-forward -n namespace podname 8843:8843

    Contoh:

    kubectl port-forward -n apigee \
    apigee-runtime-my-organization-test-blue-57965b7789-6j4bp 8843:8843
  3. Kemudian, di jendela terminal lain, gunakan utilitas seperti curl untuk mengirim permintaan ke classification/tree API, seperti yang ditunjukkan contoh berikut: 
    curl -k https://0:8843/v1/classification/tree

    Berikut adalah contoh respons, yang mencantumkan informasi tentang proxy yang di-deploy di lingkungan "test":

    [ {
  "condition" : "(always matches)",
  "virtualHost" : {
    "env" : "test",
    "name" : "default",
    "org" : "my-organization",
    "tree" : {
      "elements" : [ {
        "application" : "myproxy",
        "basePath" : "/myproxy",
        "name" : "default",
        "revision" : "1"
      } ],
      "name" : "IdentificationTree"
    }
  }
} ]

Menggunakan mode DEBUG

Untuk membantu pemecahan masalah, Anda dapat mengaktifkan mode DEBUG untuk menyertakan informasi yang lebih mendetail dalam log pod apigee-runtime.

  1. Mencantumkan pod di namespace Anda: 
    kubectl get pods -n namespace
  2. Pilih salah satu pod apigee-runtime yang tercantum untuk di-debug.
  3. Jalankan perintah penerusan port untuk pod tersebut. Contoh: 
    kubectl port-forward -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd 8843
  4. Buka terminal lain dan panggil API berikut untuk mengaktifkan proses debug: 
    curl "https://0:8843/v1/logsessions?sessions=debug" -X POST -v -k
  5. Jalankan perintah kubectl logs untuk memeriksa log yang berada dalam Mode DEBUG. Misalnya: 
    kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd
  6. Setelah selesai memeriksa log DEBUG, reset tingkat log ke INFO (default). Contoh: 
    curl "https://0:8843/v1/logsessions?sessions=info" -X POST -v -k
  7. Jalankan perintah kubectl logs untuk memastikan log kembali dalam mode INFO.