Log Monitoring (Graylog)

Cara menggunakan Graylog untuk membaca log container dan menemukan error atau warning

1. Overview

Seluruh log container Alurkerja dikumpulkan ke satu tempat menggunakan Graylog. Halaman ini menjelaskan cara memakainya: masuk, membaca dashboard, dan menemukan pesan error atau warning.

Alurnya singkat: setiap container menulis log seperti biasa, sebuah agen bernama Fluent Bit membaca berkas log tersebut lalu mengirimkannya ke Graylog. Aplikasi tidak diubah sama sekali, dan perintah docker logs tetap berfungsi seperti biasa.

Container aplikasi  →  Fluent Bit  →  Graylog  →  Dashboard & Search

Graylog hanya membaca log. Tidak ada perubahan yang dilakukan Graylog terhadap aplikasi, dan mematikan Graylog tidak mempengaruhi jalannya aplikasi.

2. Masuk ke Graylog

Buka http://50.50.50.214:9000 pada browser. Alamat ini hanya bisa diakses dari dalam jaringan internal atau melalui VPN.
Masukkan username dan password yang diberikan administrator.
Setelah berhasil, Anda akan melihat halaman Welcome berisi daftar dashboard yang terakhir dibuka.

Bilah navigasi di bagian atas berisi menu utama:

Menu	Fungsi
Search	Mencari log secara bebas dengan query
Dashboards	Kumpulan tampilan siap pakai — ini yang paling sering dipakai
Streams	Pengelompokan log (belum digunakan)
Alerts	Notifikasi otomatis (belum dikonfigurasi)

Angka di kanan atas (… in / … out) menunjukkan berapa pesan per detik yang masuk dan diproses. Angka ini naik-turun secara normal; nilai 0 sesaat bukan berarti ada masalah.

3. Daftar Dashboard

Klik menu Dashboards untuk melihat semua tampilan yang tersedia.

Dashboard terbagi menjadi dua kelompok:

Dashboard ikhtisar — untuk melihat gambaran menyeluruh:

Dashboard	Gunakan saat
Ikhtisar Log Docker	Ingin tahu kondisi umum: volume log, container paling ramai
Error & Peringatan	Titik awal saat ada masalah — semua ERROR dan WARN di satu layar
Aplikasi javan-prod	Ingin fokus hanya ke stack javan-prod
Integration alurkerja-onprem	Ingin fokus hanya ke stack alurkerja-onprem

Dashboard per service — satu dashboard untuk tiap service (Service: auth, Service: report, Service: camunda, dan seterusnya). Gunakan saat sudah tahu service mana yang bermasalah.

4. Menemukan Error dan Warning

Ini alur kerja yang paling sering dipakai. Mulailah selalu dari dashboard Error & Peringatan.

Baca dari kiri ke kanan:

Jumlah ERROR — total pesan error pada rentang waktu aktif. Bandingkan dengan hari biasa; lonjakan mendadak adalah sinyal utama.
Jumlah WARN — total peringatan. Biasanya lebih banyak dari error dan sering kali wajar.
ERROR per waktu — grafik garis. Bentuk grafik lebih penting daripada angkanya. Lonjakan tajam menandakan insiden pada waktu tertentu; garis datar tinggi menandakan masalah yang terus berulang.
ERROR per container — diagram batang. Batang tertinggi menunjukkan container mana yang paling bermasalah. Inilah tempat Anda menentukan langkah berikutnya.

Gulir ke bawah untuk melihat isi pesannya:

Perhatikan pola, bukan satu-satu. Pada contoh di atas, pesan Warning: Token audience doesn't match expected client muncul berulang di beberapa service sekaligus (report, notification, integration, tenant). Pola lintas-service seperti ini menandakan masalah pada komponen bersama — dalam kasus ini konfigurasi token — bukan bug pada satu service.

Satu pesan error yang muncul sekali biasanya tidak berarti apa-apa. Yang perlu ditindaklanjuti adalah pesan yang berulang, meningkat, atau muncul di banyak service sekaligus.

5. Fokus ke Satu Service

Setelah tahu service mana yang bermasalah, buka dashboard service tersebut, misalnya Service: report.

Tab Semua menampilkan ringkasan gabungan: total pesan, jumlah ERROR, volume per waktu, dan tabel rincian per container. Tabel ini berguna untuk membandingkan container yang sama di dua stack — pada contoh di atas terlihat alurkerja-onprem-onprem-report-1 jauh lebih ramai daripada javan-prod-onprem-report-1.

Klik tab nama container (javan-prod atau alurkerja) untuk membaca lognya secara langsung:

Di tab ini, tiga angka ringkas berada di baris atas, dan daftar log menempati sisa layar — dirancang untuk membaca, bukan menganalisis. Gulir daftar tersebut untuk menelusuri kejadian secara berurutan.

6. Pencarian Manual

Jika dashboard belum cukup, gunakan menu Search untuk mencari bebas.

Ketik query pada kolom pencarian lalu tekan Enter atau klik ikon kaca pembesar.

Sintaks dasar

Query	Arti
`ERROR`	Cari kata `ERROR` di seluruh isi pesan
`message:ERROR`	Sama, tapi dibatasi hanya pada field `message`
`container_name:"javan-prod-onprem-report-1"`	Hanya dari satu container. Tanda kutip wajib karena nama mengandung tanda hubung
`message:ERROR AND container_name:"javan-prod-onprem-auth-1"`	Gabungan dua syarat
`message:(ERROR OR Exception OR FATAL)`	Salah satu dari beberapa kata
`NOT message:INFO`	Kecualikan kata tertentu

