Belajar Traefik - Access Logs & Debugging

#Pendahuluan

Metrik memberi gambaran besar, tapi untuk menelusuri satu request yang bermasalah kalian butuh detail per-request. Episode 24 membahas access logs: catatan lengkap setiap request yang lewat Traefik — dari siapa datangnya, ke mana tujuannya, berapa lama, sampai status apa yang dikembalikan.

Bagian kedua episode ini adalah debugging: teknik memeriksa konfigurasi runtime, log level yang tepat, dan cara membaca semua sinyal yang Traefik berikan. Kombinasi access log yang baik dan teknik debugging yang sistematis adalah keterampilan yang paling sering menyelamatkan kalian di insiden produksi.

#Mengaktifkan Access Logs

#Format Common dan JSON

Access log diaktifkan di static config. Dua format utama tersedia:

accessLog:
  filePath: "/var/log/traefik/access.log"
  format: common
  bufferingSize: 100

• format: common: satu baris teks per request, mudah dibaca manusia.
• format: json: objek JSON per request, mudah di-parse mesin.
• bufferingSize: jumlah baris yang ditampung sebelum ditulis — menaikkan throughput tapi bisa menunda log.

Contoh baris format Common:

127.0.0.1 - - [10/Aug/2026:09:15:22 +0000] "GET /api/users HTTP/1.1" 200 8452 "curl/8.5.0" "-" 12ms

Format JSON menghasilkan struktur yang lebih kaya:

{
  "ClientAddr": "127.0.0.1:51432",
  "ClientHost": "127.0.0.1",
  "RequestMethod": "GET",
  "RequestPath": "/api/users",
  "RequestProtocol": "HTTP/1.1",
  "RouterName": "api@docker",
  "ServiceName": "api-svc@docker",
  "StatusCode": 200,
  "Duration": 12000000,
  "RequestHost": "api.example.com"
}

Perhatikan field RouterName dan ServiceName — inilah kunci menghubungkan log dengan konfigurasi routing.

#Filter dan Field Kustom

#Membatasi Volume Log

Log bervolume besar itu mahal. Filter dan pemilihan field membantu mengendalikannya:

accessLog:
  format: json
  filters:
    statusCodes:
      - "200"
      - "5xx"
    retryAttempts: true
  fields:
    defaultMode: drop
    names:
      ClientAddr: keep
      RequestHost: keep
      RequestPath: keep
      StatusCode: keep
      Duration: keep
      ServiceName: keep

• filters.statusCodes: hanya log status tertentu — di atas hanya 200 dan semua 5xx.
• fields.defaultMode: drop: buang semua field kecuali yang didaftarkan di names.
• retryAttempts: true: tambahkan field jumlah percobaan retry.

Hasilnya: log ramping berisi data yang benar-benar dipakai untuk debugging dan alerting.

#Agregasi Log Terpusat

#Loki dan ELK

Access log di file lokal tidak berguna jika kalian punya puluhan node. Praktik standar: alirkan log ke sistem terpusat.

• Loki (Grafana): scrape log dari Traefik container dan index labelnya. Cocok dipasangkan dengan Prometheus — satu dashboard untuk metrik dan log sekaligus.
• ELK stack (Elasticsearch, Logstash, Kibana): pipeline yang lebih berat dengan parsing penuh; gunakan format JSON agar Logstash mudah mengekstrak field.

Dengan format JSON, penyerapan ke kedua sistem menjadi sederhana: log JSON dikirim apa adanya, dan sistem parsing membaca field secara otomatis. Dari Kibana atau Grafana, kalian bisa mencari semua request dari satu klien, menelusuri error beruntun, atau memetakan latensi per service.

#Teknik Debugging

#Log Level DEBUG

Ketika perilaku tidak sesuai, naikkan log level Traefik ke DEBUG:

log:
  level: DEBUG
  filePath: "/var/log/traefik/traefik.log"

Log DEBUG menampilkan detail internal: evaluasi rule, keputusan load balancing, dan proses pembaruan konfigurasi. Output-nya sangat besar — nyalakan hanya saat debugging lalu kembalikan ke INFO.

#Inspeksi API dan Dashboard

Sebelum ganti log level, mulai dari API runtime — jawaban biasanya sudah ada di sana:

curl -s http://localhost:8080/api/http/routers | python3 -m json.tool
curl -s http://localhost:8080/api/http/services | python3 -m json.tool

Endpoint /api/http/routers menampilkan semua router beserta rule dan statusnya; /api/http/services menampilkan service dan server list. Kalau router yang diharapkan tidak ada, berarti provider tidak mengirimkannya — periksa labels atau resource. Perintah curl ini adalah langkah pertama debugging Traefik.

#Debugging Sistematis

Urutan yang biasanya berhasil:

1. Periksa dashboard dan API — router muncul atau tidak?
2. Cek log DEBUG untuk evaluasi rule yang gagal.
3. Uji langsung rule dengan curl memakai header Host.
4. Periksa backend — apakah responsnya seperti yang diharapkan?

#Penutup

Inti yang harus dibawa pulang:

• Access log aktif dengan format Common atau JSON.
• Filter status code dan field drop/keep mengendalikan volume log.
• Field RouterName dan ServiceName menghubungkan log dengan konfigurasi.
• Agregasi terpusat: Loki untuk pendamping Prometheus, ELK untuk parsing penuh.
• Log DEBUG untuk detail internal; kembalikan ke INFO setelah selesai.
• Mulai debugging dari API runtime, baru turun ke log.

Di episode 25 selanjutnya kita akan membahas distributed tracing — mengirim trace request lintas service dengan Jaeger, Zipkin, dan OpenTelemetry, konfigurasi sampling, agent versus collector, serta menganalisis latensi breakdown dan error tracking di UI tracer. Dengan ini, satu request bisa dilacak dari browser sampai database.