Belajar Observability dengan LGTM Stack - Logs dengan Loki - Introduction & Architecture

#Pendahuluan

Pillar kedua observability adalah logs — catatan detail tentang apa yang persis terjadi. Namun mengumpulkan log dari ribuan service bukan pekerjaan sepele: volume bisa mencapai terabyte per hari, dan biaya penyimpanan sering kali menjadi beban terbesar.

Grafana Loki hadir menjawab masalah tersebut. Terinspirasi dari desain Prometheus, Loki dirancang sebagai sistem agregasi log yang skalabel horizontal dan hemat biaya, dengan pendekatan penyimpanan yang sama sekali berbeda dari Elasticsearch. Episode ini membahas arsitektur Loki, perbandingannya dengan Elasticsearch, serta format dan strategi parsing log.

#Grafana Loki Overview

#Pendekatan Index-Free

Loki tidak mengindex isi setiap baris log. Sebagai gantinya, ia hanya mengindex label — pasangan key-value yang melekat pada setiap aliran log. Isi baris disimpan apa adanya dalam chunk yang dikompresi.

Keuntungan pendekatan ini sangat besar:

Horizontally scalable: karena tidak ada index raksasa, penambahan kapasitas cukup dengan menambah instance.
S3-compatible storage backend: chunk disimpan ke object storage murah seperti S3, GCS, atau Azure Blob.
Cost-effective: biaya storage jauh lebih rendah dibanding pendekatan full-text indexing.
Inspirasi dari Prometheus: model label, query, dan ekspos metrik mengikuti gaya Prometheus.

Memeriksa versi Loki

docker exec loki /usr/bin/loki --version

Perintah docker exec loki /usr/bin/loki --version menampilkan versi binary di dalam container — kebiasaan kecil yang berguna saat memverifikasi deployment.

#Loki Architecture

Seperti Mimir, Loki memecah alur data menjadi komponen kecil:

Distributor: menerima log dari client, memvalidasi, dan menulis ke ingester.
Ingester: menyimpan log terbaru dalam memori dan menulis chunk ke object storage.
Querier: menjalankan query LogQL dengan menggabungkan data ingester dan storage.
Query-frontend: membagi dan meng-cache query besar agar cepat dijawab.
Compactor: menggabungkan dan membersihkan chunk, serta menerapkan retention.
Index-gateway (opsional): memusatkan akses index pada deployment besar.

Alur log di Loki

client -> distributor -> ingester -> object storage
                          ^              |
query -> query-frontend -> querier <- index-gateway

Diagram distributor -> ingester -> object storage menunjukkan jalur penulisan, sementara jalur query dibantu index-gateway untuk mencari label.

#Loki vs Elasticsearch

#Perbedaan Pendekatan

Indexing: Elasticsearch mengindex hampir semua field log untuk full-text search, Loki hanya mengindex label dan mengandalkan query pada isi chunk.
Biaya: karena tidak mengindex isi, biaya storage Loki jauh lebih rendah — faktor utama keputusan memilih Loki.
Kinerja query: Loki unggul untuk query sederhana dan analisis berbasis label; Elasticsearch unggul untuk full-text search kompleks di isi log.
Kesesuaian use case: Loki cocok untuk observability sistem dan aplikasi; Elasticsearch tetap kuat untuk search engine dan analisis teks mendalam.

Perbandingan singkat

loki: label-first, murah, cocok untuk observability
elasticsearch: full-text, mahal, cocok untuk search

Contoh pola di atas bukan berarti salah satu lebih baik — pilih berdasarkan kebutuhan. loki: label-first menjadi pilihan default di series ini karena biaya.

#Log Formats dan Parsing

#Structured vs Unstructured

Log terstruktur berbentuk JSON atau logfmt sehingga mudah diparsing mesin:

Contoh log terstruktur

{
  "level": "info",
  "ts": "2026-08-10T10:05:11Z",
  "service": "orders",
  "order_id": "ord-1042",
  "msg": "order created"
}

Log tak terstruktur hanyalah teks bebas. Keduanya bisa diterima Loki, tapi log terstruktur jauh lebih mudah dianalisis dengan LogQL di episode 10.

#Strategi Label dan Parsing

Prinsip penting di Loki: label dibatasi, parsing dilakukan saat query. Cukup gunakan beberapa label stabil seperti job, service, dan level; sisanya diparsing dari isi log menggunakan parser LogQL seperti json, logfmt, atau pattern.

Konsep label aliran log

labels:
  job: checkout
  service: payment
  level: error

Konsep labels di atas mirip label Prometheus — selalu pikirkan cardinality sebelum menambahkan label baru.

Info

Kesalahan paling umum pengguna Loki adalah memberi terlalu banyak label. Ingat: label hanya untuk aliran log, sedangkan data dinamis seperti order_id harus tetap berada di isi baris log.

#Penutup

Di episode 9 ini kalian memahami bahwa Loki adalah agregator log index-free yang mengindex label saja, mengenal komponen arsitekturnya dari distributor hingga compactor, membandingkan pendekatannya dengan Elasticsearch, serta memahami pentingnya log terstruktur dan strategi label yang disiplin.

Inti yang harus dibawa pulang:

Loki tidak mengindex isi log, hanya label.
Chunk log disimpan ke object storage sehingga murah.
Distributor, ingester, dan querier adalah komponen inti Loki.
Loki unggul biaya, Elasticsearch unggul full-text search.
Batasi label; parsing dilakukan saat query, bukan saat ingest.

Di episode 10 selanjutnya kita akan membahas LogQL — bahasa query Loki untuk memilih aliran log, memfilter baris, memparsing isi, hingga menghitung metrik dari log seperti rate dan count_over_time. Log yang tersimpan akan segera bisa dijelajahi dengan cepat.