Membangun Observability GBIM: Metrics Bisnis, Correlation ID, dan k6 Smoke Test

Judul

Membangun Observability GBIM: Metrics Bisnis, Correlation ID, dan k6 Smoke Test

Ringkasan

Iterasi monitoring GBIM akhirnya difokuskan pada tiga hal yang benar-benar bisa dibuktikan dari implementasi saat ini: custom metrics Prometheus, correlation ID end-to-end, dan k6 smoke test yang mengirim telemetry ke Prometheus/Grafana. Frontend juga menambahkan analytics event GA4 sebagai sinyal aktivitas pengguna, tetapi bukti utama untuk CPL 6 tetap berada pada Prometheus, Grafana, k6, dan log request.

Masalah Awal

Sebelum perubahan monitoring ini, stack Prometheus dan Grafana sudah ada, tetapi bukti observability masih kurang kuat:

• Endpoint metrics masih lebih banyak menampilkan telemetry HTTP generik, belum banyak outcome bisnis GBIM.


• Dashboard k6 masih berisiko kosong karena belum ada alur yang konsisten untuk menjalankan k6 dan menulis hasilnya ke Prometheus remote write.


• Request dari frontend ke backend belum mudah ditelusuri saat error karena correlation ID belum konsisten dibawa, divalidasi, dan dikembalikan.


• Aktivitas penting pengguna seperti registrasi, aktivasi akun, verifikasi akun admin, dan update status pengajuan belum punya sinyal monitoring yang eksplisit.

Batasan Klaim

Bagian ini penting supaya klaim monitoring sesuai dengan yang benar-benar dikerjakan.

Yang diklaim selesai:

• Backend mengekspos /api/metrics dan custom metric gbm_*.


• Prometheus/Grafana membaca metric backend dan metric k6.


• k6 smoke test tersedia sebagai script dan Kubernetes Job.


• Frontend mengirim X-Correlation-ID, backend memvalidasi/menghasilkan ID, lalu mengembalikannya di response.


• Backend log memakai corr_id melalui logging filter.


• Frontend analytics helper GA4 tersedia dan dibatasi untuk host/environment yang diizinkan.

Solusi yang Dibangun

1. Backend Metrics

Backend menambahkan custom metric Prometheus untuk flow yang penting secara operasional. Metric utama berada di monitoring/metrics.py dan dinaikkan dari flow autentikasi, aktivasi, verifikasi akun admin, serta update status pengajuan admin.

Metric yang menjadi fokus:

• gbm_auth_register_total{role,outcome}


• gbm_auth_activation_total{outcome}


• gbm_auth_reactivation_total{outcome}


• gbm_auth_email_send_duration_seconds{event,outcome}


• gbm_admin_account_verification_total{action,outcome}


• gbm_pengajuan_admin_status_update_total{status,outcome}

Selain itu, beberapa domain lain juga memiliki metric khusus seperti account verification, pengajuan service, kegiatan, dan document upload. Dengan metric ini, Grafana tidak hanya membaca request HTTP, tetapi juga bisa menjawab pertanyaan bisnis seperti:

• Berapa banyak registrasi yang sukses atau gagal validasi?


• Apakah aktivasi akun sering gagal karena token invalid, expired, atau rate limited?


• Apakah admin verification gagal pada list, detail, atau update status?


• Apakah update status pengajuan gagal karena validasi, data tidak ditemukan, atau error service?

2. Correlation ID End-to-End

Frontend menambahkan header X-Correlation-ID dari lib/api.ts pada request API normal dan refresh token. Backend memiliki CorrelationIdMiddleware yang:

1. Membaca header X-Correlation-ID dari request.


2. Menerima nilai yang valid jika berbentuk UUID.


3. Mengganti nilai yang kosong/tidak valid dengan UUID baru.


4. Menyimpan ID ke context logging.


5. Mengembalikan ID yang sama di response header X-Correlation-ID.

Log backend memakai CorrelationIdFilter, sehingga format log memiliki field corr_id. Dampaknya, ketika frontend mendapatkan error dari backend, correlation ID di response bisa langsung dipakai untuk mencari log request yang sama di backend.

4. Frontend Analytics sebagai Sinyal Tambahan

