Menyiapkan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global

Dokumen ini menunjukkan contoh penggunaan pengelolaan traffic untuk beberapa kasus penggunaan tertentu. Banyak kasus penggunaan lainnya yang mungkin terjadi.

Dokumen ini berisi contoh untuk Load Balancer Aplikasi eksternal global. Load Balancer Aplikasi eksternal global menggunakan skema load balancing EXTERNAL_MANAGED dan komponen load balancing global, seperti aturan penerusan, peta URL, dan layanan backend.

Untuk mengetahui informasi tentang pengelolaan traffic dengan Load Balancer Aplikasi klasik, lihat Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi klasik.

Untuk mengetahui informasi tentang pengelolaan traffic dengan Load Balancer Aplikasi eksternal regional, lihat Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal regional.

Selain fitur perutean lanjutan yang dijelaskan di halaman ini, Load Balancer Aplikasi yang didukung terintegrasi dengan Ekstensi Layanan untuk memungkinkan Anda menyisipkan logika kustom ke dalam jalur data load balancing.

Sebelum memulai

Pastikan Anda memahami cara kerja pengelolaan traffic. Untuk mengetahui informasi selengkapnya, baca Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global.

Mengonfigurasi dan menguji pengelolaan traffic

Dalam lingkungan konfigurasi yang Anda pilih, Anda menyiapkan pengelolaan traffic dengan menggunakan konfigurasi YAML. Peta URL dan layanan backend masing-masing memiliki file YAML-nya sendiri. Bergantung pada fitur yang dipilih, Anda perlu menulis file YAML peta URL, file YAML layanan backend, atau keduanya.

Untuk mendapatkan bantuan dalam menulis file YAML ini, Anda dapat menggunakan contoh di halaman ini dan dokumentasi Cloud Load Balancing API.

Konsol Google Cloud tidak didukung.

Dokumentasi global URL map API dan global backend service API memberikan daftar lengkap kolom, termasuk semantik terkait hubungan, batasan, dan kardinalitas.

Anda dapat menambahkan pengujian konfigurasi ke peta URL untuk memastikan peta URL merutekan permintaan sesuai yang diinginkan. Anda dapat bereksperimen dengan aturan peta URL yang berbeda dan menjalankan sebanyak mungkin pengujian yang diperlukan untuk memastikan bahwa peta tersebut merutekan traffic ke layanan backend atau bucket backend yang sesuai. Untuk mengetahui detailnya, lihat Menambahkan pengujian ke peta URL. Jika Anda ingin menguji perubahan baru pada peta URL tanpa benar-benar men-deploy peta, lihat Memvalidasi konfigurasi peta URL.

Memetakan traffic ke satu layanan

Kirim semua traffic ke satu layanan. Pastikan untuk mengganti placeholder.

    defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: /PREFIX
        priority: PRIORITY  # 0 is highest
        routeAction:
          weightedBackendServices:
          - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
            weight: 100

Membagi traffic di antara dua layanan

Membagi traffic antara dua layanan atau di antara beberapa layanan. Pastikan Anda mengganti placeholder.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
           weight: 5

Mengonfigurasi pengalihan URL

Contoh berikut menampilkan kode respons 301 MOVED_PERMANENTLY_DEFAULT yang dapat dikonfigurasi. Contoh ini juga menetapkan header respons Location dengan URI yang sesuai, menggantikan host dan jalur seperti yang ditentukan dalam tindakan pengalihan.

Untuk membuat pengalihan untuk bucket backend, gunakan projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET untuk kolom defaultService.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: <var>URL_MAP_NAME</var>
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     defaultUrlRedirect:
       hostRedirect: "HOST TO REDIRECT TO" # Omit to keep the requested host
       pathRedirect: "PATH TO REDIRECT TO" # Omit to keep the requested path
       redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
       stripQuery: True

Duplikasi traffic

Selain meneruskan permintaan ke layanan backend yang dipilih, Anda dapat mengirim permintaan yang identik ke layanan backend mirror yang dikonfigurasi berdasarkan fire and forget. Artinya, load balancer tidak menunggu respons dari backend yang menerima permintaan yang dicerminkan. Duplikasi permintaan berguna untuk menguji versi baru layanan backend. Anda juga dapat menggunakannya untuk men-debug error produksi pada versi debug layanan backend, bukan pada versi produksi.

