Grafana di Production: Dashboard Observability, Alerting, dan Provisioning

Grafana sering diperkenalkan sebagai alat untuk membuat dashboard. Deskripsi itu benar, tetapi terlalu sempit. Di production, masalah terbesar biasanya bukan tidak adanya grafik, melainkan grafik yang tidak membantu mengambil keputusan ketika service mulai lambat, error rate naik, atau disk hampir penuh.

Dashboard yang baik menjawab pertanyaan operasional secara cepat: apakah pengguna terdampak, komponen mana yang menjadi penyebab, sejak kapan masalah terjadi, dan tindakan apa yang aman dilakukan. Grafana adalah lapisan visualisasi dan alerting di atas data observability; kualitas hasilnya tetap bergantung pada metric, log, trace, label, dan desain ownership yang berada di belakangnya.

Grafana menyelesaikan bagian mana dari observability?

Grafana dapat membaca data dari banyak data source, lalu menyajikannya dalam dashboard, Explore, panel, dan alert. Contoh kombinasi yang umum adalah Prometheus untuk metrics, Loki untuk logs, Tempo untuk traces, dan PostgreSQL atau Elasticsearch untuk data tertentu. Grafana tidak otomatis mengumpulkan semua data tersebut. Collector dan storage tetap harus dirancang terpisah.

Pemisahan ini penting ketika melakukan troubleshooting. Jika dashboard kosong, penyebabnya bisa query salah, label berubah, collector berhenti, retention habis, permission data source salah, atau memang service tidak menghasilkan data. Grafana hanya menampilkan hasil query yang tersedia; ia bukan bukti bahwa sistem sedang sehat.

Arsitektur minimal yang dapat dirawat

Arsitektur sederhana biasanya terdiri dari aplikasi atau host yang menghasilkan telemetry, collector seperti Prometheus atau Alloy, storage metrics/logs/traces, lalu Grafana sebagai query dan presentation layer. Alert dapat dikelola oleh Grafana Alerting atau diteruskan ke Alertmanager, tergantung kebutuhan routing dan deduplikasi.

Untuk lab, semua komponen dapat berjalan pada satu host Docker. Untuk production, pisahkan storage dari Grafana jika volume data dan query sudah besar. Grafana sendiri relatif ringan dibanding backend observability, tetapi dashboard yang memiliki banyak panel dan query berat tetap dapat menghabiskan CPU serta koneksi ke data source.

Memilih data source: Prometheus, Loki, dan Tempo

Prometheus cocok untuk metrics time series dengan label yang terkontrol. Ia efektif untuk request rate, latency histogram, error count, CPU, memory, queue depth, dan saturation. Tantangan utamanya adalah cardinality. Label seperti user_id, UUID request, atau URL mentah dapat menciptakan series dalam jumlah besar dan membuat storage maupun query mahal.

Loki menyimpan log yang dapat dicari dengan pendekatan label dan isi log. Label harus tetap rendah cardinality; jangan menjadikan setiap identifier unik sebagai label. Simpan nilai detail di body log dan gunakan structured logging agar filter tetap dapat dilakukan tanpa membebani index.

Tempo atau backend tracing membantu menghubungkan request dengan dependency yang lambat. Trace tidak menggantikan metrics. Metrics memberi sinyal bahwa latency naik, sedangkan trace membantu menemukan span mana yang memakan waktu. Ketiganya saling melengkapi, tetapi setiap data type memiliki biaya storage dan retention yang berbeda.

Dashboard yang berguna dimulai dari pertanyaan

Jangan mulai dari layout empat kolom. Mulai dari persona dan pertanyaan. On-call membutuhkan overview dan signal yang bisa ditindaklanjuti. Platform engineer membutuhkan saturation, capacity, dan dependency. Product owner mungkin hanya membutuhkan availability dan dampak pengguna. Satu dashboard yang mencoba memenuhi semua kebutuhan biasanya terlalu padat untuk semuanya.

Dashboard service production yang sehat umumnya memiliki urutan dari dampak ke penyebab:

