Belajar Observability dengan LGTM Stack - Cost Optimization Strategies

#Pendahuluan

Semakin banyak data telemetry, semakin besar biaya storage, komputasi, dan jaringan. Tanpa strategi, tagihan observability bisa membengkak diam-diam — terutama di era cloud-native yang volume datanya tak kenal lelah.

Episode ini membahas pengendalian biaya di tiga jenis data: metrik, log, dan trace, ditambah optimalisasi biaya infrastruktur. Tujuannya sederhana: observability tetap lengkap, tapi biaya terkendali.

#Optimasi Biaya Metrik

#Kendalikan Cardinality

Cardinality adalah pembunuh biaya metrik yang paling besar. Satu metrik dengan label user_id bisa menciptakan jutaan deret waktu.

• Cardinality reduction: hapus label bernilai tinggi dari metrik.
• Recording rules: agregasi berat dihitung sekali, bukan setiap query.
• Retention tuning: turunkan retention untuk metrik bernilai rendah.
• Sampling non-critical metrics: kumpulkan metrik sekunder dengan interval lebih panjang.
• Remote write filtering: filter di sisi collector agar data tak berguna tidak pernah dikirim.

prometheus.remote_write "default" {
  endpoint {
    url = "http://mimir:9009/api/v1/push"
  }
}

Kombinasikan remote_write dengan komponen filter untuk memblokir metrik ber-label tinggi sejak di collector.

#Fitur Adaptive Metrics

Mimir menyediakan adaptive metrics yang otomatis menandai deret ber-cardinality tinggi untuk dihapus. Fitur ini dibahas lebih lanjut di episode 35.

Sebagai gambaran kasar: sepuluh metrik berlabel sedang harganya lebih murah daripada satu metrik berlabel tinggi. Karena itu, tinjau label metrik secara berkala dan libatkan pemilik service sebelum menghapus label apa pun — label yang dihapus berarti data historis kehilangan dimensi. Kesepakatan tim jauh lebih baik daripada penghapusan sepihak.

#Optimasi Biaya Log

#Kontrol Label dan Volume

• Label cardinality control: batasi label log seperti yang dibahas di episode 23.
• Log level filtering: jangan kirim DEBUG ke produksi; drop WARN yang tidak berguna.
• Sampling strategies: contohkan log INFO, simpan semua ERROR.
• Retention policies: simpan log terbaru di storage cepat, log lama dipindah atau dihapus.
• Compression tuning: pastikan kompresi aktif di sisi collector.
• Storage tiering: pindahkan chunk lama ke kelas storage murah.

loki.process "sample_info" {
  stage.match {
    selector = "{level=\"info\"}"
    stage.sampling {
      rate = 0.1
    }
  }
}

Aturan stage.sampling rate: 0.1 hanya menyimpan 10 persen log level info — cara paling efektif menekan biaya log tanpa kehilangan konteks error.

#Optimasi Biaya Trace

#Intelligent Sampling

• Intelligent sampling: simpan trace bernilai — error, lambat, atau service prioritas.
• Tail-based sampling: keputusan sampling setelah trace selesai (episode 24).
• Storage retention: turunkan retention untuk trace normal.
• Query optimization: hindari query yang memuat blok besar tanpa perlu.

simpan: error, lambat, service kritis
sampling: trace normal dengan rasio

Pola simpan: error, lambat, service kritis memastikan nilai observability tetap tinggi sambil biaya menurun. Kombinasi sampling di collector dan retention di backend memberi kontrol dua lapis atas biaya trace.

#Biaya Infrastruktur

#Right-Sizing dan Storage

• Right-sizing components: jangan over-provision; ukur beban aktual tiap komponen.
• Object storage cost management: gunakan kelas storage dingin untuk blok lama.
• Network egress optimization: hindari transfer data antar region yang mahal.
• Spot instances: untuk komponen stateless seperti querier dan distributor.
• Reserved capacity: komitmen jangka panjang untuk komponen stateful.

Kombinasi antara sampling yang tepat dan tiering storage biasanya memberikan penghematan terbesar. Prioritaskan penghematan pada jenis data dengan volume paling besar — bagi sebagian besar tim, itu adalah log, bukan metrik atau trace.

Mulailah dari audit kecil: catat lima metrik, lima aliran log, dan lima service dengan biaya terbesar, lalu terapkan satu langkah optimasi untuk masing-masing. Hasilnya lebih terukur daripada mencoba mengoptimalkan semuanya sekaligus.

#Penutup

Di episode 26 ini kalian memahami strategi pengendalian biaya metrik dengan cardinality dan recording rules, biaya log dengan filter, sampling, dan retention, biaya trace dengan intelligent sampling, serta optimalisasi biaya infrastruktur.

Inti yang harus dibawa pulang:

• Cardinality tinggi adalah biaya metrik terbesar.
• Sampling log INFO menekan biaya tanpa kehilangan error.
• Tail-based sampling menyimpan trace yang bernilai.
• Right-sizing dan tiering storage menghemat infrastruktur.
• Ukur biaya observability secara berkala.

Di episode 27 selanjutnya kita akan membahas observability di Kubernetes — arsitektur monitoring node, pod, dan cluster, sumber metrik cAdvisor dan kube-state-metrics, service discovery dan relabeling, koleksi log pod, serta tracing dengan service mesh. LGTM Stack kalian akan naik kelas ke dunia Kubernetes.