Panduan pemecahan masalah pemroses pesan

Topik ini membahas langkah-langkah yang dapat Anda ambil untuk memecahkan dan memperbaiki masalah dengan pemroses pesan. Pesan adalah bagian dari Komponen apigee-runtime. Lihat juga Ringkasan konfigurasi layanan runtime.

Pemeriksaan kesiapan gagal dengan status HTTP kode 500

Gejala

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

Pesan error

Ketika menggunakan kubectl untuk mendeskripsikan pod apigee-runtime yang gagal, Anda akan melihat {i>error<i}:

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 menunjukkan bahwa tidak ada kontrak aktif yang tersedia bagi pemroses pesan untuk menyalurkan kemacetan. Dalam status ini, pemroses pesan tidak dapat menyebut dirinya "siap".

Penyebab Deskripsi
Masalah koneksi bidang pengelolaan yang disinkronkan Sinkronisasi tidak dapat terhubung ke bidang pengelolaan. Masalah ini biasanya terjadi saat Anda mengganti URL contractProvider dan mengaitkan akun layanan yang salah. Misalnya, jika Anda mengonfigurasi akun layanan untuk deployment staging dengan URL contractProvider yang mengarah ke server produksi.
Masalah koneksi prosesor pesan ke sinkronisasi Jika MP baru muncul sebagai bagian dari penskalaan otomatis atau pod dimulai ulang, Anda mungkin melihat error ini. Umumnya, masalah ini terjadi ketika sinkronisasi mati dan MP tidak dapat memuat kontrak-nya.

Diagnosis: Menyinkronkan ke pengelolaan masalah koneksi pesawat

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

  1. Lihat daftar pod di cluster: 
    kubectl get pods -n namespace
  2. Buka shell dalam 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 /application/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 angka Dalam contoh di atas (juga ditampilkan di bawah), nama folder adalah 750; Oleh karena itu, kecocokan: 
    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 ketidakcocokan versi seperti yang dijelaskan di atas, periksa log sinkronisasi untuk mencoba menentukan penyebab sebagian besar kontrak saat ini tidak didownload. Contoh:

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

Untuk mengetahui informasi tentang cara menafsirkan log sinkronisasi, lihat syncr logs. Jika sinkronisasi tidak aktif, 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 pemroses pesan ke sinkronisasi, lakukan langkah berikut:

  1. Lihat daftar pod di cluster: 
    kubectl get pods -n namespace
  2. Periksa log runtime untuk mencoba mencari tahu penyebab kontrak tidak sedang diunduh: 
    kubectl logs -f -n namespace pod-name

    Contoh:

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

    Dimungkinkan jika MP baru muncul sebagai bagian dari autoscale atau pod restart, MP mungkin tidak memuat kontrak. Umumnya, masalah terjadi ketika sedang nonaktif, 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 untuk kunci enkripsi yang tidak valid

Gejala

Pod apigee-runtime tidak dalam status Siap.

Diagnosis

Ketika 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 yang dienkode dengan base64. Untuk informasi selengkapnya tentang cara membuat kunci dengan format yang 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 membuat panggilan proxy API secara langsung dari di dalam pod apigee-runtime, sehingga mengabaikan gateway masuk.

  1. Jalankan perintah berikut untuk meneruskan ke port 8443. Hal ini memungkinkan Anda memanggil API dalam pod: 
    kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
  2. Memanggil proxy API yang di-deploy. Misalnya, dengan 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 API pengelolaan

Anda dapat menggunakan API yang dijelaskan di bawah untuk memeriksa apakah API pengelolaan berfungsi dengan benar.

  1. Dapatkan nama pod di cluster Anda: 
    kubectl get pods -n namespace
  2. Menggunakan penerusan port untuk mendapatkan akses pod apigee-runtime. Sintaksis untuk penerusan port 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 ditampilkan dalam contoh berikut: 
    curl -k https://0:8843/v1/classification/tree

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

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

Menggunakan logging untuk men-debug masalah pod runtime

Untuk membantu pemecahan masalah, Anda dapat membuat sesi log untuk menghasilkan output log yang mendetail untuk pod apigee-runtime.

Membuat sesi log

Untuk membuat sesi log untuk pod runtime:

  1. Mencantumkan pod runtime. Secara default, keduanya berada di namespace apigee. Jika Anda memilih namespace lain, gunakan itu sebagai gantinya: 
    kubectl get pods -n apigee
  2. Pilih salah satu pod apigee-runtime yang tercantum untuk di-debug.
  3. Membuat sesi log di pod runtime yang ingin Anda pecahkan masalahnya menggunakan API /logsessions. Untuk mengetahui detail tentang API, lihat Tentang logsessions API: 
    kubectl exec -it RUNTIME_POD_NAME -n apigee \
  -- curl "https://0:8843/v1/logsessions?loggerNames=ALL&level=FINE&timeout=60000" -k -X POST -v

    Contoh:

    kubectl exec -it apigee-runtime-hybrid-18-01232-dev-d27ca57-190rc6-3klyg-lc7h5 -n apigee \
  -- curl "https://0:8843/v1/logsessions?loggerNames=ALL&level=FINE&timeout=60000" -k -X POST -v

    Responsnya adalah ID sesi log. Contoh: 9f831a7d-e533-4ead-8e58-12ec1059a622

  4. Cetak log: 
    kubectl logs -f -n apigee RUNTIME_POD_NAME

Membuat daftar sesi log

Untuk mendapatkan daftar semua sesi log aktif untuk pod runtime:

kubectl exec -it RUNTIME_POD_NAME -n apigee \
  -- curl "https://0:8843/v1/logsessions" -k -v

Mendapatkan sesi log

Untuk mendapatkan detail sesi log:

kubectl exec -it RUNTIME_POD_NAME -n apigee \
  -- curl "https://0:8843/v1/logsessions/LOG_SESSION_ID" -k -v

Mengakhiri sesi log

Untuk mengakhiri sesi log:

kubectl exec -it RUNTIME_POD_NAME -n apigee \
    -- curl "https://0:8843/v1/logsessions/LOG_SESSION_ID" -k -X DELETE -v

Tentang logsessions API

Bagian ini menjelaskan parameter kueri logsessions API:

  • loggerNames: Menentukan jenis output log yang akan ditampilkan. Nilai yang mungkin menyertakan CONTRACT_REPLICATION, DEBUG.SESSION, atau ALL
  • level: Menentukan tingkat output log. Nilai yang memungkinkan mencakup FINEST, FINER, FINE, INFO, SEVERE, ALL.
  • timeout: Menentukan durasi sesi log akan beroperasi selama level log yang ditentukan. Setelah waktu tunggu habis, level log akan kembali ke INFO.

Jika berhasil, API akan menampilkan ID sesi untuk sesi log tersebut.