Belajar Observability dengan LGTM Stack - Performance Testing & Benchmarking

#Pendahuluan

Membangun observability di lingkungan kecil itu mudah. Pertanyaannya selalu sama: apakah stack ini tahan saat trafik 10 kali lipat? Jawabannya tidak bisa ditebak — harus diuji.

Episode ini membahas load testing aplikasi dengan k6, benchmarking stack observability dengan avalanche dan loggen, penetapan baseline performa, serta capacity testing dengan skenario stress, soak, dan spike.

#Load Testing dengan k6

#k6 dan Grafana

k6 adalah alat load testing open-source yang terintegrasi langsung dengan ekosistem Grafana:

• Prometheus remote write dari k6: metrik pengujian dikirim ke Mimir.
• Real-time performance dashboards: hasil uji tampil live di Grafana.
• Correlating load dengan system metrics: bandingkan beban sintetis dengan metrik sistem.

k6 run --out=prometheus-remote-write \
  --server-url=http://localhost:9009/api/v1/push \
  script.js

Perintah k6 run --out=prometheus-remote-write mengirim metrik pengujian langsung ke Mimir untuk dianalisis di Grafana.

#Contoh Skrip k6

script.js - skenario k6

import http from "k6/http";
import { check, sleep } from "k6";
 
export const options = {
  vus: 50,
  duration: "5m",
};
 
export default function () {
  const res = http.get("http://checkout:8080/health");
  check(res, { "status 200": (r) => r.status === 200 });
  sleep(1);
}

Konfigurasi vus: 50 menjalankan 50 virtual user selama 5 menit terhadap endpoint yang diuji.

#Benchmarking Stack Observability

#Alat Khusus per Jenis Data

LGTM Stack sendiri perlu diuji dengan alat yang tepat:

• avalanche: menguji ingestion metrik Mimir dengan volume sampel besar.
• loggen: mengirim log sintetis ke Loki.
• trace generation tools: menghasilkan trace buatan untuk Tempo.
• Query performance testing: menguji kecepatan query berat secara berulang.

avalanche --remote-write-url http://localhost:9009/api/v1/push \
  --metric-count 1000 --series-count 100000

Perintah avalanche di atas mensimulasikan 1000 metrik dengan 100000 deret waktu — menguji seberapa jauh batas ingestion Mimir.

#Mengukur Kinerja Query

Selain ingestion, query perlu diuji: jalankan query berat berulang, catat durasi, lalu bandingkan sebelum dan sesudah optimasi. Grafana Query inspector membantu melihat durasi tiap query.

#Menetapkan Baseline Performa

Sebelum capacity testing, tetapkan baseline yang jelas:

• Ingestion rates: berapa sampel per detik yang mampu diproses.
• Query latencies: waktu respon query normal pada beban wajar.
• Resource utilization: penggunaan CPU dan memori tiap komponen.
• Storage growth rates: kecepatan pertumbuhan storage per volume data.

baseline:
  ingestion: 500k sampel/detik
  query_p95: 300ms
  storage: 40GB/hari

Dokumentasi baseline inilah yang dipakai membandingkan hasil pengujian selanjutnya.

#Capacity Testing

#Tiga Skenario Utama

• Stress testing: beban naik terus sampai stack gagal — mencari batas maksimal.
• Soak testing: beban wajar dalam waktu lama — mencari kebocoran memori dan degradasi bertahap.
• Spike testing: lonjakan mendadak — menguji kemampuan menyerap puncak trafik.

stress: naik terus hingga gagal
soak:  stabil dalam waktu lama
spike: lonjakan tiba-tiba lalu turun

Pola stress: naik terus hingga gagal menentukan limit skalabilitas stack kalian — data penting untuk capacity planning di episode 35.

#Penutup

Di episode 32 ini kalian memahami load testing dengan k6 dan remote write ke Mimir, benchmarking stack dengan avalanche, loggen, dan generator trace, penetapan baseline performa, serta capacity testing dengan skenario stress, soak, dan spike.

Inti yang harus dibawa pulang:

• k6 mengirim metrik uji langsung ke Mimir.
• avalanche, loggen, dan generator trace menguji backend LGTM.
• Baseline performa adalah pembanding untuk semua pengujian.
• Stress, soak, dan spike menjawab pertanyaan kapasitas berbeda.
• Uji di environment terpisah, bukan produksi.

Di episode 33 selanjutnya kita akan membahas security dan compliance — enkripsi TLS, autentikasi dan otorisasi, keamanan data PII di log, kepatuhan GDPR, serta manajemen kerentanan di container dan dependensi. Stack observability menyimpan banyak data sensitif — melindunginya adalah prioritas.