- Grafana product suite में कम अंतराल पर प्रमुख components को बार-बार बंद या replace किया जाता है, जिससे long-term संचालन के लिए ढांचा कठिन बन जाता है
- हर नए solution के आने पर configuration का तरीका, DSL, Helm chart, Operator आदि बार-बार बदलते रहते हैं, जिससे स्थिर maintenance मुश्किल हो जाती है
- Prometheus Operator ecosystem के साथ CRD compatibility पूरी नहीं है, इसलिए ServiceMonitor·PodMonitor काम करते हैं, लेकिन AlertmanagerConfig जैसी core features में support gap पैदा होता है
- Mimir 3.0 Apache Kafka dependency को मजबूरी में जोड़ता है, जिससे cluster complexity और operational burden काफी बढ़ जाता है
- Grafana Cloud और Mimir·Loki·Grafana product suite भर में settings की location और endpoints आसानी से बदल जाते हैं, इसलिए एक बार बनाकर लंबे समय तक चलाना कठिन रहने वाला ढांचा बार-बार दिखाई देता है
Grafana product suite में बार-बार structural changes
- Grafana Agent, Flow Mode, OnCall जैसी core features को 1–3 साल के भीतर बंद या replace किया जाना बार-बार हुआ है
- Angular-आधारित Grafana UI को React में बदलने के दौरान कई पुराने dashboards टूट गए
- कुछ Helm charts का अब maintenance नहीं किया जाता
Alloy अपनाने से बढ़ी जटिलता
- All-in-one होने का दावा करने वाला Grafana Alloy पुराने Agent का replacement बना, लेकिन शुरुआती stability issues मौजूद थे
- यह अपना DSL (HCL जैसा) इस्तेमाल करता है, जिससे पुराने YAML-आधारित flow से disconnect हो जाता है
- Alloy Operator भी जुड़ने से components और जटिल हो गए
Prometheus Operator ecosystem के साथ अधूरी संगति
- K8s monitoring standard
ServiceMonitor, PodMonitor का support है, लेकिन
PrometheusRules के लिए अतिरिक्त configuration चाहिएAlertmanagerConfig supported नहीं है- Mimir अपना Alertmanager इस्तेमाल करता है, इसलिए version differences और subtle incompatibilities पैदा होते हैं
Mimir 3.0 में Kafka dependency की शुरुआत
- लक्ष्य पहले से ज्यादा scalability का था, लेकिन
- core architecture में Kafka को अनिवार्य रूप से जोड़ने से operational difficulty काफी बढ़ गई
- single Helm install → कई components के coordination तक जटिलता exponential रूप से बढ़ जाती है
ऐसा ecosystem जिसमें stable use कठिन है
- Grafana Cloud ingestion endpoint नया management system आने के बाद और ढूंढना मुश्किल हो गया
- प्रमुख components के upgrade·deprecation cycle तेज हैं, इसलिए यह “उबाऊ लेकिन स्थिर monitoring” चाहने वाली organizations के लिए उपयुक्त नहीं है
- तकनीक से ज्यादा product management का तरीका और तेज बदलाव की रफ्तार reliability को कम करने वाला मुख्य कारण बनते हैं
5 टिप्पणियां
influxdb में डिफ़ॉल्ट रूप से मिलने वाला dashboard भी अपने तरीके से simple use के लिए काफ़ी काम का है
मैं इस बात से सहमत हूँ कि Grafana कुछ खास नहीं है, लेकिन क्या Grafana जितने कई Datasource को सपोर्ट करने वाले किसी दूसरे समाधान की सिफारिश की जा सकती है?
हालाँकि, इसका कोई खास विकल्प भी नहीं है।
लगता है Grafana में भी ऐसे बहुत लोग थे जो promotion या resume सजाना चाहते थे।
Hacker News की राय
मैं भी लेखक की तरह Grafana को पूरी तरह छोड़ दूँ क्या इस पर गंभीरता से सोच रहा हूँ
हर साल dashboard फिर से बनाना, alerts दोबारा सेट करना, और नए features के साथ बने रहना थका देने वाला है
बस इतना चाहिए कि service डाउन होने पर बता दे, और जब तक datasource या metrics न बदलें, 10 साल तक वही dashboard definition बनाए रखना चाहता हूँ
पहले sidebar में सिर्फ 4~5 मुख्य links होते थे, अब menu के अंदर submenus इतने ज़्यादा हैं कि basic features (dashboard, alerts) ढूँढना भी मुश्किल है
ऐसा UI जो महीने में एक बार देखते हैं, उसे हर बार फिर से सीखना बहुत inefficient है
जब services की उम्र सिर्फ 2~3 साल रह गई हो, तब कई products को एक-दूसरे पर चढ़ाते जाने से आखिर में सिर्फ technical debt का पहाड़ ही बढ़ता महसूस होता है
हर quarter में कुछ बड़ा बदलना पड़े, यह हकीकत बहुत तकलीफ़देह है
Mimir ऐसा system है जिसे बिल्कुल अलग scale के metrics संभालने के लिए design किया गया है
उस स्तर पर Kafka की सच में ज़रूरत पड़ती है
लेकिन ज़्यादातर users को उतनी scalability नहीं चाहिए
अगर आप dedicated Kubernetes cluster पर Mimir नहीं चला रहे, तो यह over-engineered है
बस Prometheus इस्तेमाल करना ज़्यादा practical है
single instance mode में भी यह हैरान करने लायक अच्छा काम करता है, और scale करना भी बहुत आसान है
कई organizations और personal projects में इस्तेमाल किया है और हमेशा संतुष्ट रहा हूँ
लेकिन AWS का Amazon Managed Prometheus, Cortex पर आधारित है, और OpenObserve भी पहले से petabyte स्तर पर चल रहा है
ideally ऐसा होना चाहिए जिसे single binary के रूप में आसानी से deploy किया जा सके, OpenTelemetry compatible हो, और बाद में किसी दूसरे OTEL provider पर migrate भी किया जा सके
अगर OTEL आधारित कोई नया solution बनाना हो, तो Prometheus/Grafana के विकल्प के रूप में सबसे promising क्या होगा, यह जानना चाहता हूँ
logs और traces संभालने के लिए और जटिल components चाहिए थे
इसलिए GreptimeDB मिला, और यह metrics·logs·traces का integrated handling दे सकता है
collection OpenTelemetry से करते हैं और visualization Grafana से
SQL से dashboards बना सकते हैं, इसलिए यह हमारी team skills के साथ अच्छी तरह मेल खाता है
simple architecture की वजह से platform engineer के रूप में यह संतोषजनक लगता है
इसे Grafana और Elastic की complexity हल करने के लिए बनाया गया था, और single container में logs·metrics·traces·dashboards·alerts सब संभाल सकता है
(लेखक OpenObserve का maintainer है)
यह open source है, सक्रिय रूप से develop हो रहा है, और team communication भी अच्छा है
Grafana की उस complexity से बचने के लिए, जहाँ कई backends को खुद संभालना पड़ता है, बहुत से users यहाँ migrate कर रहे हैं
(लेखक SigNoz का maintainer है)
समझ नहीं आता कि developers हर हफ्ते settings बदलकर नई-नई तकनीक के पीछे क्यों भागते हैं
मैं 2017 से Grafana + Prometheus combination इस्तेमाल कर रहा हूँ, और यह आज भी अच्छी तरह काम करता है
1~2 साल में सिर्फ एक बार LTS version पर update करता हूँ
dashboards अब भी बिल्कुल सही हैं, कोई समस्या नहीं है
ज़्यादातर लोगों के लिए यही boring लेकिन stable combination सबसे अच्छा है
पूछना चाहता हूँ कि क्या आप अब भी पुराना version ही इस्तेमाल कर रहे हैं
open source में Grafana की जगह लेने वाला कोई dashboard builder है क्या? हमारी company में भी Grafana का बहुत व्यापक इस्तेमाल है
वरना Prometheus console templates या VictoriaMetrics के built-in dashboards इस्तेमाल किए जा सकते हैं, लेकिन features बहुत सीमित हैं
Grafana dashboards खुद VictoriaMetrics + ClickHouse combination के साथ इस्तेमाल करने पर काफ़ी आरामदायक हैं
RRD, Nagios जैसे नाम बस धुँधले से याद हैं
Grafana का लगातार बदलते रहना अब उल्टा आदत जैसा बन गया है
हर major release में dashboards टूट जाते हैं या UI बदल जाता है, लेकिन अब बस ऐसा ही मान लेते हैं
असली समस्या Prometheus का PromQL lock-in है
metrics के नाम बदलो तो सारे rules, alerts और dashboards बदलने पड़ते हैं
PromQL syntax errors के अलावा लगभग कोई error नहीं देता, इसलिए pint जैसे tools से validate करना पड़ता है
single server deployment में Prometheus Pushgateway + Grafana को अक्सर docker-compose template के रूप में इस्तेमाल करता हूँ
यह simple है और अच्छा काम करता है, लेकिन metrics की मात्रा बढ़ते ही complexity फटकर बढ़ जाती है
अगर Prometheus ने ज़्यादा efficient transport format बनाए रखा होता, तो यह समस्या कम होती
text format की जगह compact binary metric format होता, तो millions के स्तर के labels भी आसानी से संभाले जा सकते थे
SigNoz अच्छा विकल्प है और सक्रिय रूप से develop हो रहा है
पहले cloud observability platform पर बहुत पैसा खर्च होता था, अब Hetzner box पर self-hosted SigNoz चलाकर महीने के $10 में काम हो जाता है
Prometheus और Grafana, दोनों ने अलग-अलग full-stack solution बनने की दिशा पकड़ी, और फिर OTEL आने से स्थिति और जटिल हो गई
OTEL metrics·traces·logs के लिए protocol है, लेकिन इसे support करने वाला कोई single DB नहीं है
ज़्यादातर लोग Prometheus (metrics) + OpenSearch (logs) का combination इस्तेमाल करते हैं
आखिरकार OTEL का मतलब collector बदलना और configuration दोबारा करना ही बन जाता है