Frontend menambahkan helper lib/analytics.ts untuk mengirim event GA4. Helper ini tidak mengirim event jika window.gtag tidak tersedia, dan hanya aktif jika:

1. 
   NEXT_PUBLIC_GA_MEASUREMENT_ID tersedia.


2. 
   NEXT_PUBLIC_APP_ENV bernilai staging atau production.


3. Host runtime masuk allowlist analytics, misalnya gbim-staging.ppl.cs.ui.ac.id.

Event yang diinstrumentasi:

• 
  register_submitted, register_success, register_failed
  


• 
  activation_verified, activation_expired, activation_used, activation_invalid, activation_rate_limited
  


• 
  reactivation_requested, reactivation_success, reactivation_failed
  


• 
  admin_verification_list_viewed, admin_verification_detail_clicked, admin_verification_status_updated
  


• pengajuan_admin_status_updated

Pada akhir implementasi, pipeline FE juga perlu meneruskan variable analytics ke Docker build karena variable NEXT_PUBLIC_* di Next.js dibaca saat build. Tanpa itu, tag GA tidak muncul di bundle staging walaupun kode analytics sudah ada.

[Placeholder SS-06] GA4 Realtime atau DebugView menampilkan page view/event dari staging setelah variable CI/CD FE terpasang dan frontend dideploy ulang.

Mapping ke CPL 6

Criterion 1: Built-in Platform Monitoring

Monitoring sudah masuk ke lifecycle aplikasi, bukan hanya screenshot manual. Backend mengekspos /api/metrics, Prometheus melakukan scrape, dan Grafana membaca data dari Prometheus. k6 juga dijalankan sebagai Job Kubernetes sehingga telemetry performa bisa masuk ke jalur monitoring yang sama.

Correlation ID memperkuat sisi platform monitoring karena request tidak hanya terlihat secara agregat di metric, tetapi juga bisa ditelusuri sampai log backend. Ini membuat investigasi error lebih operasional: dari error frontend, ambil X-Correlation-ID, lalu cari corr_id yang sama di backend.

Criterion 2: Standard Tool Setup with Live Data

Tool yang digunakan adalah tool standar industri:

• Prometheus untuk metrics.


• Grafana untuk dashboard.


• k6 untuk smoke/load telemetry.


• Django logging dengan correlation ID untuk investigasi request.


• GA4 sebagai sinyal tambahan aktivitas frontend.

Data yang ditampilkan bukan mock statis. Custom metric naik dari flow aplikasi, k6 mengirim metric hasil request synthetic, dan correlation ID muncul dari request yang benar-benar melewati frontend/backend.

Criterion 3: Kustomisasi Sesuai Pekerjaan

Kustomisasi monitoring dibuat berdasarkan flow GBIM yang memang penting:

• Registrasi akun.


• Aktivasi akun.


• Reaktivasi token.


• Verifikasi akun admin.


• Update status pengajuan admin.


• Durasi pengiriman email aktivasi/reaktivasi.

Label seperti role, outcome, action, dan status membuat dashboard bisa membedakan kasus sukses, validasi gagal, duplicate email, token invalid, token expired, not found, server error, dan service error. Ini lebih bermakna daripada hanya melihat CPU, memory, atau HTTP 200/500.

Criterion 4: Advanced Usage

Advanced usage pada implementasi final terletak pada gabungan telemetry performa dan traceability:

• k6 menghasilkan data performa yang masuk ke Prometheus remote write dan bisa divisualisasikan di Grafana.


• Correlation ID menghubungkan request frontend, response backend, dan log backend.


• Custom metrics menjelaskan outcome bisnis, bukan hanya status HTTP.


• Analytics frontend memberi sinyal tambahan untuk aktivitas pengguna di staging/production.

Kesimpulan

Hasil akhir monitoring GBIM bukan sekadar "Grafana sudah ada", tetapi observability yang bisa menjawab pertanyaan operasional:

• Apakah registrasi sering gagal?


• Apakah aktivasi akun bermasalah?


• Apakah verifikasi admin menghasilkan error?


• Apakah update status pengajuan stabil?


• Apakah backend tetap responsif saat diuji k6?


• Request error tertentu bisa dicari di log backend lewat correlation ID apa?

Scope yang benar-benar selesai adalah metrics bisnis, k6 telemetry, correlation ID end-to-end, dan analytics frontend sebagai tambahan.