Log Akses Server — Cerita Setiap Permintaan yang Diterima Aplikasi Anda

Setiap permintaan HTTP yang ditangani oleh server Anda akan meninggalkan satu baris di log akses. Sebagian besar waktu, file-file ini berada di disk dan tumbuh secara diam-diam hingga alarm disk terjadi atau sesuatu rusak di produksi. Lalu tiba-tiba semua orang ingin membaca file tersebut.

Berikut ini adalah satu baris dari server yang berjalan dengan Format Log Gabungan:

203.0.113.42 - jsmith [09/May/2026:14:32:11 +0000] "GET /api/users/profile HTTP/1.1" 200 1843 "https://example.com/dashboard" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"

Delapan bidang. Setiap bidang merupakan bagian bukti tentang apa yang terjadi. Mari kita mulai dari kiri ke kanan.

Bidang-Bidang, Satu Per Satu

1. IP Klien — 203.0.113.42

Alamat IP yang membuka koneksi TCP ke server Anda. Ini adalah bukan pasti alamat IP pengguna akhir. Jika Anda berada di balik load balancer, CDN, atau reverse proxy (misalnya Nginx di depan aplikasi Node), maka ini akan menjadi alamat IP proxy. Alamat IP klien yang sebenarnya terdapat di X-Forwarded-For atau X-Real-IP header — dan Anda harus mengatur format log secara eksplisit untuk menangkapnya.

Di Nginx, ini terlihat seperti menambahkan $http_x_forwarded_for ke dalam log_format directif. Di Apache, gunakan %{X-Forwarded-For}i. Jika Anda melewatkan ini dan kemudian menerima keluhan tentang penyalahgunaan atau perlu menghentikan penyerang, Anda akan menemukan diri Anda memandang alamat IP load balancer Anda di setiap baris log.

2. Ident — -

Selalu berupa tanda minus. Bidang ini seharusnya mengandung hasil pencarian identd — sebuah protokol lama (RFC 1413) yang memungkinkan server menanyakan kepada sistem operasi klien siapa yang memproses koneksi tersebut. Tidak ada yang lagi menjalankan identd. Bidang ini tetap ada karena format log umum dibuat saat identd masih ada. Lepaskan saja.

3. Pengguna Otorisasi — jsmith

Nama pengguna, yang diisi saat HTTP Basic Auth atau Digest Auth berlangsung. Untuk kebanyakan aplikasi modern — autentikasi token, cookie sesi, JWT — ini akan berupa tanda minus. Jika Anda melindungi area admin dengan htpasswd, login gagal ditampilkan sebagai - di samping status 401; login berhasil menampilkan nama pengguna.

4. Waktu Permintaan — [09/May/2026:14:32:11 +0000]

Waktu ketika server menyelesaikan penanganan permintaan (bukan saat permintaan dimulai). Formatnya adalah day/Mon/year:HH:MM:SS timezone. Perbedaan zona waktu lebih penting daripada yang orang sadari — jika server aplikasi Anda berjalan di UTC tetapi alat APM atau peringatan Anda berada di zona waktu lokal, maka menghubungkan lonjakan log dengan insiden tertentu membutuhkan perhitungan konversi setiap kali. Jalankan semua hal di UTC.

5. Baris Permintaan — "GET /api/users/profile HTTP/1.1"

Bidang yang paling kaya informasi. Tiga bagian: metode HTTP, jalur dengan string query, dan versi protokol.

• Metode — GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS. Metode yang tidak terduga pada suatu endpoint perlu dicatat.
• Jalur + string query — memberi tahu Anda secara tepat apa yang diminta. String query dapat mengandung kata kunci pencarian, ID, dan dalam API yang dirancang buruk, token autentikasi. Catat sesuai dengan hal ini.
• Protokol — klien HTTP/1.0 di log Anda pada tahun 2026 adalah integrasi lama atau sesuatu yang meniru klien lama. Klien HTTP/2 dan HTTP/3 mencatat versi tersebut jika server mendukungnya.

6. Kode Status — 200

Kode HTTP yang dikirim kembali oleh server. Ini adalah bidang penilaian.

