StatsD'den OpenTelemetry'ye: vmagent ile Metrik Hattı
Büyük ölçekli bir metrik altyapısının StatsD'den OpenTelemetry ve Prometheus'a taşınma süreci; OTLP kazanımları, kardinalite sorunları ve vmagent ile akış toplulaştırma anlatılıyor.
Ekip, çoğu servisi StatsD ile enstrümante edilmiş büyük ölçekli bir metrik altyapısını OpenTelemetry (OTLP) ve Prometheus tabanlı yeni bir depolama sistemine taşıdı. Önce OTLP'yi kurumsal servisler için standart protokol olarak belirleyip StatsD'yi eski yollar için yedek bıraktılar; paylaşılan bir metrik kütüphanesi üzerinden çift yönlü emisyon (StatsD + OTLP) yaparak düşük sürtünmeli bir geçiş sağladılar. OTLP'ye geçiş; CPU kullanımını metrik işleme tarafında %10'dan %1'in altına indirdi, UDP kaynaklı paket kaybı riskini azalttı ve Prometheus'un üstel histogram gibi yerel özelliklerinden tam verimle yararlanmayı mümkün kıldı.
Ancak en yüksek hacimli ve kritik servislerde OTLP, yüksek kardinaliteli metrikler (saniyede 10 binin üzerinde örnek) nedeniyle bellek baskısı ve artan çöp toplama aktivitesine yol açtı. Çözüm olarak seçili servislerde delta temporality kullanılarak bellek yükü azaltıldı; bu da veri akışında küçük boşluklar pahasına kararlılığı artırdı.
Toplulaştırma katmanında Veneur, kayıt kuralları, m3aggregator, OTel Collector ve Vector gibi seçenekler değerlendirilip reddedildi; sonunda VictoriaMetrics'in vmagent aracı seçildi. Router ve aggregator olmak üzere iki katmanlı, durum bilgisi taşıyan bir mimari kurularak metrikler tutarlı biçimde parçalanıp toplulaştırıldı. Sonuçta tek bir üretim kümesi yüzlerce aggregator'a ölçeklenerek saniyede 100 milyondan fazla örnek işleyebilir hale geldi ve maliyetler bir büyüklük mertebesi azaldı.