Grafana Dashboard #

Kumpulan metrik numerik yang ditarik oleh Prometheus dari seluruh sudut kluster tidak akan memberikan nilai operasional jika tidak dapat divisualisasikan dengan cepat, jelas, dan relevan saat terjadi insiden. Dalam situasi krisis di mana sistem produksi mengalami kegagalan, tim engineer on-call tidak boleh membuang waktu menulis kueri PromQL secara manual di konsol mentah untuk mencari sumber masalah. Kita membutuhkan dasbor visual terintegrasi yang mampu menyajikan kesehatan sistem secara instan. Grafana telah menjadi standar industri untuk visualisasi metrik karena kemampuannya menghubungkan berbagai sumber data (data sources) dan menyajikan dasbor dinamis yang memotong waktu identifikasi masalah (Mean Time to Detect / MTTD) dari hitungan jam menjadi menit.

Hierarki Dasbor Pemantauan (Dashboard Drill-down Pattern) #

Salah satu kesalahan desain dasbor terbesar adalah meletakkan seluruh grafik metrik (mulai dari suhu CPU node master hingga latensi query database mikroservis) ke dalam satu halaman dasbor tunggal yang sangat panjang. Hal ini membebani memori browser pengakses, memperlambat kueri Prometheus, dan membanjiri fokus kognitif manusia dengan informasi yang tidak relevan.

Untuk operasional produksi, kita harus menerapkan pola Drill-down Hierarkis yang terbagi menjadi empat level dasbor terpisah:

flowchart TD
    StartView["1. Dasbor Level 1: Global Cluster Overview"] -->|"Deteksi Anomali Node / Namespace"| NamespaceView["2. Dasbor Level 2: Namespace Overview"]
    NamespaceView -->|"Temukan Service Bermasalah (High Error/Latency)"| ServiceView["3. Dasbor Level 3: Service Detail (Pods & DB)"]
    ServiceView -->|"Klik Titik Anomali Graf (Exemplars)"| TraceView["4. Dasbor Level 4: Tracing Span (Grafana Tempo)"]
    
    subgraph GoldenSignals["Metrik Utama di Setiap Level"]
        direction LR
        Throughput["Traffic (Volume)"]
        Latency["Latency (Response Time)"]
        Errors["Errors (Error Rate %)"]
        Saturation["Saturation (Resource Limit %)"]
    end
    
    NamespaceView -.-> GoldenSignals
    ServiceView -.-> GoldenSignals

Penjelasan Level Dasbor: #

  1. Level 1: Global Cluster Overview: Dasbor tingkat tinggi untuk memantau kapasitas fisik kluster (total CPU, memori, status node worker ready, insiden pod restart / OOM killed). Diperuntukkan bagi tim SRE dan infrastruktur.
  2. Level 2: Namespace Overview: Menyajikan visualisasi perbandingan antar aplikasi di dalam satu namespace. Memvisualisasikan Four Golden Signals secara ringkas untuk mendeteksi aplikasi mana yang mengalami anomali.
  3. Level 3: Service Detail: Dasbor mendalam untuk mendiagnosis satu aplikasi spesifik. Menampilkan metrik internal runtime (seperti GC pauses, thread counts, latensi kueri database spesifik, dan status koneksi eksternal).
  4. Level 4: Tracing details: Pelacakan individual request (Trace ID) untuk menemukan baris kode atau dependensi jaringan yang melambat.

Visualisasi Empat Sinyal Emas (Four Golden Signals Panels) #

Setiap dasbor tingkat aplikasi (Level 2 & 3) wajib menyajikan panel untuk pemantauan empat sinyal emas. Berikut adalah konfigurasi PromQL dan visualisasi optimal untuk masing-masing panel:

1. Latency (Latensi) #

  • Kueri PromQL (p99 & p50): 
    # Latensi p99 (Critical Threshold)
histogram_quantile(0.99, sum by (le, job) (rate(http_request_duration_seconds_bucket{namespace="$namespace", job="$service"}[5m])))
  • Tipe Visualisasi: Time Series.
  • Unit: seconds (s) atau milliseconds (ms).
  • Thresholds: 0s - 0.5s (Hijau), 0.5s - 1.5s (Kuning), >1.5s (Merah).