Secara default, layanan backend yang di-mirror menerima semua permintaan, meskipun traffic asli dibagi di antara beberapa layanan backend berbobot. Anda dapat mengonfigurasi layanan backend yang di-mirror untuk menerima hanya persentase permintaan dengan menggunakan tanda mirrorPercent opsional untuk menentukan persentase permintaan yang akan di-mirror yang dinyatakan sebagai nilai antara 0 dan 100,0. Pencerminan permintaan berbasis persentase berada dalam Pratinjau.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
             mirrorPercent: 50.0

Jika Anda memiliki beberapa layanan backend berbobot dan ingin mencatat layanan backend mana yang digunakan untuk melayani permintaan asli, Anda dapat menambahkan header kustom yang menyertakan informasi ini ke semua permintaan. Contoh berikut menambahkan header kustom bernama x-weighted-picked-backend ke semua permintaan klien. Untuk nilai header, gunakan nama layanan backend yang menayangkan permintaan asli.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
              weight: 95
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_1
                  replace: True
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
              weight: 5
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_2
                  replace: True
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_3

Perhatikan batasan berikut saat menggunakan pencerminan traffic:

• Duplikasi traffic didukung saat kedua layanan backend memiliki backend grup instance terkelola, NEG zona, atau NEG hybrid. Fitur ini tidak didukung untuk NEG internet, NEG serverless, dan backend Private Service Connect.
• Permintaan ke layanan backend yang di-mirror tidak menghasilkan log atau metrik apa pun untuk Cloud Logging dan Cloud Monitoring.

Menulis ulang URL yang diminta

Tulis ulang bagian nama host URL, bagian jalur URL, atau keduanya, sebelum mengirim permintaan ke layanan backend yang dipilih. Pastikan untuk mengganti placeholder.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           urlRewrite:
             hostRewrite: "new-host-name.com" # Omit to keep the requested host
             pathPrefixRewrite: "/new-path/" # Omit to keep the requested path

Mencoba lagi permintaan

Konfigurasi kondisi saat load balancer mencoba ulang permintaan yang gagal, berapa lama load balancer menunggu sebelum mencoba ulang, dan jumlah maksimum percobaan ulang yang diizinkan.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

Menentukan waktu tunggu rute

Tentukan waktu tunggu untuk rute yang dipilih. Waktu tunggu dihitung dari saat permintaan diproses sepenuhnya hingga respons diproses sepenuhnya. Waktu tunggu mencakup semua percobaan ulang. Pastikan untuk mengganti placeholder.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 0

Mengonfigurasi injeksi kesalahan

Memunculkan error saat melayani permintaan untuk menyimulasikan kegagalan, termasuk latensi tinggi, kelebihan beban layanan, kegagalan layanan, dan partisi jaringan. Fitur ini berguna untuk menguji ketahanan layanan terhadap kesalahan yang disimulasikan.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           faultInjectionPolicy:
             delay:
               fixedDelay:
                 seconds: 10
                 nanos: 0
               percentage: 25
             abort:
               httpStatus: 503
               percentage: 50

Mengonfigurasi CORS

Konfigurasi kebijakan cross-origin resource sharing (CORS) untuk mengontrol cara load balancer Anda menangani permintaan lintas origin.

Kebijakan CORS diterapkan di tingkat pencocok jalur

Dalam konfigurasi ini, kebijakan CORS ditentukan dalam defaultRouteAction dari pencocok jalur (pathMatchers[].defaultRouteAction.corsPolicy). Artinya, kebijakan diterapkan ke semua permintaan yang dirutekan melalui pencocok jalur default, terlepas dari jalur atau rute tertentu.

Pendekatan ini cocok jika Anda menginginkan satu kebijakan CORS yang konsisten untuk semua rute yang dikelola oleh pencocok jalur.

defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
  - '*'
  pathMatcher: path-matcher-1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
  name: path-matcher-1
- defaultRouteAction:
    corsPolicy:
      allowCredentials: true
      allowOrigins: [ "http://example.com" ]
      allowMethods: [ "GET", "POST" ]
      allowHeaders: [ "Authorization", "Content-Type" ]

Cara kerjanya

• Load balancer menerapkan kebijakan CORS untuk semua permintaan yang ditangani oleh pencocok jalur.
• Hanya permintaan dari host example.com menggunakan metode GET atau POST, dan dengan header yang diizinkan (Authorization, Content-Type), yang diizinkan.
• Kredensial (seperti cookie atau header otorisasi) diizinkan dalam permintaan lintas origin.
• Layanan backend hanya menerima permintaan yang mematuhi kebijakan CORS ini.

Kebijakan CORS diterapkan di tingkat aturan rute

