Heii guys! Ini adalah artikel pembuka dari beberapa series tentang arsitektur logging di Kubernetes pake. Di artikel ini lebih nekanin seputar logging di Kubernetes dan tantangan2nya.

Pentingnya Logging

Logging merupakan suatu sumber data yang mencatat detil tentang apa yang terjadi di dalam aplikasi atau infrastruktur kita. Dengan log, kita bisa menggunakannya untuk mendapatkan diagnosis dan insigth dari sistem kita, misalnya , ada error log yang bisa nunjukin di mana masalahnya, atau log akses yang bisa kasih tau kita pola pemakaian sistem. Logging ini juga krusial dalam ngasih real-time analysis dan historical data, yang mana bisa bantu kita buat ngambil keputusan yang tepat untuk development. It’s like having a detailed journal of your system’s life, yang mana bisa kalian pake buat bikin sistem yang lebih reliable dan perform better.

Tantangan Logging di Kubernetes

Di Kubernetes, aplikasi terdistribusi menjadi banyak pods yang terus-menerus berganti. Nah, ini bikin tracking log jadi kayak nyari jarum di tumpukan jerami. Plus, setiap pod punya lifecycle-nya sendiri, jadi log yang dihasilkan bisa hilang ketika pod tersebut di-restart atau di-terminate. Masalah lain muncul dari sisi format log, tiap aplikasi bisa jadi punya format log yg berbeda-beda, yang bikin proses analisis log jadi tambah rumit. Ini bakal semakin rumit kalo kalian punya banyak node.

Kebutuhan

So dari uraian masalah di atas, bisa disimpulin kebutuhanya yaitu:

1. Bagaimana cara keep lognya meskipun pod2nya udah gk ada
2. Bagaimana cara mengekstrak beberapa informasi2 penting aja dari entri log tersebut

Untuk memenuhi kebutuhan di atas, untungnya Kubernetes udah ngasih dokumentasi yang lengkap banget tentang logging architecture.

Dari berbagai arsitektur yg dijelasin di dokumentasi resmi tersebut, aku milih arsitektur logging di level kluster, persisnya dengan nyebarin agen log ditiap-tiap node. Ku rasa ini lebih simple daripada nyebarin sidecar container di tiap2 pod.

Agen Log di Level Node

Default logging di Kubernetes, tiap node yang disetup pakek systemd bakal nulis log entrinya ke journald, merupakan salah satu bagian dari systemd yg tugasnya ngumpulin semua log dari layanan systemd yang lagi jalan. Filenya bisa kalian temuin di folder /var/log/journal/ dengan ekstensi .journal. Log-log di Kubernetes ini persisnya ditulis oleh Kubelet dan Container runtime, yang notabene adalah komponen penting di Kubernetes.

Mekanismenya bakal beda lagi kalo kalian install node Kubernetesnya di dalam container yg gak punya systemd, biasanya install nodenya pakek semacam tools Minikube, Kind. Kubelet dan container runtime langsung nulis file lognya di folder /var/log/.

Karena semua file lognya bakal tersedia di filesystemnya node, make sense kalo kita mau ngambil lognya dan ngepush semuanya ke suatu tempat pake agen log di level node. Agen log ini kerjanya bakal ngescan direktori log, ngumpulin semua data log, terus ngepush ke pusat penyimpanan log, yang bisa berupa layanan cloud atau server log terpusat. Ini ngasih kita banyak keuntungan:

• Pertama, kita jadi bisa ngelacak dan menganalisis log dari seluruh kluster dengan lebih mudah.
• Kedua, ini ngebantu dalam hal redundancy dan disaster recovery, karena semua log disimpan di tempat yang aman dan terpusat.
• Terakhir, dengan semua log di satu tempat, kita bisa lebih gampang implementasi real-time monitoring dan alerting.

Penutup

Jadi, itulah gambaran umum tentang tantangan dan solusi logging di Kubernetes. Kita udah ngomongin logging di Kubernetes dan kenapa agen log di level node itu jadi pilihan yang mantap. Di artikel selanjutnya, kita bakal masuk ke tahap implementasi, ngulik gimana cara set up arsitektur logging pake Fluentd dan Grafana Loki. Fluentd bakal kita pake buat ngumpulin dan forward log, sementara Grafana Loki bakal jadi tempat kita ngeanalisis dan nampilin log-log tersebut.