1. Availability dan request success rate.
2. Traffic serta jumlah request.
3. Latency p50, p95, dan p99.
4. Error rate berdasarkan status atau error class.
5. Dependency: database, queue, cache, dan third-party API.
6. Resource saturation: CPU, memory, disk, connection pool, dan queue depth.

Gunakan unit dan range waktu yang konsisten. Panel latency tanpa unit milliseconds, panel disk tanpa total capacity, dan panel error tanpa denominator sering menyesatkan. Sebuah angka baru bermakna jika operator tahu baseline, target, dan dampaknya.

Query dan label: detail kecil yang menentukan biaya

Metrics yang baik memiliki nama dan label yang stabil. Untuk HTTP, gunakan route template seperti /users/:id, bukan path mentah yang berisi ID. Untuk status, bedakan class atau kode sesuai kebutuhan. Label service, environment, region, dan instance biasanya berguna; label yang jumlah nilainya terus tumbuh biasanya perlu dicurigai.

sum by (service) (rate(http_requests_total{environment="production"}[5m]))

Query di atas lebih berguna untuk overview dibanding panel yang menampilkan setiap endpoint dan instance sekaligus. Detail dapat diturunkan melalui dashboard drill-down atau Explore ketika incident sedang berlangsung. Hindari membuat semua detail tampil di halaman pertama karena operator akan kesulitan menemukan signal utama.

Alerting: deteksi masalah, bukan mengulang isi dashboard

Alert rule harus memiliki kondisi, durasi, severity, owner, dan tindakan. Alert “CPU di atas 80 persen” mungkin berguna pada workload tertentu, tetapi tidak universal. CPU tinggi bisa normal saat batch job; CPU rendah juga tidak berarti service sehat jika request menumpuk di dependency.

Lebih baik alert berdasarkan gejala pengguna dan saturation. Contohnya error budget burn, request error ratio, queue backlog yang terus meningkat, database connection pool hampir habis, atau disk yang diproyeksikan penuh dalam waktu tertentu. Resource alert tetap penting, tetapi perlu konteks agar tidak menjadi alarm palsu.

Tambahkan runbook URL atau instruksi singkat pada annotation alert. Operator yang menerima alert pada pukul tiga pagi membutuhkan konteks, bukan hanya nama query. Alert juga harus memiliki grouping dan repeat interval yang masuk akal agar satu incident tidak berubah menjadi ratusan notifikasi.

Provisioning agar konfigurasi tidak hilang

Mengedit dashboard dan data source hanya melalui UI cepat untuk eksperimen, tetapi berisiko ketika instance harus direbuild atau dipindahkan. Grafana mendukung provisioning data source, dashboard, dan resource alerting melalui file konfigurasi. Simpan konfigurasi non-secret di repository, sementara password, token, dan secure setting masuk secret store atau environment runtime.

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
    editable: false

Provisioning membuat perubahan dapat direview, tetapi jangan menganggapnya sebagai backup lengkap. Uji startup dari kondisi kosong, pastikan UID data source stabil, dan dokumentasikan urutan dependency. Jika dashboard di-import tanpa UID yang konsisten, panel dapat kehilangan referensi data source.

Security boundary Grafana

Grafana adalah konsol administratif, bukan halaman publik biasa. Gunakan HTTPS, session policy yang sesuai, dan identity provider jika organisasi sudah memiliki SSO. Berikan role Viewer, Editor, dan Admin sesuai kebutuhan. Sebagian besar operator tidak memerlukan akses Admin.

Perhatikan permission pada data source. Akses read-only ke metrics bukan berarti aman jika metrics berisi label sensitif atau endpoint internal. Log dapat memuat token, email, payload, atau data pribadi. Redaksi harus dilakukan sebelum data masuk backend, bukan hanya dengan menyembunyikan panel.

Jangan menaruh credential database langsung di query atau dashboard variable. Gunakan secure data source setting, batasi network access dari Grafana ke backend, dan audit perubahan dashboard serta alert rule. Dashboard yang dapat diedit semua orang akan sulit dipercaya ketika digunakan sebagai bukti incident.