Dalam konfigurasi ini, kebijakan CORS ditentukan dalam routeAction untuk aturan rute tertentu (pathMatchers[].routeRules[].routeAction.corsPolicy). Dengan demikian, Anda dapat menerapkan kebijakan CORS yang berbeda ke rute atau prefiks jalur yang berbeda.

Pendekatan ini cocok jika Anda memerlukan kontrol mendetail, seperti menerapkan kebijakan CORS yang berbeda ke berbagai endpoint atau jalur API.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: [ "http://example.com" ]
               allowMethods: [ "GET", "POST" ]
               allowHeaders: [ "Authorization", "Content-Type" ]
               maxAge: 1200
               allowCredentials: true

Cara kerjanya

• Kebijakan CORS hanya diterapkan untuk permintaan yang cocok dengan awalan jalur yang ditentukan (misalnya, /PREFIX).
• Hanya permintaan dari host example.com menggunakan metode GET atau POST, dan dengan header yang diizinkan, yang diizinkan untuk rute ini.
• Kolom maxAge menentukan durasi hasil permintaan preflight dapat di-cache oleh browser (dalam detik).
• Kredensial diizinkan dalam permintaan lintas origin.
• Rute lain dapat memiliki kebijakan CORS yang berbeda atau tidak sama sekali.

Anda juga dapat menentukan kebijakan CORS di tingkat peta URL berikut:

• defaultRouteAction.corsPolicy
• pathMatchers[].pathRules[].routeAction.corsPolicy

Menambahkan dan menghapus header permintaan dan respons

Menambahkan dan menghapus header permintaan sebelum mengirim permintaan ke layanan backend. Selain itu, tambahkan dan hapus header respons setelah menerima respons dari layanan backend.

Ada batasan pada nilai yang valid untuk headerName dan headerValue. Untuk mengetahui detailnya, lihat Cara kerja header kustom.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               headerAction:
                 requestHeadersToAdd:
                 - headerName: header-1-name
                   headerValue: header-1-value
                   replace: True
                 requestHeadersToRemove:
                 - header-2-name
                 - header-3-name
                 responseHeadersToAdd:
                 - headerName: header-4-name
                   headerValue: header-4-value
                   replace: True
                responseHeadersToRemove:
                - header-5-name
                - header-6-name

Mengonfigurasi deteksi outlier

Tentukan kriteria untuk penghentian paksa VM atau endpoint backend yang tidak responsif di NEG, beserta kriteria yang menentukan kapan backend atau endpoint dianggap cukup responsif untuk menerima traffic lagi. Pastikan untuk mengganti placeholder.

    loadBalancingScheme: EXTERNAL_MANAGED
    localityLbPolicy: RANDOM
    name: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
    outlierDetection:
      baseEjectionTime:
        nanos: 0
        seconds: 30
      consecutiveErrors: 5
      consecutiveGatewayFailure: 3
      enforcingConsecutiveErrors: 2
      enforcingConsecutiveGatewayFailure: 100
      enforcingSuccessRate: 100
      interval:
        nanos: 0
        seconds: 1
      maxEjectionPercent: 50
      successRateMinimumHosts: 5
      successRateRequestVolume: 100
      successRateStdevFactor: 1900

Menyiapkan pemisahan traffic: langkah-langkah mendetail

Contoh ini menunjukkan langkah-langkah berikut:

1. Buat template yang berbeda untuk layanan yang berbeda.

2. Buat grup instance untuk template tersebut.

3. Buat aturan pemilihan rute yang menyiapkan pemisahan traffic 95% / 5%.

4. Kirim perintah curl yang menunjukkan bahwa persentase pemisahan traffic kira-kira cocok dengan konfigurasi.

Petunjuk ini mengasumsikan hal berikut:

• Proxy target dan aturan penerusan telah dibuat, beserta peta URL bernama global-lb-map.

• Peta URL mengirimkan semua traffic ke satu layanan backend, yang disebut red-service, yang merupakan layanan backend default.

• Anda menyiapkan jalur alternatif yang mengirimkan 5% traffic ke blue-service dan 95% traffic ke green-service.

• Pencocok jalur digunakan.

• Anda menggunakan Cloud Shell atau lingkungan lain dengan bash yang terinstal.

Tentukan layanan

Fungsi bash berikut membuat layanan backend, termasuk template instance dan grup instance terkelola.

Petunjuk ini mengasumsikan bahwa health check HTTP (global-lb-basic-check) telah dibuat. Untuk mengetahui petunjuknya, lihat salah satu halaman berikut:

• Menyiapkan Load Balancer Aplikasi eksternal global dengan backend Compute Engine
• Menyiapkan Load Balancer Aplikasi eksternal global dengan bucket backend
• Menyiapkan Load Balancer Aplikasi eksternal global dengan konektivitas hybrid
• Menyiapkan Load Balancer Aplikasi eksternal global dengan Cloud Run, App Engine, atau Cloud Run Functions

function make_service() {
  local name="$1"
  local region="$2"
  local zone="$3"
  local network="$4"
  local subnet="$5"
  local subdir="$6"

  www_dir="/var/www/html/$subdir"

  (set -x; \
  gcloud compute instance-templates create "${name}-template" \
    --region="$region" \
    --network="$network" \
    --subnet="$subnet" \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  apt-get update
  apt-get install apache2 -y
  a2ensite default-ssl
  a2enmod ssl
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee ${www_dir}index.html
  systemctl restart apache2"; \
  gcloud compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud compute backend-services create "${name}-service" \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=global-lb-basic-check \
    --global \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --global)
}

Buat layanan

Panggil fungsi untuk membuat tiga layanan, red, green, dan blue. Layanan red bertindak sebagai layanan default untuk permintaan ke /. Layanan green dan blue disiapkan di /prefix untuk menangani 95% dan 5% traffic, masing-masing.

make_service red us-west1 us-west1-a lb-network backend-subnet ""
make_service green us-west1 us-west1-a lb-network backend-subnet /prefix
make_service blue us-west1 us-west1-a lb-network backend-subnet /prefix

Buat peta URL

Menguji konfigurasi

Untuk menguji konfigurasi, pastikan terlebih dahulu bahwa permintaan ke alamat IP load balancer yang disiapkan sebelumnya ditangani oleh konfigurasi red default.

Kemudian, periksa untuk memastikan bahwa permintaan yang dikirim ke FORWARDING_RULE_IP_ADDRESS/prefix dibagi seperti yang diharapkan.

Menyiapkan afinitas sesi berdasarkan HTTP_COOKIE

Kontrol traffic memungkinkan Anda mengonfigurasi afinitas sesi berdasarkan cookie yang diberikan. Untuk mengonfigurasi afinitas sesi berbasis HTTP_COOKIE untuk layanan backend bernama red-service, ikuti petunjuk berikut.

1. Gunakan perintah gcloud compute backend_services export untuk mendapatkan konfigurasi layanan backend.

   gcloud compute backend-services export red-service \
       --destination=red-service-config.yaml \
       --global
   

2. Perbarui file red-service-config.yaml sebagai berikut:

   sessionAffinity: 'HTTP_COOKIE'
   localityLbPolicy: 'RING_HASH'
   consistentHash:
    httpCookie:
     name: 'http_cookie'
     path: '/cookie_path'
     ttl:
       seconds: 100
       nanos: 0
    minimumRingSize: 10000
   

3. Di file red-service-config.yaml, hapus baris berikut:

   sessionAffinity: NONE
   

4. Perbarui file konfigurasi layanan backend:

   gcloud compute backend-services import red-service \
       --source=red-service-config.yaml \
       --global
   

Pemecahan masalah

Gunakan informasi ini untuk memecahkan masalah saat traffic tidak dirutekan sesuai dengan aturan rute dan kebijakan traffic yang Anda konfigurasi.

Untuk mengetahui informasi tentang logging dan pemantauan, lihat Logging dan pemantauan HTTP(S) eksternal.

Gejala:

• Peningkatan traffic ke layanan dalam aturan di atas aturan yang dimaksud.
• Peningkatan respons HTTP 4xx dan 5xx yang tidak terduga untuk aturan rute tertentu.

Solusi: Periksa urutan aturan rute Anda. Aturan rute ditafsirkan sesuai urutan penentuannya.

Aturan rute dalam peta URL ditafsirkan sesuai urutan penentuannya. Hal ini berbeda dengan cara aturan jalur ditafsirkan oleh pencocokan awalan terpanjang. Untuk aturan jalur, Load Balancer Aplikasi eksternal global hanya memilih satu aturan jalur; namun, saat Anda menggunakan aturan rute, lebih dari satu aturan dapat berlaku.

Saat Anda menentukan aturan rute, pastikan aturan di bagian atas daftar tidak secara tidak sengaja merutekan traffic yang seharusnya dirutekan oleh aturan rute berikutnya. Layanan yang menerima traffic yang salah arah kemungkinan akan menolak permintaan, dan layanan dalam aturan rute Anda akan menerima lebih sedikit traffic atau tidak menerima traffic sama sekali.

Langkah berikutnya

• Bersihkan penyiapan load balancer.