2. Traffic (Throughput) #

  • Kueri PromQL: 
    sum(rate(http_requests_total{namespace="$namespace", job="$service"}[5m])) by (status_code)
  • Tipe Visualisasi: Time Series dengan tumpukan grafik (stacked area chart) berdasarkan status code (status 2xx berwarna hijau, 4xx biru, 5xx merah).
  • Unit: requests per second (ops).

3. Errors (Tingkat Kesalahan) #

  • Kueri PromQL (Rasio %): 
    sum(rate(http_requests_total{namespace="$namespace", job="$service", status_code=~"5.."}[5m]))
/
sum(rate(http_requests_total{namespace="$namespace", job="$service"}[5m])) * 100
  • Tipe Visualisasi: Stat (Single Stat) untuk menampilkan angka persentase instan berukuran besar.
  • Unit: percent (0-100).
  • Thresholds: 0% - 0.1% (Hijau), 0.1% - 1% (Kuning), >1% (Merah).

4. Saturation (Kejenuhan) #

  • Kueri PromQL (CPU & Memori % terhadap Limit): 
    # Utilisasi memori aktual terhadap limit memori Kubernetes
sum(container_memory_working_set_bytes{namespace="$namespace", container!=""}) by (pod)
/
sum(container_spec_memory_limit_bytes{namespace="$namespace", container!=""}) by (pod) * 100
  • Tipe Visualisasi: Gauge (atau Bar Gauge).
  • Unit: percent (0-100).
  • Thresholds: 0% - 70% (Hijau), 70% - 85% (Kuning), >85% (Merah).

Templating dan Variabel Dinamis (Dynamic Dashboards) #

Kita harus menghindari pembuatan dasbor terpisah untuk setiap aplikasi (misalnya dasbor khusus untuk billing-app-dev, billing-app-prod, inventory-app). Kebiasaan ini memicu ledakan jumlah dasbor (dashboard sprawl) yang tidak terkendali dan menyulitkan pembaruan layout.

Sebagai gantinya, gunakan Template Variables pada dasbor Grafana. Variabel ini menghasilkan menu dropdown dinamis di bagian atas dasbor untuk menyaring visualisasi berdasarkan datasource, namespace, dan nama layanan.

Berikut adalah konfigurasi variabel JSON yang direkomendasikan pada pengaturan dasbor:

{
  "templating": {
    "list": [
      {
        "name": "datasource",
        "type": "datasource",
        "query": "prometheus",
        "label": "Data Source",
        "hide": 0
      },
      {
        "name": "namespace",
        "type": "query",
        "datasource": "${datasource}",
        "query": "label_values(kube_namespace_labels, namespace)",
        "label": "Namespace",
        "multi": false,
        "includeAll": false,
        "refresh": 1
      },
      {
        "name": "service",
        "type": "query",
        "datasource": "${datasource}",
        "query": "label_values(http_requests_total{namespace=\"$namespace\"}, job)",
        "label": "Service Name",
        "multi": false,
        "includeAll": false,
        "refresh": 2
      }
    ]
  }
}

Variabel $namespace dan $service ini kemudian dirujuk langsung di dalam kueri PromQL panel dasbor, seperti http_requests_total{namespace="$namespace", job="$service"}.

Implementasi Dashboard-as-Code via GitOps #

Membuat dan menyunting dasbor langsung menggunakan antarmuka grafis (UI) Grafana adalah anti-pattern yang berbahaya di lingkungan produksi. Jika dasbor dimodifikasi secara manual:

  • Kita kehilangan jejak riwayat perubahan (version control).
  • Dasbor rawan terhapus atau rusak secara tidak sengaja oleh developer lain.
  • Terjadi perbedaan konfigurasi dasbor (config drift) antar kluster.

Kita harus mengelola dasbor sebagai kode (Dashboard-as-Code) dengan menyimpannya sebagai file JSON di repositori Git, lalu mendeploy-nya ke kluster menggunakan objek ConfigMap yang dipantau oleh agen auto-provisioning Grafana.

Manifest Provisioning Dasbor melalui ConfigMap #

Jika kita mendeploy Grafana menggunakan Helm chart kube-prometheus-stack, terdapat kontainer sidecar k8s-sidecar yang secara aktif mencari ConfigMap dengan label khusus dan mengubahnya menjadi dasbor Grafana runtime secara otomatis.

