Operasi Nginx dan Middleware Gerbang API: Buku Panduan Prestasi Praktikal

Senario

Sebuah penggunaan mikrosentuh biasa menggunakan Nginx sebagai proksi terbalik dan penamat TLS, di hadapan middleware gerbang API bersepadu (contohnya, Kong, berdasarkan OpenResty/Nginx) yang mengendalikan pengesahan, had kadar, dan penghalaan permintaan. Dalam masa sebulan selepas lonjakan trafik, pasukan operasi melihat masa tindak balas purata meningkat daripada 120 ms kepada 800 ms, dan latensi p99 melebihi 2 saat. Sebilangan pengguna mula menerima ralat 504 Gateway Timeout. Penggunaan CPU gerbang mencapai 95% secara berkala, dan log aplikasi upstream menunjukkan peningkatan reset sambungan. Sistem tidak turun sepenuhnya, tetapi pengalaman pengguna merosot dengan pantas.

Gejala

• Latensi tinggi (p99 > 2s) dan tamat masa yang kerap
• Kehabisan CPU pada nod Nginx/gerbang
• Peningkatan ralat 5xx, terutamanya 502/504
• Sambungan upstream terputus
• Log ralat dipenuhi dengan "worker_connections are not enough" dan "upstream timed out"

Diagnosis

Mulakan dengan urutan semula jadi: semak metrik sistem, status Nginx, log, kemudian mendalami dengan ujian beban.

1. Sahkan sumber sistem: Gunakan top, vmstat, dan mpstat untuk melihat CPU, memori, dan I/O. Masa sy yang tinggi menunjukkan panggilan kernel/sistem, sering disebabkan oleh pertukaran konteks yang berlebihan.
2. Periksa sambungan pekerja Nginx: ngx_http_stub_status_module mendedahkan pembilang asas. Aktifkan dalam blok lokasi dan curl: location /nginx_status { stub_status; allow 127.0.0.1; deny all; } Kemudian curl http://127.0.0.1/nginx_status. Lihat "Active connections" dan "Waiting" vs "Writing".
3. Periksa log ralat Nginx: tail -n 100 /var/log/nginx/error.log. Mesej biasa: - "upstream timed out (110: Connection timed out)" — semak proxy_read_timeout. - "no live upstreams" — semak pemeriksaan kesihatan pelayan upstream. - "worker_connections are not enough" — tingkatkan worker_connections atau kurangkan sambungan keepalive.
4. Periksa log middleware gerbang API (contohnya, error.log Kong). Untuk Kong, anda juga boleh menanyakan titik akhir /status untuk status kluster.
5. Analisis format log akses Nginx dengan masa tindak balas. Jika anda menggunakan pembolehubah $request_time, anda boleh melihat permintaan perlahan secara langsung. Contoh: tail -f /var/log/nginx/access.log | awk '{print $NF}' jika masa adalah medan terakhir.
6. Lakukan ujian beban terkawal menggunakan wrk atau ab pada titik akhir ujian untuk mengasingkan sama ada kesesakan berlaku di Nginx atau middleware gerbang: wrk -t4 -c100 -d30s http://your-gateway/health Bandingkan dengan akses langsung ke aplikasi upstream untuk melihat perbezaannya.

Arahan dan Tindakan Segera

Berikut adalah arahan praktikal untuk mengumpul data tambahan dan memulakan pembaikan, dengan nota keselamatan.

