Docker Logs untuk Pemula: Baca, Batasi, dan Rotasi Log
Belajar docker logs dari file Compose nyata: stdout dan stderr, driver json-file dan journald, rotasi max-size, dan cara membaca log saat deploy gagal.
Oleh Matthews WongDitinjau pada
Poin utama
Docker logs adalah apa pun yang ditulis proses utama container ke standard output dan standard error. Docker menangkap kedua aliran itu, menyimpannya lewat logging driver (secara default json-file), dan docker logs membacanya kembali. Tanpa batas ukuran, driver default tidak pernah merotasi log, sehingga container yang cerewet bisa pelan-pelan memenuhi disk.
Setelah pelajaran ini, Anda bisa
- Membaca log container dengan docker logs dan docker compose logs: follow, tail, since, dan timestamps.
- Menjelaskan di mana sebuah baris log disimpan pada driver json-file dan journald.
- Membatasi ukuran log dengan max-size dan max-file, serta menemukan error sebenarnya di log CI atau deploy yang gagal.
Ikuti diagramnya langkah demi langkah
Tekan Putar, atau melangkah dengan panah. Setiap langkah juga ditulis di bawah diagram.
Ke mana baris log pergi, dan siapa yang membacanya
Aplikasi menulis ke stdout dan stderr, logging driver Docker menyimpan baris itu di file berbatas atau di journal systemd, dan docker logs atau journalctl membacanya kembali.
Tombol: ← → langkah · Home / End · K putar atau jeda
Container menulis baris, logging driver menyimpannya, dan pembaca memintanya nanti. Journal di kanan adalah penyimpanan alternatif; untuk sementara dibuat pudar.
Docker menangkap standard output dan standard error dari proses utama. Aplikasi tidak mengelola file log sendiri; ia cukup mencetak, dan Docker menangkap setiap baris.
Tebak langkah berikutnya Drivernya json-file dan max-size tidak diisi. Saat aplikasi terus mencetak, apa yang terjadi pada file log? (Tetap kecil dengan sendirinya · Terus membesar tanpa batas · Dirotasi setiap hari)Driver json-file bawaan menambahkan setiap baris, lengkap dengan stream dan waktunya, ke file JSON di host. Nilai bawaan max-size tidak terbatas, jadi tidak ada rotasi.
Dengan max-size 10m dan max-file 3, driver merotasi file saat mencapai batas ukuran dan menghapus yang tertua setelah lebih dari tiga. Disk tetap terbatas.
logging: driver: json-file options: max-size: "10m" max-file: "3"docker logs meminta Docker menampilkan baris yang tersimpan. Tambahkan follow untuk terus mengalir, tail untuk hanya melihat bagian akhir, dan timestamps untuk melihat kapan tiap baris ditulis.
docker logs --tail 100 --follow webTebak langkah berikutnya Anda mengganti driver ke journald. Di mana baris log sekarang tersimpan? (Masih di file JSON · Di journal systemd · Tidak di mana pun)Dengan driver journald, baris dikirim ke journal systemd. Setiap entri membawa nama container, sehingga journalctl bisa memfilternya.
journalctl CONTAINER_NAME=web --since today
Apa isi log sebuah container?
Secara default, docker logs menampilkan standard output dan standard error dari perintah utama. Standard output biasanya berisi keluaran normal, dan standard error dipakai untuk pesan error. Apa yang Anda lihat hampir sepenuhnya bergantung pada perintah utama container: kalau ia mencetak, Anda mendapat log.
Baca selengkapnya (1)Tutup
Jebakannya adalah aplikasi yang menulis ke file lognya sendiri. Saat itu docker logs bisa tidak menampilkan apa-apa yang berguna. Image nginx resmi mengatasinya dengan mengaitkan file lognya ke perangkat standard output dan error, sehingga kebiasaan yang sama juga berlaku untuknya.
Logging driver mana yang menyimpan baris log?
Docker memakai driver json-file kecuali Anda mengubahnya. Driver ini menyimpan setiap baris sebagai objek JSON berisi teks, stream (stdout atau stderr), dan waktu. Driver lain yang perlu dikenal lebih dulu adalah journald, yang meneruskan baris ke journal systemd, tempat journalctl, journal API, atau docker logs bisa membacanya.
Baca selengkapnya (1)Tutup
Driver bisa diatur per container atau untuk seluruh daemon di daemon.json, tetapi default yang diubah hanya berlaku untuk container yang dibuat sesudahnya. Container yang sudah ada mempertahankan opsi saat dibuat, jadi buat ulang untuk menggantinya. Untuk memeriksa yang dipakai sebuah container, jalankan docker inspect dengan format pada HostConfig.LogConfig.Type.
Kenapa ukuran log perlu dibatasi, dan bagaimana rotasi bekerja?
Pada json-file, max-size secara default bernilai -1, tanpa batas, dan max-file bernilai 1. Rotasi membutuhkan keduanya: max-file baru berlaku jika max-size juga diisi. Saat rotasi akan membuat terlalu banyak file, yang tertua dihapus, dan itu persis yang Anda inginkan dari log yang hanya dibaca saat ada masalah.
Baca selengkapnya (1)Tutup
File yang dirotasi adalah sebuah pertukaran: disk terjaga, tetapi baris yang lebih lama hilang selamanya. Apa pun yang harus disimpan lebih lama, seperti jejak audit, sebaiknya disimpan di tempat yang memang dibuat untuk itu, bukan di log container.
Bagaimana membaca log tanpa tenggelam di dalamnya?
docker logs punya follow untuk mengalirkan baris baru, tail untuk membatasi ke baris terakhir (defaultnya semua), since untuk hanya menampilkan baris yang lebih baru, dan timestamps untuk mencetak waktu tiap baris. docker compose logs melakukan hal yang sama untuk layanan dalam proyek Compose, dan menerima nama layanan.
Baca selengkapnya (1)Tutup
Dengan driver journald, pakai journalctl. Pencocokan field seperti CONTAINER_NAME memfilter ke satu container, since dan until menetapkan rentang waktu, lines menampilkan entri terbaru, dan filter priority hanya menyisakan entri pada tingkat tersebut atau di atasnya.
Bagaimana membaca log deploy yang gagal?
Log deploy bukan log container: ini keluaran sebuah run GitHub Actions. Buka run-nya, klik job-nya, dan step yang gagal akan terbuka otomatis. Pakai kotak pencarian untuk menemukan sebuah frasa, dan unduh arsip log bila Anda ingin menyimpannya di mesin sendiri.
Baca selengkapnya (1)Tutup
Bacalah error pertama di step yang gagal, bukan baris terakhir, karena baris-baris sesudahnya biasanya hanya dampak. Dan buat step Anda sendiri mudah dibaca: workflow smoke di repo ini mengarahkan keluaran server ke file dan mencetaknya hanya ketika sebuah step gagal, sehingga bukti tersedia saat dibutuhkan dan tenang saat tidak.
Konfigurasi nyata di balik pelajaran ini
Kutipan dari repositori yang membangun dan men-deploy situs ini, apa adanya.
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"Seluruh kebijakan log container production. Drivernya ditulis eksplisit walau json-file adalah default, sehingga maksudnya terlihat. Dengan opsi ini container menyimpan paling banyak tiga file masing-masing sekitar 10 MB, dan yang tertua dibuang saat file keempat akan dibuat.
- name: Serve
run: |
PORT=3000 npm start > server.log 2>&1 &
for i in $(seq 1 60); do
if curl -sf -o /dev/null http://localhost:3000/en/play/; then exit 0; fi
sleep 2
done
echo "server did not come up"
cat server.log
exit 1Ide yang sama dengan log container, dilakukan manual: server dijalankan di latar belakang dengan stdout dan stderr dialihkan ke server.log, lalu ditunggu. Jika tidak pernah merespons, step mencetak file itu sebelum gagal, sehingga run-nya menjelaskan dirinya sendiri, bukan sekadar exit 1.
# The hosted runner's disk is small, and this build is not: the restored
# .next/cache, node_modules and a ~1,586-page build output that Docker
# copies twice (into .next/standalone, then into the runner image). On
# 2026-10-07 it ran out mid-build ("no space left on device" at the
# standalone COPY) and every deploy after a852ccf failed the same way.
# The image ships ~20-30 GB of toolchains this job never uses; delete
# them first. `df` is printed before and after, so the headroom shows
# in the log.
- name: Free disk space on the runner
run: |
df -h / | tail -1Kegagalan nyata yang ditemukan dengan membaca log: pesan no space left on device muncul di tengah build. Perbaikannya dipasangkan dengan baris log, karena df dicetak sebelum dan sesudah pembersihan, sehingga kegagalan berikutnya memperlihatkan seberapa lega ruangnya, bukan menyisakan tebakan.
Kesalahan yang benar-benar membuang waktu
max-file diisi, max-size terlupa
max-file hanya berlaku jika max-size diisi. Dengan max-size tetap pada default tanpa batas, tidak ada yang pernah dirotasi dan satu file terus membesar sampai disk penuh. Selalu isi keduanya bersamaan, dan pastikan dengan docker inspect bahwa container benar-benar memilikinya.
Mengubah driver default dan berharap container lama ikut
Default baru di daemon.json hanya berlaku untuk container yang dibuat setelah Docker di-restart. Container yang sudah ada mempertahankan opsi saat dibuat, jadi yang lama tetap mencatat log dengan cara lama sampai Anda membuatnya ulang.
docker logs kosong karena aplikasi menulis file sendiri
Jika aplikasi mengirim keluaran ke file log di dalam container, docker logs tidak punya apa pun untuk ditampilkan. Arahkan aplikasi ke standard output dan standard error, atau kaitkan file itu ke keduanya seperti yang dilakukan image nginx resmi.
Hanya membaca baris terakhir dari run yang gagal
Baris terakhir biasanya hanya dampak dari error sebelumnya, misalnya kode exit yang generik. Buka step yang gagal, gulir ke error pertama, dan pakai pencarian log untuk frasa persisnya.
| json-file (default) | journald | |
|---|---|---|
| Tempat baris disimpan | Satu file JSON per container | Journal systemd |
| Cara membacanya | docker logs | journalctl, journal API, atau docker logs |
| Pengaturan ukuran | max-size dan max-file | Tidak diatur dengan max-size atau max-file |
| Filter per container | Sebutkan nama container | Pencocokan field CONTAINER_NAME |
Lakukan di komputer Anda sendiri
Anda hanya butuh Docker. Jalankan container yang mencetak satu baris setiap detik, baca lognya, lalu buat ulang dengan batas ukuran dan pastikan pengaturannya.
Jalankan container yang mencetak satu baris berstempel waktu setiap detik.
docker run -d --name chatty alpine sh -c 'while true; do date; sleep 1; done'Baca lima baris terakhir dengan timestamp, lalu ikuti baris baru. Hentikan dengan Ctrl-C.
docker logs --tail 5 --timestamps chatty docker logs --tail 5 --follow chattyTanyakan ke Docker driver apa yang dipakai container.
docker inspect -f '{{.HostConfig.LogConfig.Type}}' chattyHapus lalu jalankan lagi dengan batas tiga file kecil, kemudian pastikan opsinya tersimpan.
docker rm -f chatty docker run -d --name chatty --log-opt max-size=1m --log-opt max-file=3 alpine sh -c 'while true; do date; sleep 1; done' docker inspect -f '{{.HostConfig.LogConfig.Config}}' chattyBersihkan.
docker rm -f chatty
Tiga pertanyaan sebelum lanjut
Pilih jawaban untuk melihat kenapa benar atau salah. Tidak ada yang disimpan atau dinilai, jadi tebak saja dengan bebas.
Jawab dalam hati, lalu cek
1.Berapa banyak riwayat log yang bisa disimpan container production situs ini?Lihat jawabannya
Jawaban:Paling banyak tiga file masing-masing sekitar 10 MB, karena file Compose mengatur max-size 10m dan max-file 3. Saat file baru dibutuhkan, yang tertua dihapus.
2.Perintah mana yang menampilkan 100 baris terakhir log container dan terus mengikutinya?Lihat jawabannya
Jawaban:docker logs --tail 100 --follow diikuti nama container. Untuk proyek Compose, docker compose logs menerima flag yang sama ditambah nama layanan.
3.Sebuah run deploy gagal. Ke mana Anda melihat lebih dulu?Lihat jawabannya
Jawaban:Di job yang gagal pada run itu: step yang gagal terbuka otomatis. Cari error pertama di dalamnya, cari frasa persisnya di log, dan unduh arsipnya jika perlu di lokal.
Bahasan mendalam terkait di situs ini
Sumber
Sumber primer yang diperiksa pada tanggal riset. Ikuti tautannya untuk versi terbaru.