- Grafana ürün ailesi, ana bileşenleri kısa aralıklarla sık sık kullanımdan kaldırıp değiştirdiği için uzun vadeli işletimi zorlaştıran bir yapı oluşturuyor
- Her yeni çözüm devreye alındığında yapılandırma yöntemi, DSL, Helm chart, Operator vb. tekrar tekrar değişiyor ve bu da istikrarlı bakım yapmayı zorlaştıran bir ortam yaratıyor
- Prometheus Operator ekosistemiyle CRD uyumluluğu tam olmadığı için ServiceMonitor ve PodMonitor çalışsa da AlertmanagerConfig gibi kritik işlevlerde destek boşlukları oluşuyor
- Mimir 3.0, Apache Kafka bağımlılığını zorunlu hale getirerek küme karmaşıklığını ve operasyon yükünü ciddi biçimde artırıyor
- Grafana Cloud ile Mimir, Loki ve Grafana ürün ailesinin genelinde ayar konumları ve endpoint’ler kolayca değişebildiği için, bir kez kurup uzun süre kullanmayı zorlaştıran bir yapı tekrar ediyor
Grafana ürün ailesinde sık yapısal değişiklikler
- Grafana Agent, Flow Mode, OnCall gibi çekirdek işlevlerde 1–3 yıl içinde kullanımdan kaldırma ve değiştirme döngüsü tekrar ediyor
- Angular tabanlı Grafana arayüzü React’e geçirilirken mevcut dashboard’ların önemli bir kısmı bozuldu
- Bazı Helm chart’ları artık bakım almıyor
Alloy’nin devreye girmesiyle artan karmaşıklık
- Hepsi bir arada yaklaşımını savunan Grafana Alloy, mevcut Agent’ın yerini aldı ancak ilk dönemde kararlılık sorunları yaşandı
- Kendi DSL’sini (HCL benzeri) kullandığı için mevcut YAML tabanlı akıştan kopuyor
- Alloy Operator’ün de eklenmesiyle bileşenler daha da karmaşık hale geliyor
Prometheus Operator ekosistemiyle eksik uyum
- K8s izleme standardı olan
ServiceMonitor, PodMonitor destekleniyor ancak
PrometheusRules için ek yapılandırma gerekiyorAlertmanagerConfig desteklenmiyor- Mimir kendi Alertmanager’ını kullandığı için sürüm farkları ve ince uyumsuzluklar ortaya çıkıyor
Mimir 3.0’da Kafka bağımlılığının eklenmesi
- Amaç eskisine göre daha yüksek ölçeklenebilirlik olsa da
- Çekirdek yapıya Kafka’yı zorunlu olarak ekleyerek operasyon zorluğunu ciddi biçimde artırıyor
- Tek bir Helm kurulumu → çok sayıda bileşenin koordinasyonuna geçişle karmaşıklık katlanarak büyüyor
İstikrarlı kullanımın zor olduğu bir ekosistem
- Grafana Cloud ingestion endpoint’i, yeni bir yönetim sisteminin devreye alınmasıyla daha da zor bulunur hale geldi
- Ana bileşenlerin yükseltme ve kullanımdan kaldırma döngüsü hızlı olduğu için “sıkıcı ama istikrarlı izleme” isteyen kurumlarla pek uyuşmuyor
- Sorunun özü teknolojinin kendisinden çok, ürün yönetim biçimi ve hızlı değişim temposunun güvenilirliği zayıflatması olarak öne çıkıyor
5 yorum
influxdb'nin varsayılan olarak sunduğu pano da basit işler için fena sayılmaz.
Grafana'nın pek iyi olmadığı konusunda katılıyorum ama Grafana kadar çok sayıda
Datasourcedestekleyen, önermeye değer başka bir çözüm var mı acaba?Belirgin bir alternatif de pek yok gibi.
Görünüşe göre Grafana'da da terfi etmek ya da özgeçmişini süslemek isteyen epey kişi varmış.
Hacker News görüşleri
Ben de yazarla aynı nedenlerden dolayı Grafana’yı tamamen bırakmayı ciddi ciddi düşünüyorum
Her yıl panoları yeniden yapmak, alarmları yeniden ayarlamak ve yeni özelliklere ayak uydurmak yorucu
Aslında sadece servis öldüğünde haber versin istiyorum ve veri kaynağı ya da metrikler değişmediği sürece aynı pano tanımını 10 yıl koruyabilmek istiyorum
Eskiden kenar çubuğunda sadece 4-5 ana bağlantı vardı, şimdi ise menüler içindeki alt menüler o kadar arttı ki temel işlevleri (panolar, alarmlar) bulmak bile zorlaştı
Ayda bir kadar baktığım bir arayüzü her seferinde yeniden öğrenmek zorunda olmak çok verimsiz
Servis ömrünün sadece 2-3 yıl olduğu bir ortamda üst üste bir sürü ürün yığmak, sonunda sadece teknik borç dağı büyüyormuş gibi hissettiriyor
Her çeyrekte büyük bir şeyi değiştirmek zorunda kalmanın gerçekliği acı verici
Mimir, tamamen farklı ölçekteki metrikleri işlemek için tasarlanmış bir sistem
O seviyede Kafka gerçekten gerekli
Ama çoğu kullanıcının bu kadar ölçeklenebilirliğe ihtiyacı yok
Mimir’i özel bir Kubernetes kümesinde çalıştırmıyorsanız, bu aşırı tasarlanmış demektir
Sadece Prometheus kullanmak daha gerçekçi
Tek örnek modunda bile şaşırtıcı derecede iyi çalışıyor ve ölçeklendirmesi de çok kolay
Bunu birden çok kuruluşta ve kişisel projede kullandım, hep memnun kaldım
Ama AWS’nin Amazon Managed Prometheus’u Cortex tabanlı ve OpenObserve da zaten petabayt ölçeğinde çalışıyor
Tek binary olarak dağıtımı kolay, OpenTelemetry ile uyumlu ve ileride başka bir OTEL sağlayıcısına taşınabilen bir çözüm ideal olurdu
OTEL tabanlı yeni bir çözüm kurulacaksa, Prometheus/Grafana’ya alternatif olarak en umut verici seçeneğin hangisi olduğunu merak ediyorum
Logları ve trace’leri işlemek için daha karmaşık bileşenler gerekiyordu
Sonra GreptimeDB’yi bulduk; metrik, log ve trace’i birleşik şekilde işleyebiliyor
Toplamayı OpenTelemetry ile yapıyor, görselleştirmeyi Grafana ile gerçekleştiriyoruz
SQL ile pano oluşturabilmek ekibin yetkinliğiyle iyi örtüşüyor
Basit yapısı sayesinde platform mühendisi olarak memnunum
Grafana ve Elastic’in karmaşıklığını çözmek için yapıldı; tek bir container ile log, metrik, trace, pano ve alarmı birlikte yönetebiliyor
(Yazan kişi OpenObserve’un maintainer’ı)
Açık kaynak, aktif olarak geliştiriliyor ve ekip iletişimi de iyi
Grafana’da birden fazla backend’i doğrudan yönetmenin karmaşıklığından kaçmak isteyen birçok kullanıcı buraya geçiyor
(Yazan kişi SigNoz maintainer’ı)
Geliştiricilerin neden her hafta ayar değiştirip en yeni teknolojinin peşinden koştuğunu anlamıyorum
Ben 2017’den beri Grafana + Prometheus kombinasyonunu kullanıyorum ve hâlâ gayet iyi çalışıyor
Sadece 1-2 yılda bir, o da LTS sürümüne güncelliyorum
Panolar hâlâ kusursuz ve hiçbir sorun yok
Çoğu insan için bu sıkıcı ama istikrarlı kombinasyon en iyi seçenek
Acaba eski sürümü olduğu gibi mi kullanıyorsunuz, diye sormak isterim
Açık kaynak dünyasında Grafana’nın yerini alabilecek bir pano oluşturucu var mı? Şirkette de Grafana’yı yaygın biçimde kullanıyoruz
Ya da Prometheus console templates veya VictoriaMetrics’in gömülü panoları kullanılabilir, ama özellikleri çok daha sınırlı
Grafana panolarının kendisi ise VictoriaMetrics + ClickHouse kombinasyonuyla kullanıldığında oldukça rahat
RRD ve Nagios gibi isimleri ancak belirsiz biçimde hatırlıyorum
Grafana’daki bitmek bilmeyen değişim bir noktadan sonra insana alışkanlık kazandırıyor
Her major release’te panolar bozuluyor ya da arayüz değişiyor ama insan artık “neyse” deyip geçiyor
Asıl sorun Prometheus’un PromQL kilitlenmesi
Metrik adını değiştirirseniz tüm kuralları, alarmları ve panoları güncellemeniz gerekiyor
PromQL sözdizimi hataları dışında neredeyse hiç hata vermediği için pint gibi araçlarla doğrulamak gerekiyor
Tek sunucu dağıtımlarında Prometheus Pushgateway + Grafana’yı sık sık docker-compose şablonu olarak kullanıyorum
Basit ve iyi çalışıyor ama metrik miktarı büyüyünce karmaşıklık patlıyor
Prometheus daha verimli bir aktarim biçimi korusaydı bu sorun daha hafif olurdu
Metin biçimi yerine derli toplu bir ikili metrik biçimi olsaydı milyonlarca etiketi bile zorlanmadan işleyebilirdi
SigNoz iyi bir seçim ve aktif olarak geliştiriliyor
Eskiden bulut gözlemlenebilirlik platformlarına büyük para harcıyordum, şimdi ise bir Hetzner kutusunda self-hosted SigNoz çalıştırarak işi aylık 10 dolara çözüyorum
Prometheus ve Grafana’nın ikisi de full-stack çözüm olmaya yönelirken OTEL ortaya çıktı ve tabloyu karmaşıklaştırdı
OTEL, metrik, trace ve loglar için bir protokol ama bunların hepsini destekleyen tek bir veritabanı yok
Çoğu kişi Prometheus (metrik) + OpenSearch (log) kombinasyonunu kullanıyor
Sonuçta OTEL, toplayıcı değişimi ve yeniden yapılandırma gerektiriyor gibi görünüyor