Alasan Grafana Tak Lagi Bisa Direkomendasikan

 (henrikgerdes.me)
22 poin oleh GN⁺ 2025-11-17 | 5 komentar | Bagikan ke WhatsApp
  • Rangkaian produk Grafana sering menghentikan atau mengganti komponen utama dalam siklus yang pendek, sehingga menciptakan struktur yang menyulitkan operasi jangka panjang
  • Setiap kali solusi baru diperkenalkan, cara konfigurasi, DSL, chart Helm, dan Operator terus berubah berulang kali, sehingga lingkungan menjadi sulit dipelihara secara stabil
  • Karena kompatibilitas CRD dengan ekosistem Prometheus Operator tidak sepenuhnya terpenuhi, ServiceMonitor dan PodMonitor bisa digunakan, tetapi fungsi inti seperti AlertmanagerConfig memiliki celah dukungan
  • Mimir 3.0 secara paksa menambahkan dependensi Apache Kafka, sehingga kompleksitas klaster dan beban operasional meningkat besar
  • Di Grafana Cloud serta seluruh rangkaian Mimir, Loki, dan Grafana, lokasi konfigurasi dan endpoint mudah berubah, sehingga pola yang sulit dibangun sekali lalu dipakai lama terus terulang

Perubahan struktur yang sering di rangkaian produk Grafana

  • Fitur-fitur inti seperti Grafana Agent, Flow Mode, dan OnCall berulang kali dihentikan atau digantikan dalam 1–3 tahun
    • UI Grafana berbasis Angular beralih ke React, sehingga banyak dashboard lama rusak
    • Sebagian chart Helm tidak lagi dipelihara
Iklan

Kompleksitas yang meningkat akibat adopsi Alloy

  • Grafana Alloy, yang mengusung konsep all-in-one, menggantikan Agent lama, tetapi pada awalnya sempat memiliki masalah stabilitas
    • Menggunakan DSL sendiri (mirip HCL), sehingga terputus dari alur berbasis YAML yang sebelumnya ada
    • Dengan ditambahkannya Alloy Operator, komponen konfigurasi menjadi makin kompleks

Kesesuaian yang tidak sepenuhnya lengkap dengan ekosistem Prometheus Operator

  • Standar monitoring K8s seperti ServiceMonitor dan PodMonitor memang didukung, tetapi
    • PrometheusRules memerlukan konfigurasi tambahan
    • AlertmanagerConfig tidak didukung
    • Karena Mimir memakai Alertmanager miliknya sendiri, muncul perbedaan versi dan inkompatibilitas detail
Iklan

Pengenalan dependensi Kafka di Mimir 3.0

  • Meski menargetkan skalabilitas yang lebih tinggi dari sebelumnya,
    • Kafka ditambahkan sebagai komponen wajib di bagian inti, sehingga tingkat kesulitan operasional naik drastis
    • Instalasi Helm tunggal → koordinasi banyak komponen membuat kompleksitas meningkat secara eksponensial

Ekosistem yang sulit digunakan secara stabil

  • Endpoint ingestion Grafana Cloud menjadi makin sulit ditemukan setelah diperkenalkannya sistem manajemen baru
  • Siklus upgrade dan penghentian komponen utama terlalu cepat, sehingga tidak cocok bagi organisasi yang menginginkan “monitoring yang membosankan dan stabil”
  • Bukan semata masalah teknologinya, melainkan cara pengelolaan produk dan laju perubahan yang terlalu cepat menjadi faktor utama yang menurunkan keandalan

Bacaan terkait

5 komentar

 
ifmkl 2025-11-18

Dashboard bawaan yang disediakan oleh influxdb juga lumayan bisa dipakai untuk kebutuhan sederhana.
 
dongho42 2025-11-18

Saya setuju dengan poin bahwa Grafana kurang bagus, tetapi adakah solusi lain yang layak direkomendasikan yang mendukung berbagai Datasource sebanyak Grafana?
 