• 2xx — sukses. Permintaan berhasil ditangani.
• 3xx — redirect. Klien perlu pergi ke tempat lain.
• 4xx — kesalahan klien. Permintaan buruk, kekurangan autentikasi, tidak ditemukan. Bisa jadi penggunaan yang sah atau eksplorasi.
• 5xx — kesalahan server. Aplikasi Anda crash, timeout, atau mengembalikan data yang rusak. Selalu investigasi ini.

Saat menangani insiden, filter berdasarkan 5xx pertama. Lalu lihat waktu pertama munculnya 500 — itu saat kegagalan dimulai. Semua sebelumnya adalah persiapan; semua sesudahnya adalah dampaknya.

7. Ukuran Respon — 1843

Ukuran tubuh respons dalam byte, tidak termasuk header. Tanda minus berarti nol byte (biasanya untuk 304 Not Modified respon — klien sudah memiliki konten tersebut). Nilai yang sangat besar pada endpoint yang seharusnya mengembalikan beberapa ratus byte adalah peringatan merah. Seorang pengguna yang terautentikasi mengakses endpoint “dapatkan profil saya” dan menerima 40MB adalah bug atau seseorang yang memanfaatkan eksport data.

8. Referer — "https://example.com/dashboard"

Dari mana klien datang sebelum membuat permintaan ini — URL di header browser. Referer . (Spesifikasi HTTP salah menulisnya pada tahun 1996 dan kita tetap menggunakannya.) Permintaan langsung, bookmark, dan permintaan dari aplikasi native datang dengan referer kosong. Bidang ini hanya ada di Format Log Gabungan; format log umum berakhir pada ukuran respon.

Spam referer — header referer palsu dalam permintaan massal yang berusaha muncul di analitik Anda — lebih umum dulu tetapi kini hampir menjadi barang bekas. Tetap perlu dihilangkan dari statistik agregat Anda.

9. User Agent — "Mozilla/5.0 (Windows NT 10.0; Win64; x64)…"