Query siap pakai

Semua error dalam satu stack:

message:(ERROR OR Exception OR FATAL) AND container_name:"javan-prod-onprem-report-1"

Menelusuri satu masalah spesifik:

message:"bpm_sla_task_instances"

Semua warning kecuali yang sudah diketahui dan diabaikan:

message:WARN AND NOT message:"Token audience"

Wildcard di awal kata tidak berfungsi pada instance ini. Query seperti container_name:*camunda* akan mengembalikan hasil kosong, bukan pesan error — sehingga mudah disalahartikan sebagai "tidak ada log". Gunakan nama lengkap dalam tanda kutip, atau wildcard di akhir saja seperti container_name:javan-prod*.

7. Membaca Satu Baris Log

Klik salah satu baris pesan untuk membuka detailnya.

Field yang perlu dipahami:

Field	Arti
`timestamp`	Waktu pesan diterima Graylog
`container_name`	Nama container asal — field paling penting untuk tahu service mana yang bicara
`container_id`	12 karakter pertama ID container Docker
`source`	Nama server asal (`javan-prod`)
`message`	Isi log apa adanya, sama persis dengan keluaran `docker logs`

Tombol yang tersedia di detail pesan:

Show surrounding messages — menampilkan log sesaat sebelum dan sesudah pesan ini. Ini tombol paling berguna saat menyelidiki error, karena penyebab sebenarnya biasanya tertulis beberapa baris sebelumnya.
Permalink — tautan permanen ke pesan tersebut, bisa dibagikan ke rekan.
Copy message — menyalin isi pesan.

8. Mengatur Rentang Waktu

Kotak waktu berada di kiri atas, bertuliskan misalnya From: 30 minutes ago — Until: Now. Klik untuk mengubahnya.

Rentang	Gunakan untuk
5–30 menit	Memeriksa masalah yang sedang berlangsung
1–4 jam	Menelusuri insiden yang baru saja terjadi
1 hari	Melihat pola harian atau service yang jarang menulis log

Jika sebuah dashboard tampak kosong, periksa rentang waktunya lebih dulu sebelum menyimpulkan tidak ada log. Service yang sepi seperti keycloak hanya menulis beberapa pesan per hari, sehingga jendela 1 jam akan selalu kosong. Dashboard Service: keycloak sudah disetel 24 jam karena alasan ini.

9. Contoh Nyata: Menelusuri Error

Berikut alur penelusuran yang menghasilkan temuan sungguhan pada sistem ini.

Langkah 1. Buka dashboard Error & Peringatan, rentang 30 menit. Terlihat 475 ERROR.

Langkah 2. Lihat diagram ERROR per container. Batang tertinggi: javan-prod-onprem-integration-1, javan-prod-postgres-1, javan-prod-onprem-app-fe-new-1.

Langkah 3. Buka menu Search, jalankan message:ERROR. Terlihat tiga pola berulang:

ERROR: relation "bpm_sla_task_instances" does not exist (SQLSTATE 42P01)
ERROR: column "process_key" of relation "notification_log" does not exist (SQLSTATE 42703)
ERROR: there is no unique or exclusion constraint matching the ON CONFLICT specification (SQLSTATE 42P10)

Langkah 4. Ketiganya adalah error PostgreSQL bertipe objek tidak ditemukan — tabel hilang, kolom hilang, constraint hilang. Pola seperti ini mengarah ke satu kesimpulan: skema database tertinggal dari versi kode, yaitu migrasi belum dijalankan sepenuhnya.

Langkah 5. Gunakan Show surrounding messages pada salah satu pesan untuk melihat operasi apa yang sedang berjalan saat error terjadi, lalu teruskan ke tim yang menangani migrasi.

Inti alurnya: dashboard menunjukkan di mana, search menunjukkan apa, surrounding messages menunjukkan mengapa.

10. Hal yang Perlu Diketahui

Log tidak disimpan selamanya. Indeks dibatasi 8 GB dengan rotasi per 1 GB. Saat batas tercapai, indeks tertua dihapus otomatis. Lama penyimpanan tergantung volume log — semakin ramai log, semakin pendek riwayat yang tersimpan. Untuk arsip jangka panjang, log harus diekspor terpisah.

Satu baris log = satu pesan. Docker menulis log per baris, sehingga keluaran multi-baris seperti stack trace Java atau query SQL akan terpecah menjadi beberapa pesan terpisah. Gunakan Show surrounding messages untuk merangkainya kembali.

Semua container di server ikut terkirim, bukan hanya service Alurkerja. Container milik project lain di server yang sama juga muncul di Graylog.

Menambah container baru. Container baru tidak otomatis mendapat dashboard sendiri, meskipun lognya tetap masuk dan bisa dicari lewat menu Search. Hubungi administrator untuk menambahkan dashboard service.

11. Jika Log Tidak Muncul

Periksa berurutan:

Rentang waktu — penyebab paling sering. Lebarkan menjadi 1 hari.
Ejaan query — nama container harus lengkap dan dalam tanda kutip. Ingat wildcard di awal kata tidak berfungsi.
Apakah semua log berhenti atau hanya satu service? Buka dashboard Ikhtisar Log Docker. Jika seluruhnya kosong, masalahnya pada pengiriman log, bukan pada aplikasi.
Angka in/out di kanan atas — jika terus 0 selama beberapa menit, pengiriman log terhenti. Laporkan ke administrator.

Log Monitoring (Graylog)

On this page