cysl0 2025-11-18

Memang tidak ada alternatif yang benar-benar pas.
 
savvykang 2025-11-18

Sepertinya bahkan di Grafana juga banyak orang yang ingin mengejar promosi atau sekadar mempercantik resume.
 
GN⁺ 2025-11-17
Opini Hacker News

  • Saya juga sedang serius mempertimbangkan untuk meninggalkan Grafana sepenuhnya karena alasan yang sama seperti penulis
    Melelahkan harus membuat ulang dashboard setiap tahun, menyetel ulang alert, dan terus mengikuti fitur baru
    Saya cuma ingin diberi tahu saat layanan mati, dan selama data source atau metrik tidak berubah, saya ingin mempertahankan definisi dashboard yang sama selama 10 tahun
    Dulu sidebar hanya punya 4–5 tautan utama, sekarang submenu di dalam menu terlalu banyak sampai sulit menemukan fungsi dasar seperti dashboard dan alert
    Sangat tidak efisien kalau harus mempelajari ulang UI yang cuma dilihat kira-kira sebulan sekali setiap kali membukanya

  • Saat umur layanan hanya 2–3 tahun lalu kita menumpuk banyak produk di atasnya, rasanya yang membesar pada akhirnya hanya gunung utang teknis
    Kenyataan bahwa setiap kuartal harus mengganti sesuatu yang besar itu menyakitkan

  • Mimir adalah sistem yang dirancang untuk menangani metrik pada skala yang benar-benar berbeda
    Pada level itu Kafka memang benar-benar diperlukan
    Namun kebanyakan pengguna tidak memerlukan skalabilitas sebesar itu
    Jika Anda tidak menjalankan Mimir di klaster Kubernetes khusus, itu berarti desainnya berlebihan
    Menggunakan Prometheus saja lebih realistis

    • Saya merekomendasikan Victoria Metrics
      Bahkan dalam mode single-instance, performanya sangat bagus, dan skalanya juga sangat mudah ditingkatkan
      Saya sudah memakainya di berbagai organisasi dan proyek pribadi, dan selalu puas
    • Lucu melihat pernyataan yang dengan tegas bilang “tidak ada skalabilitas open source lain yang sekelas”
      Namun Amazon Managed Prometheus milik AWS berbasis Cortex, dan OpenObserve juga sudah beroperasi pada skala petabyte
    • Saya penasaran solusi apa yang lebih disukai orang untuk memantau aplikasi kecil
      Idealnya mudah di-deploy sebagai single binary, kompatibel dengan OpenTelemetry, dan nanti bisa dipindahkan ke penyedia OTEL lain

  • Jika membuat solusi baru berbasis OTEL, saya penasaran mana yang paling menjanjikan sebagai alternatif Prometheus/Grafana

    • Kami juga mulai dengan kube-prometheus-stack, tetapi tidak suka PromQL
      Untuk menangani log dan trace, kami perlu komponen tambahan yang rumit
      Karena itu kami menemukan GreptimeDB, yang bisa menangani metrik, log, dan trace secara terpadu
      Data dikumpulkan dengan OpenTelemetry dan divisualisasikan dengan Grafana
      Kami bisa membuat dashboard dengan SQL, jadi sangat cocok dengan kemampuan tim
      Sebagai platform engineer, saya puas dengan strukturnya yang sederhana
    • Saya merekomendasikan OpenObserve
      Ini dibuat untuk mengatasi kerumitan Grafana dan Elastic, dan bisa menangani log, metrik, trace, dashboard, dan alert dalam satu container
      (Penulis adalah maintainer utama OpenObserve)
    • Di perusahaan belakangan ini, kami sedang beralih dari Grafana ke SigNoz
      Ini open source, dikembangkan aktif, dan komunikasinya dengan tim juga bagus
    • SigNoz adalah open source OpenTelemetry-native
      Banyak pengguna pindah ke sini untuk menghindari kerumitan Grafana yang mengharuskan mereka menangani banyak backend secara langsung
      (Penulis adalah maintainer SigNoz)

  • Saya tidak mengerti kenapa para developer mengubah setup setiap minggu sambil mengejar teknologi terbaru
    Saya sudah memakai kombinasi Grafana + Prometheus sejak 2017, dan sampai sekarang masih bekerja dengan baik
    Saya hanya memperbarui ke versi LTS sekali tiap 1–2 tahun
    Dashboard-nya masih sempurna dan tidak ada masalah apa pun
    Bagi kebanyakan orang, kombinasi yang membosankan tapi stabil ini adalah pilihan terbaik

    • Saya penasaran bagaimana Anda menangani penghentian dukungan Angular
      Saya ingin bertanya apakah Anda masih memakai versi lama apa adanya

  • Adakah pembuat dashboard open source yang bisa menggantikan Grafana? Di perusahaan kami juga Grafana dipakai sangat luas

    • Perses tampaknya alternatif yang paling menjanjikan
      Atau bisa juga memakai template konsol Prometheus atau dashboard bawaan VictoriaMetrics, tetapi fiturnya jauh lebih terbatas
    • Keluhan penulis tampaknya lebih mengarah ke lini produk lain dari perusahaan itu daripada Grafana sendiri
      Dashboard Grafana sendiri cukup nyaman dipakai bersama kombinasi VictoriaMetrics + ClickHouse
    • Dulu, bahkan sebelum Grafana, ada beberapa alternatif FOSS lain, tetapi kebanyakan sudah hilang
      Yang samar-samar saya ingat hanya nama seperti RRD dan Nagios
    • OpenSearch Dashboards juga alternatif, tetapi untuk visualisasi murni Grafana masih lebih baik
    • Kami sepenuhnya mengganti stack Loki dengan kombinasi Graylog + ElasticSearch

  • Perubahan tanpa henti di Grafana justru membuat saya terbiasa
    Setiap major release dashboard rusak atau UI berubah, tetapi lama-lama jadi dianggap biasa saja
    Masalah sebenarnya adalah lock-in PromQL di Prometheus
    Jika nama metrik diubah, semua rule, alert, dan dashboard harus diperbarui
    PromQL hampir tidak pernah mengeluarkan error selain kesalahan sintaks, jadi harus divalidasi dengan alat seperti pint

    • Masalah PromQL adalah tanggung jawab Prometheus, bukan Grafana

  • Untuk deployment server tunggal, saya sering memakai Prometheus Pushgateway + Grafana sebagai template docker-compose
    Sederhana dan bekerja dengan baik, tetapi saat volume metrik membesar, kompleksitasnya meledak
    Kalau Prometheus mempertahankan format transfer yang lebih efisien, masalah seperti ini mungkin tidak akan separah itu
    Seandainya ada format metrik biner yang ringkas alih-alih format teks, jutaan label pun mungkin bisa ditangani tanpa masalah

  • SigNoz adalah pilihan yang baik dan sedang dikembangkan secara aktif

    • Saya juga setuju dengan SigNoz
      Dulu saya menghabiskan banyak biaya untuk platform observability cloud, sekarang cukup menjalankan SigNoz self-hosted di box Hetzner dan selesai dengan biaya $10 per bulan

  • Prometheus dan Grafana masing-masing mengarah menjadi solusi full-stack, lalu OTEL muncul dan membuat situasinya jadi rumit

    • Saya masih belum sepenuhnya memahami bagaimana OTEL akan menempatkan diri dalam stack monitoring open source
      OTEL adalah protokol untuk metrik, trace, dan log, tetapi tidak ada satu DB tunggal yang mendukung semuanya
      Kebanyakan orang akhirnya menggabungkan Prometheus (metrik) + OpenSearch (log)
      Pada akhirnya, OTEL berarti harus mengganti dan mengonfigurasi ulang collector