Nginx sebagai Gerbang API: Buku Panduan Operasi Berorientasikan Prestasi

Senario

Anda menjalankan Nginx sebagai gerbang API dalam kluster Kubernetes, menghalakan trafik luaran kepada pelbagai mikroservis. Pada suatu hari, amaran pemantauan berbunyi: masa tindak balas API melonjak daripada purata 80ms kepada 800ms, dan sebahagian permintaan mula gagal dengan ralat 502 dan 504. Pasukan perniagaan melaporkan kemerosotan pengalaman pengguna yang serius, tetapi anda tidak tahu di mana punca kesesakan itu.

Simptom

• Kependaman API meningkat, terutamanya untuk panggilan rentas perkhidmatan.
• Tamat masa huluan, dengan upstream timed out atau no live upstreams muncul dalam log ralat Nginx.
• Penggunaan CPU proses pekerja Nginx menghampiri 100%.
• Sambungan mencapai had worker_connections, menyebabkan ralat accept failed.
• Pelanggan menerima kod status 503 atau 504.

Diagnostik

1. Periksa Status dan Log Nginx

Mula-mula, masuki pod Nginx dan periksa log ralat serta log akses:

kubectl exec -it <nginx-pod> -n <namespace> -- /bin/bash

tail -f /var/log/nginx/error.log
tail -f /var/log/nginx/access.log

Isyarat biasa dalam log ralat:

• worker_connections are not enough: kapasiti sambungan tidak mencukupi.
• upstream timed out (110: Connection timed out) while connecting to upstream: perkhidmatan huluan lambat atau tidak dapat dihubungi.
• recv() failed (104: Connection reset by peer): perkhidmatan huluan menutup sambungan secara aktif, selalunya kerana tamat masa atau ranap.

2. Gunakan Modul Status Terbina

Jika ngx_http_stub_status_module diaktifkan, anda boleh melihat sambungan aktif:

curl http://localhost:80/nginx_status

Contoh output:

Active connections: 291
server accepts handled requests
 16630948 16630948 31070465
Reading: 6 Writing: 179 Waiting: 106

• Reading dan Writing yang tinggi menunjukkan aliran permintaan sibuk; Waiting ialah sambungan keep-alive terbiar.
• Jika accepts dan handled berbeza dengan ketara, sambungan sedang digugurkan.

3. Analisis Kependaman Log Akses

Dayakan medan $request_time dan $upstream_response_time dalam format log untuk melihat pemasaan hiliran vs huluan:

tail -n 100 /var/log/nginx/access.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

Jika $request_time jauh lebih besar daripada $upstream_response_time, punca kesesakan ialah Nginx itu sendiri (cth., sambungan, had kadar, jabat tangan SSL). Jika hampir sama, perkhidmatan huluan adalah penyebabnya.

4. Periksa Kesihatan Huluan

Jika anda menggunakan blok upstream dengan semakan kesihatan, sahkan bahawa pelayan huluan berada dalam senarai tersedia:

kubectl get endpoints -n <namespace>
kubectl get pods -n <namespace> -o wide

Anda juga boleh menguji sambungan dari pod:

telnet <upstream-ip> <port>

Arahan dan Tindakan Segera

1. Laraskan Proses Pekerja dan Sambungan

Edit konfigurasi Nginx untuk meningkatkan worker_processes dan worker_connections:

events {
    worker_connections 4096;
}

error_log /var/log/nginx/error.log warn;
worker_rlimit_nofile 65535;

Kemudian muat semula:

nginx -t && nginx -s reload

2. Optimumkan Tamat Masa Huluan

Tetapkan had masa proksi yang sesuai dalam blok location atau server:

location /api/ {
    proxy_read_timeout 15s;
    proxy_connect_timeout 5s;
    proxy_send_timeout 15s;
}

Nota: Tamat masa terlalu pendek boleh membatalkan permintaan sebelum huluan selesai; terlalu lama boleh menahan sambungan dan menyebabkan kebocoran sumber.

3. Dayakan Caching Nginx

Cache respons yang jarang berubah:

proxy_cache_path /tmp/nginx_cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactivity=60m;

location /static/ {
    proxy_cache my_cache;
    proxy_cache_valid 200 60m;
    proxy_cache_valid 404 1m;
}

4. Had Kadar untuk Perlindungan

Gunakan limit_req untuk menyekat kadar permintaan dan elakkan lonjakan trafik mengejut daripada membebankan backend:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
}

5. Laraskan Parameter Kernel

Jika lonjakan sambungan terlalu ekstrem, anda mungkin perlu menyesuaikan parameter peringkat sistem, misalnya dalam arahan permulaan kontena:

sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.ip_local_port_range="1024 65535"

Kawalan Risiko

• Sentiasa sandarkan konfigurasi asal sebelum membuat perubahan.
• Gunakan nginx -t untuk mengesahkan sintaks konfigurasi.
• Untuk pengeluaran, amalkan pelepasan canary: muat semula pada satu instance dahulu, perhatikan, kemudian perluaskan.
• Apabila menukar tetapan kernel atau global, sahkan tiada kesan sampingan pada aplikasi lain.
• Elakkan menetapkan worker_connections terlalu tinggi pada waktu puncak untuk mengelakkan kehabisan memori.

Rollback

Jika perubahan memburukkan gangguan atau menghasilkan ralat baharu, segera undur:

# Pulihkan dari sandaran
cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf
nginx -t && nginx -s reload

Jika konfigurasi dipasang melalui ConfigMap, gunakan kubectl rollout untuk membuat asal:

kubectl rollout undo deployment/nginx-ingress -n <namespace>

Pengesahan

• Periksa error.log untuk ralat tamat masa atau sambungan yang baru.
• Jalankan ujian beban (cth., ab, wrk, k6) untuk membandingkan kependaman P95/P99 sebelum dan selepas perubahan.
• Pantau sambungan Nginx, CPU, memori, dan masa tindak balas huluan.
• Perhatikan sama ada sambungan Waiting dalam nginx_status kembali normal.

Bila Perlu Menghantar Tiket OpsGlobal

Hubungi pasukan SRE jarak jauh OpsGlobal dengan segera jika:

• Prestasi tidak bertambah baik selepas pelarasan dan punca akar masih tidak diketahui.
• Anda memerlukan pemantauan prestasi 24/7 dan amaran proaktif.
• Kluster berskala besar dan memerlukan pengoptimuman sistematik Nginx serta tindanan rangkaian Kubernetes.
• Organisasi anda tidak mempunyai kepakaran SRE dalaman dan isu ini menjejaskan ketersediaan pengeluaran.

OpsGlobal menyediakan sokongan operasi Nginx dan gerbang API profesional, termasuk pengoptimuman prestasi, diagnosis kerosakan, pengukuhan keselamatan, dan automasi, membantu anda mengurangkan MTTR dan meningkatkan kestabilan platform.