Operasi Prestasi Gerbang API Nginx: Panduan Lapangan

Senario

Pasukan anda mengendalikan gerbang API berasaskan Nginx dalam kluster Kubernetes. Pengguna mula melaporkan respons perlahan dan sekali-sekala ralat 504. Trafik tidak meningkat secara luar biasa, tetapi metrik kependaman jelas merosot. Anda perlu mendiagnosis dan menyelesaikan isu secara sistematik, kemudian memastikan ia tidak berulang.

Simptom

• Kependaman meningkat: Masa tindak balas persentil-99 melonjak daripada garis asas 200ms kepada melebihi 2 saat.
• Kadar ralat meningkat: Ralat 5xx meningkat, terutamanya 504 akibat tamat masa hulu.
• Kehabisan sumber: Proses pekerja Nginx menggunakan hampir 100% CPU, dan penggunaan memori meningkat.
• Aduan pengguna: Pelanggan luaran mengalami tamat masa, yang menjejaskan operasi perniagaan.

Diagnosis

Diagnosis berstruktur bermula dengan titik data yang paling mudah:

1. Log akses: Periksa log akses untuk mengenal pasti permintaan yang perlahan dan sama ada terdapat corak (cth., titik akhir tertentu, kumpulan pelanggan).
2. Log ralat: Periksa log ralat untuk petunjuk seperti "upstream timed out" atau "no live upstreams".
3. Metrik status Nginx: Jika modul stub_status atau vts diaktifkan, semak /status untuk bilangan sambungan, kadar permintaan, dsb.
4. Masa tindak balas hulu: Gunakan pemboleh ubah $upstream_response_time dalam format log untuk menentukan sama ada kesesakan ialah Nginx itu sendiri atau perkhidmatan belakang.
5. Audit konfigurasi: Periksa worker_processes, worker_connections, keepalive, proxy_timeout, dan parameter lain untuk melihat sama ada ia sepadan dengan beban.

Arahan

Dengan menganggap Pod gerbang dilabelkan app=gateway, arahan ini membantu anda menyiasat:

# Uji sintaks konfigurasi Nginx
kubectl exec -it <gateway-pod> -- nginx -t

# Lihat 100 baris log akses dan ralat terakhir
kubectl logs -l app=gateway --tail=100

# Paparkan modul dan argumen binaan
kubectl exec <gateway-pod> -- nginx -V

# Ukur masa permintaan
curl -s -o /dev/null -w "total: %{time_total} connect: %{time_connect} starttransfer: %{time_starttransfer}" http://gateway.example.com/api/health

# Semak penggunaan sumber setiap pod
kubectl top pod <gateway-pod>

# Dapatkan shell dan periksa fail konfigurasi
kubectl exec -it <gateway-pod> -- /bin/bash
cat /etc/nginx/nginx.conf
cat /etc/nginx/conf.d/*.conf

Untuk isu yang lebih mendalam, anda boleh menjejak panggilan sistem buat sementara dengan strace:

kubectl exec <gateway-pod> -- strace -p $(pgrep nginx worker) -c -f

Amaran: strace menambah beban dan hanya boleh digunakan apabila perlu.

Kawalan Risiko

Apabila membuat perubahan, ikuti peraturan keselamatan ini:

1. Sandaran konfigurasi: Sebelum sebarang suntingan, simpan konfigurasi Nginx semasa ke ConfigMap atau Git.
2. Muat semula secara sopan: Gunakan nginx -s reload atau hantar isyarat HUP kepada proses induk daripada memulakan semula kontena, untuk mengelakkan pemutusan sambungan.
3. Langkah kecil: Tukar satu parameter pada satu masa dan sahkan kesannya. Contohnya, mula dengan melaraskan proxy_read_timeout, kemudian perhatikan metrik.
4. Pelepasan canary: Jika menggunakan Deployment, gunakan konfigurasi baharu pada satu replika sahaja dan alihkan sebahagian kecil trafik untuk pengesahan.
5. Had kadar dan pemutus litar: Jika perkhidmatan hulu terbeban, aktifkan had kadar atau pemutus litar di gerbang untuk melindungi sumber hiliran.

Pemulihan

Jika perubahan memburukkan keadaan, patah balik dengan segera:

# Jika konfigurasi dipasang melalui ConfigMap, pulihkan versi sebelumnya
kubectl rollout undo deployment/gateway

# Atau pulihkan fail konfigurasi secara manual dan muat semula dengan sopan
kubectl cp <backup-config> <gateway-pod>:/etc/nginx/nginx.conf
kubectl exec <gateway-pod> -- nginx -s reload

Selepas patah balik, teruskan pemantauan untuk memastikan isu selesai.

Pengesahan

Selepas pelarasan, sahkan hasil yang diingini:

1. Metrik: Pastikan kependaman persentil-99, kadar ralat, dan penggunaan CPU kembali ke julat yang boleh diterima.
2. Ujian beban: Jalankan ujian beban sintetik di persekitaran staging menggunakan ab atau hey: bash hey -n 10000 -c 100 -H "Host: api.example.com" http://gateway.internal/api
3. Semakan log: Pastikan log akses tidak lagi menunjukkan tamat masa hulu yang berlebihan, dan log ralat bersih.
4. Kelulusan perniagaan: Minta pasukan perniagaan mengesahkan titik akhir kritikal dengan akaun ujian.

Bila Perlu Hantar Tiket OpsGlobal

Pertimbangkan untuk meningkatkan kepada OpsGlobal jika mana-mana keadaan ini berlaku:

• Punca kompleks: Isu melibatkan penalaan kernel, timbunan rangkaian, penyelesaian DNS, prestasi TLS, atau bidang lain yang memerlukan kepakaran peringkat sistem.
• Banyak mikroservis: Gerbang berada di hadapan banyak perkhidmatan hulu teragih, dan analisis rantaian panggilan penuh diperlukan.
• Kustomisasi Nginx mendalam: Konfigurasi melibatkan skrip Lua, penalaan modul pihak ketiga, atau bendera kompilasi yang memerlukan semakan pakar.
• Kemerosotan berterusan: Walaupun usaha konvensional terbaik anda, kependaman dan kadar ralat terus meningkat—selalunya tanda beberapa faktor berinteraksi.

Pakar SRE OpsGlobal boleh mengendalikan segala-galanya daripada penalaan parameter kernel dan reka bentuk afiniti nod kepada penyepaduan jejaring perkhidmatan, tetapi penyiasatan awal yang teratur sentiasa mempercepatkan penyelesaian.

Ingat, intervensi operasi yang berkesan bergantung pada proses yang jelas, tindakan berhemah, dan peningkatan tepat pada masanya.