Docker Compose untuk lab yang tidak menipu

Compose cocok untuk memvalidasi query dan membangun kebiasaan provisioning. Contoh berikut hanya menggambarkan service Grafana dan Prometheus pada jaringan internal. Untuk production, tambahkan volume persisten, backup provisioning, reverse proxy, healthcheck, resource limit, dan strategi upgrade.

services:
  grafana:
    image: grafana/grafana:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
      - ./provisioning:/etc/grafana/provisioning:ro
    depends_on:
      - prometheus

  prometheus:
    image: prom/prometheus:latest
    restart: unless-stopped
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus_data:/prometheus

volumes:
  grafana_data:
  prometheus_data:

Tag latest hanya cocok untuk eksperimen. Pada production, pin versi image dan uji upgrade pada environment terpisah. Binding ke loopback pada contoh mencegah port dashboard dibuka langsung ke jaringan; akses publik seharusnya melewati reverse proxy dengan TLS dan policy autentikasi.

Investigasi saat dashboard kosong atau lambat

Mulai dari layer paling bawah. Pastikan exporter atau aplikasi menghasilkan data. Lanjutkan ke collector dan periksa scrape error. Setelah itu query langsung ke backend, bukan hanya melalui panel Grafana. Jika query langsung berhasil, periksa time range, variable, permission, dan transformation pada dashboard.

Untuk dashboard lambat, lihat query inspector dan kurangi range waktu, jumlah panel, serta resolusi data. Gunakan recording rule untuk query yang mahal dan berulang. Hindari auto-refresh terlalu agresif. Dashboard yang refresh setiap lima detik dapat menghasilkan beban besar tanpa memberi informasi lebih baik bagi manusia.

Alternatif dan trade-off

Grafana OSS memberi kontrol dan fleksibilitas, tetapi tim harus mengurus upgrade, backup, authentication, storage, dan on-call platform. Grafana Cloud mengurangi beban operasi dan menyediakan layanan terkelola, tetapi biaya ingestion, retention, dan vendor dependency perlu dihitung.

Untuk lingkungan yang hanya membutuhkan uptime sederhana, layanan monitoring terkelola mungkin lebih ekonomis daripada membangun seluruh metrics stack. Untuk organisasi yang sudah memiliki platform Prometheus-compatible, Grafana biasanya menjadi pilihan alami. Tidak ada alasan memindahkan semua data ke Grafana; pilih backend sesuai bentuk data dan kebutuhan query.

Checklist sebelum dashboard masuk production

• Setiap panel memiliki pertanyaan operasional yang jelas.
• Metric name dan label memiliki kontrak yang terdokumentasi.
• Cardinality dipantau dan label unik tidak digunakan sembarangan.
• Data source menggunakan permission minimum dan koneksi terenkripsi.
• Dashboard serta alert rule diprovision atau di-backup.
• Alert memiliki owner, severity, grouping, dan runbook.
• Time range, unit, threshold, dan denominator sudah diuji dengan traffic nyata.
• Grafana memiliki healthcheck, backup, dan prosedur upgrade.
• Query berat diuji sebelum dipasang pada auto-refresh.

Practical takeaways

• Grafana bukan sistem observability lengkap tanpa collector dan backend data yang benar.
• Mulai dari pertanyaan incident dan dampak pengguna, lalu pilih panel.
• Jaga cardinality Prometheus dan label Loki sejak awal.
• Alert harus menghasilkan tindakan, bukan hanya menampilkan angka merah.
• Provisioning membuat konfigurasi dapat direview dan dipulihkan.
• Dashboard production perlu security boundary, backup, healthcheck, dan upgrade plan.
• Gunakan Grafana OSS, Grafana Cloud, atau platform lain berdasarkan kapasitas tim dan biaya operasi.

Referensi

• Grafana documentation
• Grafana data sources
• Grafana Alerting
• Provision Grafana