Cara Analisis Log Nginx untuk Mencari Penyebab Website Lambat

Website terasa lambat, pengguna mengeluh, tapi grafik CPU di panel VPS terlihat biasa saja. Situasi ini sering terjadi, dan jawabannya hampir selalu ada di file yang jarang dibuka: access log Nginx. Setiap request tercatat di sana, lengkap dengan URL, IP, status, dan user agent. Yang kurang biasanya satu hal, yaitu berapa lama request itu diproses.

Semua perintah di bawah ini jalan di server Linux biasa tanpa memasang apa pun. Lokasi log bawaan di Ubuntu dan Debian ada di /var/log/nginx/access.log.

Tambahkan request_time ke format log

Format log bawaan Nginx (combined) tidak mencatat durasi. Tanpa durasi, kamu hanya bisa menebak halaman mana yang lambat. Tambahkan format baru di blok http pada konfigurasi Nginx, isinya format combined ditambah `$request_time` dan `$upstream_response_time` di bagian paling akhir, lalu arahkan `access_log` ke format itu.

Bedanya penting. `$request_time` adalah total waktu dari Nginx menerima request sampai selesai mengirim respons, termasuk lambatnya koneksi pengguna. `$upstream_response_time` adalah waktu yang dipakai backend, misalnya PHP-FPM atau aplikasi Node.js. Kalau upstream kecil tapi request_time besar, masalahnya di jaringan atau ukuran file. Kalau keduanya besar, masalahnya di aplikasi atau database.

Setelah mengubah konfigurasi, jalankan `nginx -t` untuk memastikan tidak ada salah ketik, baru reload. Tunggu beberapa jam sampai log baru terkumpul.

Cari URL dan IP yang paling banyak

Di format combined, kolom pertama adalah IP dan kolom ketujuh adalah path URL. Untuk melihat 20 URL paling sering diakses, jalankan `awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20`. Ganti `$7` dengan `$1` untuk melihat 20 IP teratas.

Kalau `$request_time` ditaruh di posisi kedua dari akhir dan upstream di paling akhir, urutkan request paling lambat dengan `awk '{print $(NF-1), $7}' /var/log/nginx/access.log | sort -rn | head -20`. Dari daftar ini biasanya langsung terlihat polanya: satu halaman pencarian, satu endpoint API, atau satu halaman laporan yang selalu muncul di atas.

Untuk mempersempit ke jam tertentu, misalnya saat pengguna mengeluh, saring dulu dengan grep berdasarkan tanggal dan jam di log, contohnya `grep '08/Sep/2026:14'`, lalu teruskan ke perintah awk yang sama.

Hitung error 5xx

Error 502 dan 504 sering jadi tanda backend kewalahan. Kolom kesembilan adalah kode status, jadi `awk '$9 ~ /^5/' /var/log/nginx/access.log | wc -l` menghitung jumlah respons 5xx. Untuk tahu URL mana yang paling sering error, gabungkan filter itu dengan `{print $7}` lalu urutkan seperti sebelumnya.

Cocokkan jam error dengan error.log Nginx dan log aplikasi. Kalau 504 menumpuk di jam yang sama dengan request_time yang tinggi, besar kemungkinan ada query database atau proses berat yang melewati batas timeout.

Kenali lonjakan bot crawler

Tidak semua lambat disebabkan pengguna asli. Crawler mesin pencari, bot SEO, dan scraper bisa mengirim ratusan request per menit ke halaman berat. User agent ada di bagian yang diapit tanda kutip ganda, jadi `awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head` menampilkan user agent terbanyak.

Kalau satu bot mendominasi, cek dulu apakah itu crawler yang kamu butuhkan. Untuk bot yang tidak berguna, batasi lajunya dengan `limit_req` di Nginx atau blokir berdasarkan user agent. Hati-hati memblokir crawler mesin pencari, karena efeknya langsung ke SEO.

Supaya tidak mengetik ulang setiap kali

Perintah di atas cukup untuk investigasi sekali jalan. Untuk dipakai berkala, Log analyzer Nginx merangkum access log jadi output ringkas: IP teratas, halaman yang paling banyak kena 404, dan pola traffic bot, dalam bentuk skrip Bash. Pasangkan dengan Cek resource harian + reminder yang mengirim laporan pemakaian server ke Telegram atau email setiap hari, supaya lonjakan traffic bisa dicocokkan dengan kenaikan RAM atau disk. Kalau server belum pernah dirapikan sama sekali, jasa setup dan hardening VPS bisa jadi titik awal.

Mulai hari ini dengan satu langkah: tambahkan request_time ke format log, reload Nginx, lalu besok pagi jalankan perintah urut request paling lambat. Daftar 20 baris itu biasanya sudah menunjuk halaman yang perlu diperbaiki lebih dulu.