# File: billing-dashboard-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-billing-dashboard
  namespace: monitoring
  labels:
    # Label ini wajib agar dideteksi oleh sidecar kontainer Grafana
    grafana_dashboard: "1"
spec:
  # Konfigurasi opsional untuk memisahkan kategori dasbor di folder Grafana
  annotations:
    grafana_dashboard_folder: "Application Performance"
data:
  # Nama file JSON dasbor
  billing-service-overview.json: |
    {
      "annotations": {
        "list": []
      },
      "editable": false,
      "fiscalYearStartMonth": 0,
      "graphTooltip": 1,
      "id": null,
      "links": [],
      "liveNow": false,
      "panels": [
        {
          "type": "timeseries",
          "title": "Throughput billing-service",
          "gridPos": {
            "h": 8,
            "w": 12,
            "x": 0,
            "y": 0
          },
          "targets": [
            {
              "datasource": "${datasource}",
              "expr": "sum(rate(http_requests_total{namespace=\"$namespace\", job=\"$service\"}[5m])) by (status_code)",
              "refId": "A"
            }
          ]
        }
      ],
      "schemaVersion": 38,
      "style": "dark",
      "tags": ["application", "production"],
      "title": "Billing Service Overview",
      "uid": "billing-app-overview",
      "version": 1
    }

Interkoneksi Metrik ke Traces Menggunakan Exemplars #

Melihat grafik latensi p99 naik tajam memberi tahu kita bahwa ada masalah, tetapi tidak memberi tahu request individual mana yang lambat. Exemplars adalah fitur Prometheus dan Grafana yang mengikat Trace ID distributed tracing langsung ke titik-titik data spesifik pada grafik metrik.

Ketika Exemplars dikonfigurasi:

  1. Dasbor Grafana akan menampilkan titik-titik bintang kecil di dalam chart time series latensi.
  2. Ketika kursor diarahkan ke titik tersebut, detail Trace ID akan muncul.
  3. Kita dapat mengklik Trace ID tersebut untuk membuka visualisasi detail span (Grafana Tempo) secara instan di sisi kanan dasbor.
Visualisasi Aliran Exemplars:

[Grafik Latensi Time Series] ──> Terdapat Anomali Latensi Tinggi (3.5s)
                                       │
                                       ▼ (Arahkan Kursor ke Bintang Exemplar)
                               [Pop-Up Trace ID: 4bf92f3577b3...]
                                       │
                                       ▼ (Klik Link Trace ID)
                        [Drill Down Langsung ke Panel Grafana Tempo]

Konfigurasi Panel dengan Dukungan Exemplars #

Di dalam manifest JSON dasbor Grafana, kita mengaktifkan exemplars pada opsi target query panel:

"targets": [
  {
    "datasource": "${datasource}",
    "expr": "histogram_quantile(0.99, sum by (le, job) (rate(http_request_duration_seconds_bucket{namespace=\"$namespace\"}[5m])))",
    "refId": "A",
    "exemplar": true # Aktifkan visualisasi exemplar
  }
]

Catatan: Pastikan database Prometheus kluster Anda dikonfigurasi dengan flag --enable-feature=exemplars-storage saat startup.

Pemasangan Annotations Alert di Dasbor #

Untuk mempermudah analisis korelasi insiden, kita dapat menampilkan momen aktifnya alarm (alert firing) langsung sebagai garis vertikal merah di dalam dasbor Grafana.

Tambahkan konfigurasi annotations berikut di tingkat atas struktur JSON dasbor Anda:

"annotations": {
  "list": [
    {
      "builtIn": 1,
      "datasource": {
        "type": "datasource",
        "uid": "grafana"
      },
      "enable": true,
      "hide": false,
      "name": "Alerts Firing Events",
      "type": "dashboard",
      "iconColor": "rgba(255, 96, 96, 1)",
      "target": {
        "limit": 100,
        "matchAny": false,
        "tags": ["production", "alert"]
      }
    }
  ]
}

Ketika ada aturan PrometheusRule yang beralih ke status firing, Grafana akan memplot garis putus-putus merah pada area grafik, memperlihatkan korelasi visual instan antara lonjakan trafik dan terpicunya alarm.

Anti-Pattern dalam Desain Dasbor #

