Membaca log pelayan nginx tanpa menjadi jurutera: apa yang access.log dan error.log beritahu pemilik laman

Setiap permintaan yang sampai ke laman web meninggalkan satu baris dalam fail log nginx. Satu baris itu menyimpan sembilan maklumat: alamat IP, nama pengguna HTTP, masa, laluan yang diminta, kod status, saiz badan respons, laman rujukan dan identiti pelayar. Ukuran pada satu log nginx sebenar menunjukkan 2,000 baris terakhir berjumlah 309,255 bait, iaitu kira-kira 155 bait satu baris. Jumlah itu kecil untuk satu permintaan, tetapi selepas 14 hari ia menjadi fail yang mampu menjawab soalan yang biasanya orang bayar untuk tahu: halaman mana yang rosak, siapa menghantar trafik, dan bila pelayan mula meragam.

Pos ini bukan panduan menjadi pentadbir sistem. Ia adalah urutan kerja untuk pemilik laman: dua fail yang perlu dikenali, bahagian satu baris log, kod status yang menentukan tindakan, dan corak yang menandakan sesuatu perlu dibaiki. Laporan Bad Bot Report 2026 daripada Imperva memberi konteks pada permulaan: trafik automatik melebihi 53 peratus daripada semua trafik web sepanjang 2025, naik daripada 51 peratus pada 2024. Sebahagian besar baris dalam log sesebuah laman tidak datang daripada manusia, jadi bacaan mentah jumlah lawatan mudah mengelirukan.

Access log dan error log: dua fail, dua tugas berbeza

Nginx menulis dua log secara lalai. access_log mencatat setiap permintaan yang dijawab, dan nilai lalainya ialah logs/access.log dengan format combined. error_log mencatat masalah, termasuk mesej bahawa fail tidak dijumpai pada cakera kerana log_not_found berada dalam keadaan on secara lalai. Pada pemasangan Ubuntu 24.04 dengan nginx 1.24.0, kedua-duanya berada dalam /var/log/nginx/ sebagai access.log dan error.log.

Error log mempunyai lapan peringkat keterukan: debug, info, notice, warn, error, crit, alert dan emerg, disusun daripada paling ringan kepada paling berat. Peringkat lalai ialah error, jadi hanya error, crit, alert dan emerg dicatat selagi tetapan itu tidak diubah. Sebab itulah sesetengah masalah kelihatan tiada dalam log: mesej itu berada di peringkat warn atau notice yang tidak diminta oleh tetapan lalai.

• ▸ Semak saiz dan senarai fail: ls -lh /var/log/nginx/ menunjukkan access.log, access.log.1 dan fail lama yang berakhir .gz.
• ▸ Pada Ubuntu, fail /etc/logrotate.d/nginx menetapkan daily, rotate 14, compress, delaycompress dan create 0640 www-data adm.
• ▸ Fail lama masih boleh dibaca: zgrep ' 404 ' /var/log/nginx/access.log.*.gz menyemak semua fail mampat sekali gus.
• ▸ Tetapan 0640 bermakna hanya pemilik fail dan kumpulan adm boleh membaca log, bukan setiap pengguna pelayan.

Bahagian satu baris log dan apa yang diabaikan orang

Format lalai nginx dipanggil combined, dan dokumentasi rasmi menulisnya begini:

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

Sebuah baris sebenar mengikut format itu kelihatan begini, menggunakan alamat contoh 203.0.113.9:

203.0.113.9 - - [12/Oct/2026:09:14:02 +0800] "GET /blog/sandaran-laman-web HTTP/1.1" 200 18422 "https://www.google.com/" "Mozilla/5.0 (compatible; Googlebot/2.1)"

Dua perkara sering tersalah faham. $body_bytes_sent mengira badan respons sahaja, tanpa header; untuk jumlah bait sebenar yang dihantar kepada pelanggan, nginx menyediakan $bytes_sent. Kedua, nginx menulis baris log selepas pemprosesan permintaan tamat, jadi masa dalam $time_local ialah masa permintaan selesai, bukan masa ia bermula.

Dua medan yang paling berguna untuk masalah kelajuan tidak ada dalam format lalai. $request_time mengukur masa daripada bait pertama dibaca daripada pelanggan sehingga baris log ditulis, manakala $upstream_response_time mengukur masa aplikasi di belakang nginx membalas. Pada laman yang berjalan melalui aplikasi, kedua-dua angka ini yang memisahkan masalah pelayan hadapan daripada masalah aplikasi, dan ia hanya muncul selepas log_format ditambah sendiri.

Kod status yang menentukan tindakan

Lima kumpulan kod sudah cukup untuk membaca log harian tanpa mengira setiap nombor.

• ▸ 200 dan 2xx: permintaan berjaya dijawab. Lonjakan jumlah 200 biasanya bermakna trafik atau crawler bertambah, bukan kerosakan.
• ▸ 301 dan 302: pengalihan. Rantaian tiga pengalihan atau lebih untuk satu alamat membazir masa pemuatan pelawat.
• ▸ 404: halaman tidak dijumpai. Kod ini muncul dalam access.log dan dimaklumkan juga dalam error.log kerana log_not_found lalai on.
• ▸ 499: kod khusus nginx. Dokumentasi Cloudflare menerangkannya sebagai pelanggan menamatkan sambungan sebelum pelayan sempat membalas, keadaan yang berlaku apabila had masa pelanggan lebih pendek daripada masa pemprosesan.
• ▸ 500, 502, 503 dan 504: masalah di pihak pelayan. Kod 502 bermakna pelayan hadapan tidak menerima jawapan yang sah daripada aplikasi di belakangnya.

