Roman Khavronenko'nun “ExtishedPromQL” raporunun metnini okumanızı öneririm
Kısaca hakkımda. Benim adım Roman. CloudFlare'de çalışıyorum ve Londra'da yaşıyorum. Ama aynı zamanda VictoriaMetrics'in bakımcısıyım.
Ve ben yazarım Grafana için ve ClickHouse için küçük bir proxy'dir.
“Çevirinin Zorlukları” adlı ilk bölümle başlayacağız ve bu bölümde herhangi bir dilin, hatta sadece bir iletişim dilinin ne kadar önemli olduğundan bahsedeceğim. Çünkü düşüncelerinizi bu şekilde başka bir kişiye veya sisteme aktarırsınız, bu şekilde bir talepte bulunursunuz. İnternetteki insanlar hangi dilin daha iyi olduğunu tartışıyorlar - java mı yoksa başka bir dil mi? Kendim için göreve göre seçim yapmam gerektiğine karar verdim çünkü bunların hepsi spesifik.
En baştan başlayalım. PromQL nedir? PromQL, Prometheus Sorgu Dilidir. Zaman serisi verilerini almak için Prometheus'ta sorguları bu şekilde oluşturuyoruz.
Zaman serisi verileri nedir? Kelimenin tam anlamıyla, bunlar üç parametredir.
Bunlar şunlardır:
- Neye bakıyoruz?
- Baktığımızda.
- Peki hangi değeri gösteriyor?
Bu tabloya bakarsanız (bu grafik adım istatistiklerimi gösteren telefonumdan alınmıştır), bu sorulara hızlı bir şekilde cevap verebilir.
Adımlara bakıyoruz. Baktığımızda manayı da, zamanı da görüyoruz. Yani bu şemaya baktığınızda Pazar günü yaklaşık 15 adım attığımı rahatlıkla söyleyebilirsiniz. Bu zaman serisi verileridir.
Şimdi bunları tablo biçiminde başka bir veri modeline "bölelim" (dönüştürelim). Burada da baktığımız şey var. Buraya meta veri diyeceğimiz küçük bir ek veri ekledim, yani bunu yapan ben değildim, iki kişi, örneğin Jay ve Sessiz Bob. Baktığımız şey bu; neyi gösterir ve bu değeri ne zaman gösterir?
Şimdi tüm bu verileri bir veritabanında saklamayı deneyelim. Örneğin ClickHouse sözdizimini aldım. Ve burada "Adımlar" adında bir tablo oluşturuyoruz, yani baktığımız şey. Öyle bir dönem var ki bakıyoruz; ne gösterdiğini ve kim olduğunu saklayacağımız bazı meta verileri: Jay ve Sessiz Bob.
Tüm bunları görselleştirmeye çalışmak için Grafana'yı kullanacağız çünkü her şeyden önce çok güzel.
Biz de bu eklentiyi kullanacağız. Bunun iki nedeni var. Birincisi, çünkü bunu ben yazdım. Ve zaman serisi verilerini ClickHouse'dan alıp Grafana'da göstermenin ne kadar zor olduğunu tam olarak biliyorum.
Bunu Grafik Panelinde görüntüleyeceğiz. Bu, bir değerin zamana bağlılığını gösteren Grafana'daki en popüler paneldir, dolayısıyla yalnızca iki parametreye ihtiyacımız var.
En basit sorguyu yazalım - Grafana'da adım istatistiklerinin nasıl gösterileceğini, bu verileri ClickHouse'da, oluşturduğumuz tabloda saklayacağız. Ve bu basit isteği yazıyoruz. Adımlar arasından seçim yapıyoruz. Bir değer seçiyoruz ve bu değerlerin süresini yani bahsettiğimiz üç parametreyi seçiyoruz.
Sonuç olarak şöyle bir grafik elde edeceğiz. Neden bu kadar tuhaf olduğunu kim bilebilir?
Doğru, zamana göre sıralamamız gerekiyor.
Ve sonunda daha iyi ama yine de tuhaf bir programa sahip olacağız. Nedenini kim biliyor? Doğru, iki katılımcı var ve biz Grafana olarak iki zaman serisi veriyoruz çünkü veri modeline tekrar bakarsanız, her zaman serisinin adın ve tüm anahtar/değer etiketlerinin benzersiz bir birleşimi olduğunu görürsünüz.
Bu nedenle belirli bir kişiyi seçmemiz gerekiyor. Jay'i seçiyoruz.
Ve tekrar çizelim. Artık grafik gerçeğe benziyor. Artık bu normal bir program ve her şey yolunda gidiyor.
Muhtemelen aşağı yukarı aynı şeyi nasıl yapacağınızı biliyorsunuzdur, ancak Prometheus'ta PromQL aracılığıyla. Bunun gibi bir şey. Biraz daha basit. Ve hepsini parçalayalım. Adımlar attık. Ve Jay'e göre filtreleyin. Burada bir değer almamız gerektiğini belirtmiyoruz ve bir zaman seçmiyoruz.
Şimdi Jay veya Sessiz Bob'un hareket hızını hesaplamaya çalışalım. ClickHouse'da RunningDifference yapmamız gerekecek, yani nokta çiftleri arasındaki farkı hesaplamak ve tam hızı elde etmek için bunları zamana bölmek. İstek şuna benzer bir şey olacak.
Ve yaklaşık olarak bu değerleri gösterecektir, yani Sessiz Bob veya Jay saniyede yaklaşık 1,8 adım atar.
Ve Prometheus'ta bunu nasıl yapacağınızı da biliyorsunuz. Daha önce olduğundan çok daha kolay.
Bunu Grafana'da da kolaylaştırmak için PromQL'e çok benzeyen bu sarmalayıcıyı ekledim. Buna Hız Makroları veya siz ne demek isterseniz onu denir. Grafana'da basitçe "oran" yazarsınız ama derinlerde bir yerde bu büyük talebe dönüşür. Bakmanıza bile gerek yok, orada bir yerlerde var ama çok zaman kazanıyorsunuz çünkü bu kadar büyük SQL sorguları yazmak her zaman pahalıdır. Kolayca hata yapabilir ve ardından uzun süre neler olduğunu anlayamayabilirsiniz.
Ve bu bir slayda bile sığmayan bir istek ve hatta onu iki sütuna bölmek zorunda kaldım. Bu aynı zamanda ClickHouse'da da bir istektir, ancak her iki zaman serisi için de aynı oranı yapar: Sessiz Bob ve Jay, böylece panelde iki zaman serimiz olur. Ve bence bu zaten çok zor.
Prometheus'a göre ise toplam (oran) olacaktır. ClickHouse için Prometheus'taki bir sorguya benzeyen RateColumns adında ayrı bir makro yaptım.
Baktık ve PromQL'in çok havalı olduğunu gördük ama elbette sınırlamaları da var.
Bunlar şunlardır:
- Sınırlı SEÇİM.
- Sınırda JOIN'ler.
- Desteğe sahip olmak yok.
Ve eğer onunla uzun süre çalıştıysanız, o zaman PromQL'de bazen bir şeyler yapmanın çok zor olduğunu bilirsiniz, ancak SQL'de hemen hemen her şeyi yapabilirsiniz çünkü az önce bahsettiğimiz tüm bu seçenekler SQL'de yapılabilir. . Ama onu kullanmak uygun olur mu? Bu da bana en güçlü dilin her zaman en kullanışlı dil olmayabileceğini düşündürüyor.
Bu nedenle bazen görev için bir dil seçmeniz gerekir. Batman'in Süpermen'le dövüşmesi gibi. Süpermen'in daha güçlü olduğu açık ama Batman daha pratik olduğu ve ne yaptığını tam olarak bildiği için onu yenmeyi başardı.
Bir sonraki bölüm ise PromQL'i Genişletmek.
Bir kez daha VictoriaMetrics hakkında. VictoriaMetrics nedir? Bu bir zaman serisi veritabanıdır, Açık Kaynaktır, tek ve küme versiyonlarını dağıtıyoruz. Kriterlerimize göre, şu anda piyasada bulunan her şeyden daha hızlıdır ve sıkıştırması da benzerdir; yani gerçek insanlar nokta başına yaklaşık 0,4 baytlık bir sıkıştırma bildirirken, Prometheus'unki 1,2-1,4'tür.
Prometheus'tan fazlasını destekliyoruz. InfluxDB, Graphite, OpenTSDB'yi destekliyoruz.
Bize “yazabilirsiniz” yani eski verileri aktarabilirsiniz.
Ayrıca Prometheus ve Grafana ile de mükemmel çalışıyoruz, yani PromQL motorunu destekliyoruz. Ve Grafana'da Prometheus uç noktasını VictoriaMetrics olarak değiştirebilirsiniz; tüm kontrol panelleriniz eskisi gibi çalışacaktır.
Ancak VictoriaMetrics'in sağladığı ek özellikleri de kullanabilirsiniz.
Eklediğimiz özellikleri hızla gözden geçireceğiz.
Aralık parametresini atla – Grafana'da aralık parametrelerini atlayabilirsiniz. Panelde yakınlaştırma/uzaklaştırma yaparken garip grafikler elde etmek istemiyorsanız değişkenin kullanılması önerilir. $__interval. Bu dahili bir Grafana değişikliğidir ve veri aralığını kendisi seçer. Ve VictoriaMetrics'in kendisi de bu aralığın ne olması gerektiğini anlayabilir. Ve tüm isteklerinizi güncellemenize gerek yok. Çok daha kolay olacak.
İkinci işlev aralık referansıdır. Bu aralığı ifadelerinizde kullanabilirsiniz. Çoğaltabilir, bölebilir, aktarabilir, başvurabilirsiniz.
Sırada toplama işlevi ailesi var. Toplama işlevi, zaman serilerinizden herhangi birini üç ayrı zaman serisine dönüştürür. Bunlar minimum, maksimum ve ortalamadır. Bunu çok kullanışlı buluyorum çünkü bazen bazı aykırı değerler ve yanlışlıklar gösterebilir.
Ve eğer sadece öfke veya oranlama yapıyorsanız, zaman serisinin beklediğiniz gibi davranmadığı bazı durumları muhtemelen kaçıracaksınız. Bu fonksiyonla görmek çok daha kolay, diyelim ki max, avg'den çok uzak.
Sonraki varsayılan değişkendir. Varsayılan - bu, şu anda bir zaman serimiz yoksa Grafana'da hangi değeri çizmemiz gerektiği anlamına gelir. Bu ne zaman olur? Bazı hata ölçümlerini dışa aktardığınızı varsayalım. Ve o kadar harika bir uygulamanız var ki, başladığınızda sonraki üç saat, hatta bir gün boyunca hiçbir hatanız, hatta hatanız yok. Ve başarıdan hataya olan ilişkiyi gösteren kontrol panelleriniz var. Ve size hiçbir şey göstermeyecekler çünkü bir hata ölçümünüz yok. Ve varsayılan olarak her şeyi belirtebilirsiniz.
Keep_last_Value – eksikse metriğin son değerini kaydeder. Eğer Prometheus bir sonraki kazıma sonrasında 5 dakika içinde bulamazsa burada son değerini hatırlayacağız ve grafikleriniz bir daha bozulmayacaktır.
Scrape_interval – Prometheus'un metriğinize ilişkin verileri ne sıklıkta ve hangi sıklıkta topladığını gösterir. Burada örneğin bir geçiş görebilirsiniz.
Etiket değiştirme popüler bir özelliktir. Ancak bunun biraz karmaşık olduğunu düşünüyoruz çünkü bütün argümanları gerektiriyor. Ve sadece 5 argümanı hatırlamanız değil, aynı zamanda sıralarını da hatırlamanız gerekiyor.
Bu nedenle neden onları daha basit hale getirmiyorsunuz? Yani, anlaşılır sözdizimine sahip küçük işlevlere bölün.
Ve şimdi eğlenceli kısım. Bunun neden genişletilmiş PromQL olduğunu düşünüyoruz? Çünkü Ortak Tablo İfadelerini destekliyoruz. QR kodunu takip edebilirsiniz (), yalnızca tarayıcıya yüklemeden VictoriaMetrics'te sorguları doğrudan çalıştırabileceğiniz oyun alanından örnekler içeren bağlantılara bakın.
Peki bu nedir? Yukarıdaki bu talep oldukça popüler bir taleptir. Birçok şirketin herhangi bir kontrol panelinde her şey için aynı filtreyi kullandığınızı düşünüyorum. Genellikle öyle. Ancak yeni bir filtre eklemeniz gerektiğinde, her paneli güncellemeniz veya kontrol panelini indirmeniz, JSON'da açmanız, değiştirmeyi bulmanız gerekir; bu da zaman alır. Neden bu değeri bir değişkende saklayıp yeniden kullanmıyorsunuz? Bana göre bu çok daha basit ve net görünüyor.
Örneğin, tüm isteklerde Grafana'daki filtreleri güncellemem gerektiğinde ve kontrol paneli çok büyük olabilir veya bunlardan birkaçı bile olabilir. Grafana'daki bu sorunu nasıl çözmek isterim?
Bu sorunu şu şekilde çözüyorum: Bir commonFilter yapıyorum ve bu filtreyi onun içinde tanımlıyorum ve ardından bunu sorgularda yeniden kullanıyorum. Ancak şimdi aynısını yaparsanız işe yaramaz çünkü Grafana, sorgu değişkenleri içindeki değişkenleri kullanmanıza izin vermez. Ve bu biraz tuhaf.
Ve ben de bunu yapmanıza izin veren bir seçenek yaptım. Ve eğer böyle bir özellik ilginizi çekiyorsa veya istiyorsanız, o zaman onu destekleyin veya bu fikirden hoşlanmazsanız beğenmeyin.
PromQL genişletilmiş hakkında daha fazla bilgi. Burada sadece bir değişkeni değil, bütün bir fonksiyonu tanımlıyoruz. Biz buna ru (kaynak kullanımı) diyoruz. Ve bu fonksiyon ücretsiz kaynakları, kaynak sınırlamasını ve filtreyi kabul eder. Sözdizimi basit görünüyor. Bu işlevi kullanmak ve sahip olduğumuz boş hafızanın yüzdesini hesaplamak çok kolaydır. Yani hafızamız ne kadardır, sınırlama nedir ve nasıl filtrelenir. Hepsini aynı filtreleri kullanarak yazarsanız çok daha kullanışlı görünür çünkü bu çok büyük bir sorguya dönüşür.
Ve işte böylesine büyük bir talebin örneği. Grafana'nın resmi NodeExporter kontrol panelindendir. Ama burada neler olduğunu zar zor anlıyorum. Yani yakından bakarsanız elbette anlıyorum ama parantezlerin sayısı burada olup biteni anlama motivasyonunu anında azaltabilir. Ve neden bunu daha basit ve anlaşılır hale getirmiyorsunuz?
Mesela önemli şeyleri veya parçaları değişkenlere ayırmak gibi. Ve sonra temel matematiğinizi yapın. Bu zaten daha çok programlamaya benziyor, gelecekte Grafana'da görmek istediğim şey bu.
Bu ru işlevine zaten sahip olsaydık ve doğrudan VictoriaMetrics'te mevcut olsaydı, bunu nasıl daha da kolaylaştırabileceğimize dair ikinci bir örneği burada bulabilirsiniz. Daha sonra CTE'de bildirdiğiniz önbelleğe alınmış değeri iletmeniz yeterlidir.
Doğru programlama dilini kullanmanın ne kadar önemli olduğundan daha önce bahsetmiştim. Ve muhtemelen Grafana'daki her şirkette farklı şeyler oluyor. Muhtemelen geliştiricilerinize de Grafana'ya erişim izni veriyorsunuz ve geliştiriciler de kendi işlerini yapıyorlar. Ve hepsi bunu bir şekilde farklı şekilde yapıyor. Ama bir şekilde aynı olmasını, yani ortak bir standarda indirilmesini istedim.
Diyelim ki sadece sistem mühendisleriniz bile yok; hatta belki uzmanlarınız, geliştiricileriniz veya SRE'niz bile var. Belki izlemenin ne olduğunu bilen, Grafana'nın ne olduğunu bilen, yani yıllardır onunla çalışan ve bunu nasıl doğru yapacağını tam olarak bilen uzmanlarınız vardır. Zaten bunu 100 kere yazıp herkese açıkladılar ama nedense kimse dinlemiyor.
Ya diğer kullanıcıların özellikleri yeniden kullanabilmesi için bu bilgiyi doğrudan Grafana'ya aktarabilselerdi? Ve eğer boş hafızanın yüzdesini hesaplamaları gerekiyorsa, fonksiyonu uygulayacaklardı. İhracatçıların yaratıcıları, ürünlerinin yanı sıra, metrikleriyle nasıl çalışacaklarına dair bir dizi işlev de sağlasaydı, çünkü bu metriklerin tam olarak ne olduğunu ve bunları nasıl doğru şekilde hesaplayacaklarını biliyorlardı?
Bu gerçekten mevcut değil. Ben de bunu yaptım. Bu Grafana'daki kütüphane desteğidir. Diyelim ki NodeExporter'ı yapan adamlar benim bahsettiğimi yaptılar. Ayrıca bir dizi işlev de sağladılar.
Yani buna benzer bir şeye benziyor. Bu kütüphaneyi Grafana'ya bağlarsınız, düzenlemeye başlarsınız ve bu metrikle nasıl çalışılacağı JSON'da çok basit bir şekilde yazılmıştır. Yani, bazı işlevler kümesi, bunların açıklamaları ve neye dönüştükleri.
Bunun faydalı olabileceğini düşünüyorum çünkü o zaman Grafana'da aynen böyle yazarsınız. Ve Grafana size falan kütüphaneden falan filan fonksiyon olduğunu "söyler" - hadi kullanalım. Bence bu çok hoş olurdu.
VictoriaMetrics hakkında biraz. Pek çok ilginç şey yapıyoruz. Sıkıştırma, diğer zaman serisi veri uygulamalarıyla yarışmalarımız, PromQL ile nasıl çalışılacağına dair açıklamalarımız hakkında makalelerimizi okuyun, çünkü bu konuda hala çok sayıda yeni başlayan var, ayrıca dikey ölçeklenebilirlik ve Thanos ile yüzleşme hakkında.
Sorular:
Soruma basit bir hayat hikayesiyle başlayacağım. Grafana'yı ilk kullanmaya başladığımda 5 satır uzunluğunda oldukça ilgi çekici bir sorgu yazmıştım. Sonuç oldukça ikna edici bir grafiktir. Bu program neredeyse üretime geçti. Ancak daha yakından incelendiğinde, rakamların görmeyi beklediğimiz aralıkta olmasına rağmen, bu grafiğin gerçeklikle hiçbir ilgisi olmayan mutlak bir saçmalık gösterdiği ortaya çıktı. Ve sorum. Kütüphanelerimiz var, fonksiyonlarımız var ama Grafana için testleri nasıl yazacağız? Gerçek bir sunucu konteyneri sipariş etmek veya sipariş vermemek gibi bir iş kararının bağlı olduğu karmaşık bir talep yazdınız. Ve bildiğimiz gibi grafiği çizen bu fonksiyon gerçeğe benzer. Teşekkür ederim.
Soru için teşekkürler. İki bölüm var. İlk olarak, deneyimlerime dayanarak çoğu kullanıcının grafiklerine baktıklarında onlara ne gösterdiklerini anlamadığı izlenimini edindim. Bazı nedenlerden dolayı insanlar, bir fonksiyon içindeki bir hata olsa bile, grafiklerde meydana gelen herhangi bir anormallik için bahane bulma konusunda çok başarılıdırlar. Ve ikinci kısım - bana öyle geliyor ki, geliştiricilerinizin her birinin kendi kapasite planlamasını yapması ve belirli bir olasılıkla hatalar yapması yerine, bu tür işlevleri kullanmak sorununuzu çözmek için çok daha iyi bir yaklaşım olacaktır.
Nasıl kontrol edilir?
Nasıl kontrol edilir? Muhtemelen değil.
Grafana'da bir test olarak.
Grafana'nın bununla ne ilgisi var? Grafana bu isteği doğrudan DataSource'a çevirir.
Parametrelere biraz ekleme.
Hayır, Grafana'ya hiçbir şey eklenmez. Adım gibi GET parametreleri olabilir. Açıkça belirtilmemiştir, ancak geçersiz kılabilirsiniz veya geçersiz kılmayabilirsiniz, ancak otomatik olarak eklenir. Buraya test yazmayacaksınız. Burada gerçeğin kaynağı olarak Grafana'ya güvenmemiz gerektiğini düşünmüyorum.
Rapor için teşekkürler! Sıkıştırma için teşekkürler! Grafana'da bir değişkenin içinde bir değişkeni kullanamayacağınızdan, bir grafikte bir değişkeni eşlediğinizden bahsettiniz. Ne demek istediğimi biliyor musun?
Evet.
Grafana'da bir uyarı oluşturmak istediğimde bu başlangıçta baş ağrısıydı. Ve orada her ana bilgisayar için ayrı ayrı bir uyarı yapmanız gerekiyor. Yaptığın bu şey Grafana'daki uyarılar için işe yarıyor mu?
Grafana değişkenlere farklı şekilde erişmiyorsa evet işe yarayacaktır. Ancak benim tavsiyem Grafana'da uyarıyı hiç kullanmamanız, uyarı yöneticisini kullanmanız daha iyi olur.
Evet kullanıyorum ama Grafana'da kurulumu daha kolay gibi geldi ama tavsiyen için teşekkürler!
Kaynak: habr.com