Identitas klien. User agent sangat mudah disalahgunakan, sehingga ini harus dianggap sebagai petunjuk, bukan fakta. Penelusuran yang sah biasanya mengidentifikasi dirinya secara jujur: Googlebot/2.1 (+http://www.google.com/bot.html), Bingbot/2.0. Penelusuran yang meniru browser mengirimkan string lengkap Mozilla/5.0 Chrome. Curl mengirimkan curl/8.x kecuali seseorang mengubahnya dengan -A.

Pola untuk diawasi: string user agent yang identik menyerang endpoint yang sama dengan kecepatan mesin, atau user agent yang mengklaim sebagai iOS Safari tetapi membuat permintaan dalam pola yang tidak akan dilakukan oleh browser manusia (tidak ada gambar, tidak ada CSS, penelusuran halaman produk secara berurutan).

Pola yang Muncul di Setiap Log

Pemindaian keamanan

Sebuah IP tunggal atau subnet kecil yang menyerang banyak jalur secara cepat berurutan: /.env, /wp-login.php, /phpmyadmin, /admin/config.yml, /.git/config. Semua mengembalikan 404. Ini adalah pemindaian otomatis yang menjalankan checklist, bukan serangan yang ditargetkan. Mereka menjalankan ini terhadap setiap IP publik secara terus-menerus.

Pertanyaan yang benar bukan “mengapa mereka memindaian saya” — melainkan “apakah salah satu dari jalur tersebut mengembalikan 200.” Jika /.env mengembalikan 200 di server Anda, itu adalah masalah nyata.

# Check if any sensitive paths actually returned 200
grep -E '"(GET|POST) /(wp-login\.php|\.env|\.git/config|phpmyadmin|admin)' access.log | awk '$9 == 200'

Pemindaian kredensial

Permintaan POST berjumlah tinggi ke endpoint login Anda, hampir semua mengembalikan 401, dari sejumlah IP yang tersebar. Tanda khasnya adalah pola: endpoint yang sama, ukuran respons konsisten (halaman kesalahan), banyak IP berbeda yang berbagi ASN. Waktu respons cenderung konsisten juga — upaya login otomatis berjalan dengan laju stabil untuk menghindari batasan kecepatan.

# Count POST /login attempts with 401 status by source IP
awk '$6 == "\"POST" && $7 == "/api/login" && $9 == "401" {print $1}' access.log \
  | sort | uniq -c | sort -rn | head -20

Lonjakan 404 setelah deploy

Anda melakukan deploy versi baru. Jumlah 404 meningkat. Tautan lama di email, bookmark, dan situs eksternal mengarah ke URL yang tidak lagi ada. Ini normal — tetapi jika 404 muncul di URL yang seharusnya ada di versi baru, itu adalah regresi routing. Bandingkan jalur 404 dengan definisi rute Anda.

Kluster respon lambat

Format log standar tidak mencakup waktu respon. Anda harus menambahkannya: di Apache, tambahkan %D (microsecond) ke dalam LogFormat; di Nginx, tambahkan $request_time ke dalam log_format blok. Setelah Anda memiliki itu:

# Nginx: show requests slower than 3 seconds (request_time in last field)
awk '{if ($NF+0 > 3) print $0}' /var/log/nginx/access.log | head -20

Jika permintaan lambat berkumpul di jendela waktu tertentu, itu adalah konten — sebuah tugas cron, proses batch, atau backup yang memukul database. Jika suatu jalur secara konsisten lambat terlepas dari waktu, itu adalah query lambat atau panggilan I/O yang menghambat yang perlu dianalisis.

Mengatasi Insiden dari Log

Log akses adalah timeline. Ketika pengguna melaporkan “sesuatu rusak sekitar pukul 3 sore,” Anda:

• Filter ke rentang waktu 14:50–15:10
• Cari pertama kali munculnya 5xx — itu saat kegagalan dimulai
• Periksa apa yang berubah dalam beberapa menit sebelumnya: apakah ada deploy? Push konfigurasi? Pembaruan sertifikat?
• Periksa jalur mana yang mengalami 5xx — apakah semua atau hanya satu endpoint?
• Periksa ukuran respon yang berhasil sebelum dan sesudah — apakah sesuatu mulai mengembalikan respons yang terpotong?

Beberapa tanda kegagalan yang perlu diketahui:

• Lonjakan 502 — upstream Anda mati (crash aplikasi, koneksi pool habis, database down). Lonjakan 502 dimulai pada waktu yang tepat.
• Lingkaran redirect — 301/302 dari IP yang sama ke jalur yang sama secara berulang. Biasanya konfigurasi redirect HTTPS yang salah atau pengaturan SSL Cloudflare yang bertentangan dengan logika redirect aplikasi Anda.
• 200 dengan nol byte — status 200 tetapi ukuran yang dikirim adalah nol atau -. Aplikasi Anda menerima permintaan, menangkap pengecualian, dan mengembalikan tubuh kosong. Kasus kegagalan yang tidak ditangani klasik.
• Lonjakan 413 — klien mengirim badan permintaan melebihi batas ukuran Anda. Atau batas ukuran Anda terlalu rendah untuk kasus penggunaan atau seseorang sedang memeriksa kelemahan upload.

Jika Anda menghadapi log dalam format berbeda — Apache Common, Apache Combined, Nginx default, format kustom — Format Pemroses Log Akses dapat memarsing dan memberi annotasi pada bidang-bidang tersebut sehingga Anda tidak perlu secara mental memetakan posisi bidang setiap kali Anda beralih antara server.

Pengelolaan Log yang Anda Sayangkan Tidak Menyediakan

• Rotasi log — logrotate diatur untuk rotasi harian, dikompres, dan disimpan selama 14–30 hari. Tanpa itu, access.log meningkat hingga disk penuh. Ini terjadi di produksi.
• Pengelolaan log terpusat — setelah Anda memiliki lebih dari satu server, mengekstrak file log secara individu tidak dapat diperluas. Kirim ke Loki + Grafana, Elasticsearch, atau layanan terkendali. Format log JSON terstruktur membuat pencarian jauh lebih mudah daripada memarsing CLF dengan awk.
• Kontrol akses pada log mentah — file log dapat mengandung parameter query dengan token, data PII pengguna, dan jalur internal. Jangan buat file log tersebut dapat dibaca oleh semua orang. Jadilah sengaja dalam periode retensi log jika Anda berada di bawah GDPR atau serupa.
• Jangan log parameter query sensitif — jika aplikasi Anda menerima token autentikasi atau kata sandi sebagai parameter URL (tidak seharusnya, tetapi sering terjadi pada API lama), filter pada tingkat log sebelum mereka mencapai disk.

Anda mungkin juga menyukai