Kiraan mudah: 150 baris berstatus 404 daripada 5,000 permintaan sehari ialah 3 peratus permintaan menuju halaman yang tidak wujud. Nisbah itu tidak membimbangkan jika halaman lama sudah dialihkan, tetapi ia menjadi isu berasingan apabila setiap 404 menunjuk ke pautan yang dipasang di menu utama.

Arahan ringkas untuk soalan yang paling kerap

Semua arahan di bawah dijalankan dari terminal pelayan dalam folder /var/log/nginx. Kedudukan medan dalam format combined mudah diingat: $1 alamat IP, $7 laluan, $9 kod status.

awk '{print $9}' access.log | sort | uniq -c | sort -rn | head

awk '$9 == 404 {print $7}' access.log | sort | uniq -c | sort -rn | head -20

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

awk '$9 ~ /^5/ {print $4, $7, $9}' access.log | tail -20

Arahan pertama mengira setiap kod status, arahan kedua menunjukkan 20 alamat yang paling banyak menghasilkan 404, dan arahan ketiga menyenaraikan sepuluh alamat IP dengan permintaan terbanyak. Jika ada antara alamat itu dengan ratusan permintaan sehari ke laluan yang sama, itu tanda crawler atau alat pengikis, bukan pembaca.

Untuk paparan tanpa menulis arahan tambahan, GoAccess memapar panel seperti 404 atau Not Found, serta panel Hosts yang berguna untuk melihat crawler agresif, dan ia mengenali format log bertakrif seperti COMBINED. Versi yang dibina dengan sokongan zlib boleh membaca fail .gz terus tanpa membuka mampatan secara manual.

Bot dan crawler: separuh baris bukan pelawat

Laporan Imperva 2026 meletakkan trafik automatik pada lebih 53 peratus daripada semua trafik web sepanjang 2025, dan 27 peratus serangan bot menyasarkan titik akhir API. Terjemahannya di peringkat laman kecil: daripada 10,000 baris dalam log sehari, kira-kira 5,300 mungkin bukan manusia. Membuat keputusan kandungan berdasarkan jumlah lawatan mentah tanpa menolak trafik bot boleh membawa kepada kesimpulan yang salah.

Fail robots.txt dan sitemap.xml menentukan apa yang crawler dibenarkan dan dijangka lihat, dan kedua-duanya lebih mudah diperiksa daripada log. Untuk log, cara paling cepat ialah menyemak sepuluh alamat IP teratas bersama lima user agent teratas. Crawler yang mematuhi peraturan biasanya menyebut namanya sendiri dalam user agent, manakala alat pengikis kasar menghantar ribuan permintaan tanpa laman rujukan.

Berapa lama log disimpan dan berapa ruang diperlukan

Logrotate menjalankan pusingan log sebagai kerja cron harian, dan rekod keadaan terakhirnya disimpan dalam /var/lib/logrotate/status. Konfigurasi nginx pada Ubuntu menetapkan pusingan harian, menyimpan 14 pusingan, memampatkan fail lama dan melewatkan mampatan satu pusingan. Sebab itulah access.log.1 masih belum dimampatkan sementara access.log.2.gz dan seterusnya berakhir .gz.

Dengan 155 bait satu baris, 10,000 permintaan sehari menghasilkan kira-kira 1.55 MB log sehari, atau 21.6 MB selepas 14 hari sebelum pemampatan. Satu juta permintaan bersamaan kira-kira 155 MB. Fail mampat biasanya jauh lebih kecil, tetapi ruang tetap perlu diperiksa kerana panjang baris bergantung pada panjang alamat dan user agent.

• ▸ Semak ruang dengan df -h / untuk cakera dan du -sh /var/log/nginx untuk jumlah log nginx.
• ▸ Jika trafik tinggi, tambah nilai rotate atau kurangkan yang dicatat dengan mengecualikan permintaan fail statik daripada log.
• ▸ Sebelum memendekkan tempoh simpanan, pastikan tetapan pelayan dan laman disandarkan: sandaran yang hanya mengandungi fail laman tidak cukup untuk memulihkan sistem yang rosak.

Tiga corak yang patut mencetuskan tindakan

• ▸ 404 melonjak pada alamat yang sebelum ini dijawab 200: pautan rosak, halaman dipadam tanpa pengalihan, atau menu yang menunjuk ke alamat lama.
• ▸ Kod 5xx berulang: baca error.log dahulu. Jika 502 muncul, aplikasi di belakang nginx tidak membalas dalam masa yang ditetapkan.
• ▸ 499 meningkat: pelawat menutup sambungan sebelum jawapan siap, biasanya kerana halaman lambat atau had masa terlalu pendek.

Selain kod status, jadual permintaan memberi bacaan berguna. Lonjakan bilangan baris sejam pada waktu malam tanpa kempen menandakan sesuatu menghantar permintaan secara automatik. Pemantauan uptime menjawab soalan berbeza, iaitu bila laman jatuh, manakala log menjawab mengapa ia jatuh atau lambat.

Lima minit membaca log sehari sudah mencukupi untuk menangkap tiga corak di atas. Mulakan dengan senarai kod status, kemudian semak alamat yang paling banyak menghasilkan 404 dan 5xx, dan simpan setiap perubahan konfigurasi log supaya tetapan itu tidak hilang apabila pelayan dipasang semula.