Hindari kesalahan fatal berikut saat merancang antarmuka visualisasi:

1. Pola “Wall of Charts” (Terlalu Banyak Grafik) #

Menempatkan lebih dari 20 panel grafik pada satu halaman dasbor. Ini menurunkan performa render browser pengguna dan membebani server Prometheus dengan puluhan kueri serentak.

✓ SOLUSI: 
- Batasi dasbor utama maksimal 8-12 panel penting.
- Gunakan fitur "Collapsible Rows" (baris yang bisa dilipat) untuk menyembunyikan metrik sekunder secara default.

2. Kueri PromQL Tanpa Unit Pengukuran yang Sesuai #

Menampilkan data ukuran file memori byte tanpa mengatur parameter Unit di pengaturan panel Grafana. Angka seperti 8589934592 sangat sulit dibaca manusia secara instan dibandingkan jika unit diatur ke Bytes (IEC) yang secara otomatis memformatnya menjadi 8 GiB.

3. Duplikasi Dasbor secara Manual (Manual Dashboard Sprawl) #

Menduplikat dasbor yang sama untuk setiap mikroservis baru. Gunakan variable templating dinamis untuk membuat satu dasbor serbaguna (reusable template dashboard).

Checklist Audit Grafana Dashboard Produksi #

Pastikan dasbor visualisasi Anda memenuhi standar kualitas berikut sebelum digunakan oleh tim operasional:

DESAIN TAMPILAN & STRUKTUR:
  □ Dasbor dirancang mengikuti pola drill-down hierarkis (Cluster -> Namespace -> Service).
  □ Panel dasbor menyertakan visualisasi 'Four Golden Signals' untuk aplikasi kritis.
  □ Menggunakan collapsible rows untuk menyembunyikan panel metrik sekunder.
  □ Seluruh unit pengukuran dikonfigurasi secara tepat (bytes, seconds, percent).
  □ Menggunakan thresholds warna standar (hijau, kuning, merah) yang merepresentasikan urgensi nyata.

DINAMISASI & VARIABLE TEMPLATING:
  □ Menggunakan variable '$datasource' untuk fleksibilitas perpindahan cluster.
  □ Dropdown '$namespace' dan '$service' aktif dan kueri PromQL saling terikat.
  □ Tidak ada nilai hardcoded untuk parameter cluster, namespace, atau pod di kueri PromQL.

INTEGRASI & PROVISIONING (GIT_OPS):
  □ Dasbor disimpan sebagai file JSON di dalam Git repositori.
  □ Dasbor diprovisioning otomatis ke kluster menggunakan objek ConfigMap dengan label pencocokan.
  □ Dasbor dikunci (editable: false) di tingkat JSON agar tidak bisa dimodifikasi manual di produksi.
  □ Fitur annotations alert diaktifkan pada time series chart.
  □ Exemplars dikonfigurasi untuk menghubungkan grafik latensi langsung ke Grafana Tempo traces.

Ringkasan #

  • Kurangi MTTD dengan Desain Hierarkis — Pisahkan dasbor menjadi tingkat Cluster, Namespace, dan Service Detail untuk mempermudah penyelidikan insiden secara bertahap.
  • Wajibkan Visualisasi Four Golden Signals — Pastikan metrik Latency, Traffic, Errors, dan Saturation selalu menjadi fokus visual utama pada dasbor aplikasi Anda.
  • Gunakan Variabel untuk Reusable Dashboard — Manfaatkan variabel $namespace dan $service untuk mencegah duplikasi dasbor manual yang memicu kekacauan manajemen file.
  • Terapkan Dashboard-as-Code via GitOps — Jangan edit dasbor secara manual di produksi; kelola sebagai JSON di repositori Git dan deploy menggunakan ConfigMap.
  • Hubungkan Metrik ke Tracing via Exemplars — Aktifkan fitur exemplars untuk melompat secara instan dari grafik anomali latensi ke visualisasi tracing di Grafana Tempo.
  • Konfigurasikan Unit Pengukuran secara Akurat — Atur unit visualisasi (seperti mengubah detik ke milidetik atau byte ke GiB) agar data dapat dipahami oleh tim on-call dalam 1 detik.

← Sebelumnya: Distributed Tracing   Berikutnya: Health Check →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact