VictoriaMetrics - Prometheus için en iyi uzak depolamayı oluşturma

Herkese selam! VictoriaMetrics kurucuları burada:

  • valyala
  • hagen1778
  • tenmozes

Victoria Metrik’e ışık tutabildiğimiz için mutluyuz.

Biraz tarih

İki yıl önce Prometheus ve Grafana'yı kullanmaya başladık. Bu, Zabbix'e kıyasla temiz bir nefes aldı. Artık geliştiriciler kodlarına rastgele ölçümler dağıtabilir, Grafana'da özel panolar oluşturabilir ve uygulamalarını özel sysadmins / DevOps olmadan izleyebilirler.

Prometheus örneğimiz tarafından kazınan benzersiz metriklerin sayısı, yarım yılda birkaç yüzden 300.000'den fazla hızla büyüdü. Büyüme sırasında Prometheus 2.0'a geçtik, çünkü 2.0 öncesi Prometheus metrik hacimlerimiz için çok yavaş oldu. Ancak yeni Prometheus'un birkaç sorunu vardı:

  • Birkaç günden fazla olan sorgu aralıklarında hızlı değildi. Uzun vadeli eğilimler ve kapasite planlama panoları için bu aralıkları kullandık.
  • Varsayılan 15 günden bir yıla yavaş yavaş alıkonma artışının ardından çok fazla depolama alanı yemeye başladı.
  • Prometheus'un veri kaybının önlenmesi durumunda, depolama çökmesi durumunda nasıl netleşeceği belli değildi. Aynı hedefleri kazıyan iki farklı Prometheus örneği ile sonuçlanıyoruz (diğer bir deyişle HA çifti). Bu, izleme maliyetlerimizi iki katına çıkardı.

Olası çözümleri araştırmaya başladık ve Prometheus'un uzaktan depolamayı desteklediğini keşfettik. Ancak mevcut tüm çözümler, çeşitli nedenlerden dolayı tatmin edici değildi:

  • Karmaşık kurulum ve kırılgan işlem.
  • Rapor edilen çökmeler ve veri kaybı.
  • Yavaşlık.
  • Sıfır veya alt-optimal ölçeklenebilirlik.

Aynı zamanda, günde 300 milyar olaya kadar olan büyük olay akışlarını depolamak ve analiz etmek için ClickHouse'u başarıyla kullandık. Operasyonel basitliğe, sorgu hızına ve MergeTree masa motorunun sıkıştırma seviyesine hayran kaldık.

ClickHouse ile olan deneyimimiz çok büyüktü, dolayısıyla aşağıdaki projeleri kaynaklı olarak açtık:

  • clickhouse-grafana - ClickHouse için Grafana veri kaynağı.
  • chproxy - ClickHouse için yük dengeleyici ve önbellek proxy'si.
  • chclient - ClickHouse için hızlı Go istemcisi.

ClickHouse'u Prometheus için uzak bir depolama alanı olarak kullanmayı denedik. İlk sonuçlar mükemmeldi - ClickHouse, saniyede milyarlarca veri noktasını tek bir sunucuda tarayabildi. Ne yazık ki Prometheus etiketleri için verimli bir indeks oluşturmak için iyi bir çözüm bulamadık.

Sonra çılgınca bir fikir ortaya çıktı - haydi kendi TSDB'imizi aşağıdaki şartlarla oluşturalım:

  • Prometheus etiketleri için verimli indeks aka aka Milyarlarca farklı etiketi kolayca saklayan ve sorgulayan Metrics 2.0 etiketleri.
  • Büyük tarih aralıkları, çok sayıda benzersiz ölçüm ve çok sayıda veri noktasıyla ilgili sorgular için hızlı hız.
  • İyi depolama sıkıştırma, bu nedenle sınırlı disk alanında daha fazla veri depolanabilir.
  • ClickHouse'daki FREEZE PARTITION ile benzer kolay ve hızlı çevrimiçi yedekleme.

Bu TSDB'nin prototipi ümit vericiydi, bu yüzden (valyala) VertaMedia'daki çalışmamdan ayrıldım ve TSDB üzerinde tam zamanlı olarak çalışmaya başladım. Daha sonra TSDB güzel bir isim aldı - VictoriaMetrics.

Teknik detaylar

VictoriaMetrics Go'da yazılmıştır. Go aşağıdaki nedenlerden dolayı seçildi:

  • Mevcut birçok TSDB çözümü Go - Prometheus, InfluxDB, Thanos, M3, Cortex, vb. İle yazılmıştır. Bu ipuçları Go, TSDB yazımı için oldukça iyidir.
  • Go'da iyi bir tecrübem var. GitHub'taki depolarıma bakın.
  • Ben fasthttp'nin yazarıyım, bu yüzden Go'da nasıl verimli uygulamalar yazacağımı biliyorum.

VictoriaMetrics’in depolaması, Clickhouse’un MergeTree masa motorundaki fikirleri kullanarak sıfırdan inşa edilmiştir:

  • Ayrı zaman isimlerini, zaman damgalarını ve değerlerini (aka sütunlu depolama) saklayın. Bu, yalnızca gerekli sütunları tarayarak sorguları hızlandırır.
  • Her sütunu log yapılı birleştirme ağacına (LSM) benzer bir veri yapısında saklayın. Bu, B ağacı benzeri veri yapılarına kıyasla sıralı değerler eklerken / tararken rastgele G / Ç'yi azaltır. Bu, HDD’deki depolamayı hızlandırır. LSM dosyaları değişmez. Bu, hızlı anlık görüntüler ve yedeklemeler yapmanızı kolaylaştırır. LSM'nin B ağacıyla karşılaştırıldığında bir dezavantajı vardır - daha küçük dosyalar daha büyük dosyalara birleştirildiğinde, saklanan veriler birçok kez yeniden yazılır. Bu, disk bant genişliğini boşa harcar, ancak ClickHouse uygulaması bunun oldukça iyi bir tradeoff olduğunu gösterir.
  • CPU önbelleğine uyan parçalarda veri işleyin. Bu, yavaş RAM'den veri beklememesi nedeniyle CPU performansını en üst düzeye çıkarır. Ayrıntılar için Her Programcının Bilmesi Gereken Gecikme Numaralarına bakın.

Başlangıçta Prometheus etiketleri için endeks Go'daki LevelDB portunun üstüne inşa edildi. Sonra onu daha verimli bir alternatifle değiştirmeye çalıştım - RocksDB. Ancak, taranan her etiket için ödenmesi gereken yüksek cgo yükü nedeniyle başarılı olamadı. Sonunda LevelDB özel bir veri yapısı ile değiştirildi - mergeset. Bu veri yapısı Prometheus etiketlerinin endeksi için özel olarak optimize edilmiştir.

mergeset, LevelDB ile karşılaştırıldığında aşağıdaki farklılıklara sahiptir:

  • Sadece tuşlarda çalışır. Değerlerin farkında değil.
  • Düşük yazma kuvvetlendirmesi vardır.
  • Birçok sipariş edilen anahtar için daha hızlı aramalar yapıyor.
  • Anahtarları daha iyi sıkıştırır, bu nedenle daha az depolama alanı gerektirir.
  • Anlık veri anlık görüntüleri ve kolay yedeklemeler sağlar.
  • ClickHouse’un MergeTree masa motorundan fikirler kullanır.

Yakın gelecekte kaynak birleştirme açmayı planlıyoruz, bu nedenle diğerleri bundan faydalanabilir.

Başlangıçta VictoriaMetrics, tek sunuculu bir çözümdü. Daha sonra kümelenmiş bir çözüme dönüştürüldü. Dönüşüm sırasında tek bir hizmet üç hizmete bölünmüştür:

  • vmstorage - vminsert'ten alınan metrik değerleri saklar, vmselect'ten sorgular için ham metrik değerleri döndürür.
  • vminsert - Prometheus remote_write API üzerinden metrik değerleri kabul eder ve bunları vmstorage'a gönderir.
  • vmselect - Prometheus sorgulama API'sini uygular. Vmstorage'dan ham verileri alır.

Bölme, aşağıdaki avantajları sağlar:

  • Her servis bağımsız olarak ölçeklenebilir.
  • Her servis, servis ihtiyaçları için ideal olarak optimize edilmiş donanımlarda çalışabilir.
  • Ağır uçlar, ağır seçimlere müdahale etmez.
  • Vminsert içindeki hatalar vmselect'i bozmaz ve bunun tersi de geçerlidir.
  • Daha iyi vmstorage dayanıklılığı, çünkü vmselect için karmaşık sorgulama mantığını boşaltır.

Şimdi VictoriaMetrics Google Cloud'da çalışıyor. Altyapıyı Kaynak yönetimi ve Dağıtım Yöneticisi aracılığıyla sağlama için Kod yaklaşımı olarak kullanıyoruz.

Sorgu motoru

Başlangıçta vmselect Prometheus'un uzaktan okuma API'sini sağladı. Ancak, bu işlem alt düzeydeydi çünkü API her ham veri noktasını her sorgu için Prometheus'a transfer etmeyi gerektiriyordu. Örneğin, Prometheus, her biri 10K veri noktası olan 1K metrikler üzerinde yanıt oluşturuyorsa, vmselect her sorguda Prometheus'a 1K * 10K = 10M veri noktası göndermelidir. Bu bir çıkış trafiği ve para kaybıdır. Böylece daha sonra uzaktan okuma API'si tamamen PromQL ile uyumlu olan sorgu motoru ile değiştirildi.

Sorgu motoru, karmaşık sorguların sadeleştirilmesine yönelik ek özellikleri desteklemektedir. Aşağıda birkaç örnek verilmiştir:

  • Genel tablo ifadelerine benzeyen şablonlarla:
İLE (
      commonFilters = {job = ~ "$ job", örnek = ~ "$ örnek"}
  ) node_filesystem_size_bytes {commonFilters} / node_filesystem_avail_bytes {commonFilters}

WITH şablonlar hakkında daha fazla bilgi edinin ve WITH şablonlar oyun alanında onlarla oynayın.

  • Birçok yararlı fonksiyon. Örneğin, sorgu sonuçlarını birleştirmek için birleştirme işlevi:
Birlik(
    , node_filesystem_size_bytes
    , node_filesystem_avail_bytes
)

Ek fonksiyonların tam listesi burada mevcuttur.

Performans gerçekleri

  • İlk testler, VictoriaMetrics'in veri noktası başına Prometheus 2.0-0.4 bayta kıyasla bizim durumumuzda veri başına 4 bayt ile karşılaştırıldığında 10 kat daha az depolama alanı kullandığını gösteriyor. Veri noktası (zaman damgası, metrik_değer) tuple.
  • Tek bir vmstorage hizmeti, 8xCPU sunucusunda saniyede 4 milyon veri noktasını kabul eder.
  • Tek bir vmselect servisi, 8xCPU sunucusunda saniyede 500 milyon veri noktasına kadar tarama yapar.
  • VictoriaMetrics, Time Series Benchmark Suite - 250MB ve 18GB arasındaki test verilerinde TimescaleDB ile karşılaştırıldığında 70 kat daha az depolama alanı kullanıyor. Test verileri 1B veri noktalarından oluşur - GitHub'daki TSBS açıklamasına bakın.
  • Performans iyileştirmeleri için bir oda var. Tüm VictoriaMetrics hizmetleri pprof işleyicisi ile donatılmıştır, bu nedenle üretim iş yükündeki performanslarını ayarlamaya hazırız.

VictoriaMetrics özellikleri

  • Tam PromQL'in yanı sıra WITH şablonlu genişletilmiş PromQL'i destekler. Grafana oyun alanında genişletilmiş PromQL kullanılabilir.
  • Kolay kurulum - sadece sağlanan remote_write URL'sini kopyalayıp Prometheus config'e yapıştırın.
  • Azaltılmış işletme maliyetleri. Prometheus, VictoriaMetrics'e uzaktan yazma sağladıktan sonra vatansız hizmete dönüştürülebilir.
  • Çok çeşitli saklama süreleri mevcuttur - 1 aydan 5 yıla kadar.
  • Performans ölçeklerini saniyede milyonlarca metrik değere yerleştirin.
  • Performans ölçeklerini saniyede milyarlarca metrik değere ayarlayın.
  • Depolama, trilyonlarca metrik değere ve milyonlarca benzersiz metriğe (yani yüksek kardinalite) ölçeklenir.
  • Aynı remote_write URL'sini kullanıyorlarsa, rastgele farklı sayıda Prometheus örnekleri arasında genel sorgulama görünümü sağlar.

VictoriaMetrics'ten kimler yararlanabilir?

  • Prometheus'u kullanan herkes. Sadece VictoriaMetrics'i uzak bir depolama alanı olarak ayarlayın ve yedeklemeler, çoğaltma, kapasite planlama ve diğer bakım yükleri gibi yerel depolama operasyonel sorunları hakkında endişelenmeyi bırakın.
  • Prometheus'u Kubernet'lere yerleştiren kullanıcılar. Şu anda, bu tür kullanıcılar Prometheus yerel depolaması için kalıcı hacimleri dikkatli bir şekilde yönetmelidir. Genellikle Prometheus'u zamanlama kararlarında Kubernet'leri sınırlayabilen durumlu bir uygulama olarak kurdular. Sadece VictoriaMetrics'i uzak bir depolama alanı olarak kullanın ve Prometheus'u vatansız bir uygulama olarak çalıştırın.
  • Farklı ağlarda / veri merkezlerinde bulunan birçok farklı Prometheus örneğine sahip kullanıcılar. VictoriaMetrics, tüm Prometheus örnekleri arasında genel sorgulama görünümü sağlar.

Gelecek özellikler

Gelecekte aşağıdaki özellikleri uygulamayı planlıyoruz:

  • Eski verilerin otomatik olarak küçültülmesi.
  • Verilen etiket filtreleri için son değerler.
  • Zaman pencereli sayaçlar.

Sonuç

Victoria Metet'in Prometheus için en iyi uzak depo olacağına eminiz.

Keşfetmeye devam et. SSS bölümünü okuyun. VictoriaMetrics oyun alanında kayıt olun, Prometheus örnekleriniz için uzaktan test olarak kullanın. Prometheus, uzak depolamanın yanı sıra yerel depoya veri yazmaya devam ettiğinden kesinlikle güvenlidir, bu nedenle uzak depolamayı etkinleştirirken yerel verileriniz kaybolmaz. Daha fazla bilgi için Hızlı Başlangıç ​​bölümüne bakın.

Grafana oyun alanında gösterge tablolarını ve grafikleri düzenleyin. Bu oyun alanı, VictoriaMetrics oyun alanının dahili ölçümlerine işaret eden VictoriaMetrics veri kaynağını kullanır, bu nedenle Extended PromQL'in tüm özellikleri burada mevcuttur.

Üretim VictoriaMetrics yakında hazır olacak. Bizi izlemeye devam edin ve bu konudaki sözü yayın!

Güncelleme: Tek sunucu VictoriaMetrics içeren docker görüntüleri burada bulunmaktadır. Docker'dan hoşlanmıyorsanız, ilgili statik ikili dosyaları kullanın.

Güncelleme2: Yeni mesajımızı okuyun - High-cardinality TSDB kıyaslamaları: VictoriaMetrics - TimescaleDB - InfluxDB.

Update3: VictoriaMetrics şimdi açık kaynak!

Topluluğumuza katılın Slack ve haftalık Faun konularımızı okuyun ⬇

Bu yayın yardımcı olduysa, yazara desteğinizi göstermek için lütfen birkaç kez aşağıdaki p düğmesine tıklayın! ⬇