• Sahkan konfigurasi sebelum memuat semula: nginx -t -c /etc/nginx/nginx.conf (mesti dijalankan sebagai root atau dengan kebenaran yang sesuai).
• Muat semula Nginx secara berhemah untuk menggunakan perubahan: nginx -s reload (berfungsi jika anda mempunyai kebenaran; dalam systemd, systemctl reload nginx).
• Naikkan worker_connections buat sementara dalam blok events jika anda melihat "worker_connections are not enough". Ini memerlukan muat semula, dan ia selamat selagi deskriptor fail mencukupi (ulimit -n).
• Optimal keepalive ke upstream: Dalam blok upstream Nginx, pastikan keepalive 32; dan dalam blok location, tetapkan proxy_http_version 1.1; dan proxy_set_header Connection ""; untuk menggunakan semula sambungan upstream. Ini dapat mengurangkan memori dan CPU dengan ketara.
• Untuk tamat masa upstream, laraskan proxy_connect_timeout, proxy_send_timeout, proxy_read_timeout kepada nilai munasabah (contohnya, 5s, 10s, 60s). Jangan tetapkan terlalu tinggi kerana ia akan mengikat sambungan pekerja.
• Untuk middleware gerbang API (andaikan Kong), gunakan admin API untuk memeriksa plugin prestasi. Jika had kadar diaktifkan, semak pembilang untuk memastikan had tidak menyebabkan pendikit.
• Gunakan strace -p <nginx_pid> -f -e trace=network selama beberapa saat untuk melihat sama ada panggilan sistem menyekat (hanya jika anda selesa; ia boleh menyebabkan overhead).
• Periksa deskriptor fail terbuka: lsof -p $(pidof nginx) | wc -l untuk melihat sama ada proses pekerja mencapai had.

Kawalan risiko: Sebarang perubahan hendaklah digunakan pada satu nod terlebih dahulu (jika terdapat pengimbang beban di hadapan). Simpan sandaran konfigurasi semasa: cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak. Gunakan canary dengan mengalihkan trafik secara perlahan menggunakan berat dalam blok upstream. Jika anda mengubah suai plugin dalam gerbang API, lakukan melalui admin API dan uji dalam persekitaran pementasan.

Rollback

Jika pelarasan membawa kepada tingkah laku atau ralat yang lebih buruk, kembalikan serta-merta.

• Untuk perubahan konfigurasi Nginx, gantikan konfigurasi dengan fail .bak dan jalankan nginx -t kemudian nginx -s reload. Ini adalah rollback yang berhemah yang tidak menggugurkan sambungan aktif.
• Untuk perubahan plugin gerbang API, anda boleh melumpuhkan plugin melalui admin API atau kembali ke konfigurasi deklaratif sebelumnya (jika menggunakan mod deklaratif).
• Sentiasa ada pelan rollback untuk perubahan sijil (contohnya, sesi TLS). Muat semula dengan konfigurasi buruk akan ditangkap oleh nginx -t.

Pengesahan

Selepas menggunakan perubahan, sahkan bahawa masalah diselesaikan.

• Pantau metrik utama: nilai nginx_status (Sambungan Aktif harus stabil), masa tindak balas dalam log akses ($request_time), dan kadar ralat.
• Jalankan ujian beban sekali lagi dengan parameter yang sama seperti sebelumnya. Bandingkan p99 dan kadar ralat.
• Gunakan alat papan pemuka seperti Grafana dan Prometheus jika ada untuk menggambarkan perubahan.
• Semak curl -v https://your-api/endpoint untuk memastikan jabat tangan TLS lancar dan tiada latensi tambahan.

Bila Menghantar Tiket OpsGlobal

Jika anda masih melihat penggunaan CPU tinggi selepas melaraskan worker_connections, keepalive, dan tamat masa, atau jika middleware gerbang itu sendiri menjadi kesesakan (contohnya, kolam sambungan pangkalan data Kong, Lua JIT, atau plugin tersuai), sudah tiba masanya untuk membawa pakar. OpsGlobal boleh melakukan penyiasatan mendalam dengan alat penjejakan seperti eBPF/perf, menganalisis dalaman Nginx dan gerbang, dan melaksanakan strategi prestasi lanjutan seperti pengurusan upstream dinamik, pengoptimuman konfigurasi, dan penalaan kernel. Jika isu itu menjejaskan ketersediaan pengeluaran, hantar tiket segera untuk meminimumkan masa henti.