Belajar Observability dengan LGTM Stack - LogQL - Loki Query Language

#Pendahuluan

Loki menyimpan log, dan untuk membacanya kalian butuh bahasa query: LogQL. Berbeda dari bahasa query pada umumnya, LogQL bekerja dalam dua lapisan — memilih aliran log berdasarkan label, lalu memfilter dan memparsing isi baris di dalam aliran tersebut.

Episode ini membangun kemampuan LogQL dari nol: stream selector, line filter, parser expression, metrik log, sampai teknik optimasi. Dengan LogQL, kalian bisa mengubah kumpulan log mentah menjadi jawaban — berapa error dalam satu jam, atau berapa latency rata-rata per service.

#LogQL Basics

#Stream Selector dan Label Matcher

Setiap query LogQL dimulai dengan memilih aliran log menggunakan label:

{job="checkout"}
{service="payment", level="error"}
{job=~"checkout|cart"}

Notasi {job="checkout"} sama konsepnya dengan selector label Prometheus — gabungan matcher =, !=, =~, dan !~ untuk label.

#Line Filter

Setelah memilih aliran, kalian bisa memfilter baris berdasarkan isinya:

{job="checkout"} |= "error"
{job="checkout"} |~ "timeout|refused"
{job="checkout"} != "debug"

Operator |=, |~, !=, dan !~ memfilter baris tanpa parsing. {job="checkout"} |= "error" mengembalikan hanya baris yang mengandung kata error.

#Parser Expressions

Untuk membaca field dari log terstruktur, gunakan parser:

#JSON dan Logfmt

{job="checkout"} |= "error" | json
{job="checkout"} | json level="lvl" | lvl="error"
{job="checkout"} | logfmt

Parser json mengekstrak semua field JSON menjadi label query sementara. Bisa juga dipetakan ulang seperti json level="lvl" agar nama field konsisten.

#Pattern Parser

Untuk log semi-terstruktur, gunakan parser pattern:

{job="api"} | pattern "<method> <path> <status> <duration>"

Parser pattern memakai template posisi untuk mengekstrak field. Pola ini sangat efisien untuk log akses server.

#Log Queries dan Metric Queries

#Dua Tipe Query

LogQL memiliki dua hasil:

• Log query: mengembalikan baris log, misalnya {job="checkout"} |= "error".
• Metric query: mengembalikan deret waktu dari perhitungan log, dibungkus fungsi agregasi.

#Stream Aggregation

Fungsi metrik log yang paling sering dipakai:

count_over_time({job="checkout"} |= "error" [5m])
rate({job="checkout"} |= "error" [5m])
bytes_over_time({job="checkout"} [5m])

Query count_over_time({job="checkout"} |= "error" [5m]) menghitung jumlah baris error dalam 5 menit — persis seperti pola RED errors.

#Unwrap dan Agregasi Lanjutan

Untuk menghitung nilai numerik dari field log, gunakan unwrap:

avg_over_time({job="api"} | json | unwrap duration [5m])
sum(rate({job="api"} | json | unwrap duration [5m]))

Kombinasi | json | unwrap duration mengekstrak field duration lalu menghitung statistiknya — mirip histogram dari data log.

#Advanced LogQL

#Label Formatting dan Binary Operations

LogQL bisa menulis ulang label dengan label_format dan menggabungkan dua query dengan operator binary:

{job="checkout"} | label_format env=service_name
sum(rate({service="payment"} [5m])) / sum(rate({service="orders"} [5m]))

Hasil binary operation bisa digabungkan dengan variabel templating Grafana untuk dashboard dinamis.

#Optimasi Performa

Beberapa kebiasaan agar query LogQL tetap cepat:

• Gunakan label yang tepat di stream selector — semakin sedikit data yang dilalui, semakin cepat.
• Batasi time range — jangan query seminggu penuh tanpa kebutuhan.
• Filter baris sebelum parsing — |= "error" lebih murah daripada parse lalu filter.
• Manfaatkan caching hasil agregasi untuk query yang dipakai berulang.

#Penutup

Di episode 10 ini kalian menguasai LogQL: memilih aliran dengan stream selector, memfilter baris dengan operator filter, mengekstrak field dengan parser json, logfmt, dan pattern, menghitung metrik dari log, serta menerapkan teknik optimasi performa.

Inti yang harus dibawa pulang:

• Query LogQL selalu dimulai dari stream selector label.
• Line filter lebih murah daripada parsing.
• Parser json, logfmt, dan pattern mengekstrak field dari isi log.
• Metric query mengubah log menjadi deret waktu.
• Batasi label, time range, dan data sebelum parsing.

Di episode 11 selanjutnya kita akan membahas mengumpulkan log dengan Grafana Alloy — pengganti Grafana Agent, arsitektur komponen berbasis River, metode koleksi dari file dan Docker, proses parsing dan enrichment, hingga pengiriman log ke Loki dengan remote write. Query LogQL kalian akan segera punya sumber data yang terus mengalir.