Saya mencadangkan untuk membaca transkrip laporan oleh Roman Khavronenko "ExtendedPromQL"
Secara ringkas tentang saya. Nama saya Roman. Saya bekerja untuk CloudFlare dan tinggal di London. Tetapi saya juga seorang penyelenggara VictoriaMetrics.
Dan saya adalah pengarangnya untuk Grafana dan ialah proksi kecil untuk ClickHouse.
Kami akan mulakan dengan bahagian pertama, yang dipanggil "Kesukaran Terjemahan" dan di dalamnya saya akan bercakap tentang fakta bahawa mana-mana bahasa atau bahkan hanya bahasa komunikasi adalah sangat penting. Kerana ini adalah cara anda menyampaikan fikiran anda kepada orang atau sistem lain, cara anda merumuskan permintaan. Orang di Internet bertengkar tentang bahasa mana yang lebih baik - java atau bahasa lain. Untuk diri saya sendiri, saya memutuskan bahawa perlu memilih tugas, kerana semua ini khusus.
Mari kita mulakan dari awal lagi. Apakah PromQL? PromQL ialah Bahasa Pertanyaan Prometheus. Beginilah cara kami membentuk pertanyaan dalam Prometheus untuk mendapatkan data siri masa, siri masa.
Apakah data siri masa? Secara harfiah, ini adalah tiga parameter.
Ini adalah:
- Apa yang kita lihat.
- Apabila kita melihatnya.
- Dan apakah nilai yang ditunjukkan.
Jika anda melihat carta ini (carta ini adalah daripada telefon saya, yang menunjukkan statistik langkah saya), maka di sini anda boleh menjawab soalan ini dengan cepat.
Kami melihat langkah. Kita melihat makna dan kita melihat masa apabila kita melihatnya. Iaitu, melihat rajah ini, anda boleh dengan mudah mengatakan bahawa pada hari Ahad saya berjalan kira-kira 15 langkah. Ini adalah data siri masa.
Sekarang mari kita "pecahkan" (ubah) mereka menjadi model data lain dalam bentuk jadual. Di sini kita juga mempunyai apa yang kita lihat. Di sini saya menambah sedikit data tambahan, yang akan kita panggil meta-data, iaitu, bukan saya yang lalui, tetapi dua orang, contohnya, Jay dan Silent Bob. Itulah yang kami lihat; apa yang ditunjukkan dan bila ia menunjukkan nilai itu.
Sekarang mari cuba simpan semua data ini dalam pangkalan data. Sebagai contoh, saya mengambil sintaks ClickHouse. Dan di sini kita mencipta satu jadual yang dipanggil "Langkah", iaitu apa yang kita lihat. Ada masa di sini apabila kita melihatnya; apa yang ditunjukkan dan beberapa meta-data di mana kami akan menyimpan siapa itu: Jay dan Silent Bob.
Dan untuk cuba menggambarkan semuanya, kami akan menggunakan Grafana, kerana, pertama, ia cantik.
Juga kami akan menggunakan pemalam ini. Terdapat dua sebab untuk ini. Yang pertama adalah kerana saya menulisnya. Dan saya tahu betapa sukarnya untuk mengeluarkan data siri masa dari ClickHouse untuk menunjukkannya dalam Grafana.
Kami akan memaparkan dalam Panel Graf. Ini ialah panel paling popular dalam Grafana dan menunjukkan nilai berbanding masa, jadi kami hanya memerlukan dua parameter.
Mari tulis pertanyaan paling mudah - bagaimana untuk menunjukkan statistik langkah dalam Grafana, menyimpan data ini dalam ClickHouse, dalam jadual yang kami buat. Dan kami menulis pertanyaan yang begitu mudah. Kami memilih daripada langkah. Kami memilih nilai dan memilih masa nilai ini, iaitu tiga parameter yang sama yang kami bincangkan.
Dan sebagai hasilnya, kami mendapat graf ini. Siapa tahu kenapa dia pelik?
Betul, anda perlu menyusun mengikut masa.
Dan pada akhirnya kami mendapat jadual yang lebih baik, tetapi masih pelik. Siapa tahu kenapa? Betul, terdapat dua peserta, dan kami memberikan dua siri masa dalam Grafana, kerana jika kami berurusan dengan model data sekali lagi, maka setiap siri masa ialah gabungan unik nama dan semua nilai kunci label.
Oleh itu, kita perlu memilih orang tertentu. Kami pilih Jay.
Dan lukis lagi. Sekarang graf itu kelihatan seperti kebenaran. Sekarang ia adalah jadual biasa dan semuanya berfungsi dengan baik.
Dan, mungkin, anda tahu bagaimana untuk melakukan perkara yang sama, tetapi dalam Prometheus melalui PromQL. Lebih kurang begini. Mudah sikit. Dan mari kita pecahkan semuanya. Kami mengambil Langkah. Dan tapis oleh Jay. Kami tidak menyatakan di sini bahawa kami perlu mendapatkan nilai dan kami tidak memilih masa.
Sekarang mari kita cuba mengira kelajuan pergerakan Jay atau Silent Bob. Dalam ClickHouse, kita perlu melakukan runningDifference, iaitu, mengira perbezaan antara pasangan mata dan membahagikannya mengikut masa untuk mendapatkan kelajuan yang tepat. Permintaan akan kelihatan seperti ini.
Dan dia akan menunjukkan lebih kurang nilai ini, iaitu kira-kira 1,8 langkah sesaat melakukan Silent Bob atau Jay.
Dan dalam Prometheus anda juga tahu cara melakukannya. Jauh lebih mudah daripada sebelumnya.
Dan untuk menjadikannya juga mudah dilakukan dalam Grafana, saya menambah pembungkus sedemikian yang kelihatan sangat serupa dengan PromQL. Ia dipanggil Makro Kadar, atau apa sahaja yang anda mahu panggil. Dalam Grafana, anda hanya menulis "kadar", tetapi di suatu tempat jauh di dalam ia berubah menjadi permintaan yang begitu besar. Dan anda tidak perlu melihatnya, ia ada di suatu tempat, tetapi anda menjimatkan banyak masa, kerana menulis pertanyaan SQL yang besar itu sentiasa mahal. Anda boleh dengan mudah membuat kesilapan dan kemudian tidak memahami apa yang berlaku untuk masa yang lama.
Dan ini adalah pertanyaan yang tidak sesuai pada satu slaid, malah saya terpaksa membahagikannya kepada dua lajur. Ini juga merupakan permintaan dalam ClickHouse, yang membuat kadar yang sama, tetapi untuk kedua-dua siri masa: Silent Bob dan Jay, supaya kami mempunyai dua siri masa pada panel. Dan ini sudah sangat sukar, pada pendapat saya.
Dan menurut Prometheus ia akan menjadi jumlah (kadar). Untuk ClickHouse saya membuat makro berasingan yang dipanggil RateColumns yang kelihatan seperti pertanyaan Prometheus.
Kami melihat dan nampaknya PromQL semuanya sangat keren, tetapi sudah tentu, ia mempunyai batasan.
Ini adalah:
- PILIHAN terhad.
- Edge JOINs.
- Tiada sokongan HAVING.
Dan jika anda telah bekerja dengannya untuk masa yang lama, maka anda tahu bahawa kadang-kadang sangat sukar untuk melakukan sesuatu dalam PromQL, dan dalam SQL anda boleh melakukan hampir segala-galanya, kerana semua pilihan yang baru kita bincangkan ini boleh dilakukan dalam SQL . Tetapi adakah ia mudah untuk menggunakannya? Dan ini membuatkan saya berfikir bahawa tidak semestinya bahasa yang paling berkuasa boleh menjadi yang paling mudah.
Oleh itu, kadangkala anda perlu memilih bahasa untuk tugasan. Ia seperti pertempuran antara Batman dan Superman. Sudah jelas bahawa Superman lebih kuat, tetapi Batman dapat mengalahkannya kerana dia lebih praktikal dan tahu apa yang dia lakukan.
Dan bahagian seterusnya ialah Memanjangkan PromQL.
Sekali lagi mengenai VictoriaMetrics. Apakah itu VictoriaMetrics? Ini adalah pangkalan data siri masa, ia berada dalam OpenSource, kami mengedarkan versi tunggal dan kelompoknya. Menurut penanda aras kami, ia adalah yang terpantas yang ada di pasaran sekarang dan ia adalah serupa dari segi pemampatan, iaitu orang yang masih hidup melaporkan pemampatan kira-kira 0,4 bait setiap titik, apabila Prometheus mempunyai 1,2-1,4.
Kami menyokong bukan sahaja Prometheus. Kami menyokong InfluxDB, Graphite, OpenTSDB.
Anda boleh "menulis" dalam kami, iaitu, anda boleh memindahkan data lama.
Dan kami juga berfungsi dengan sempurna dengan Prometheus dan Grafana, iaitu kami menyokong enjin PromQL. Dan dalam Grafana, anda boleh menukar titik akhir Prometheus kepada VictoriaMetrics dan semua papan pemuka anda akan berfungsi seperti yang dilakukan.
Tetapi anda juga boleh menggunakan cip tambahan yang disediakan oleh VictoriaMetrics.
Kami akan menyemak ciri yang telah kami tambahkan dengan cepat.
Abaikan param selang - anda boleh melangkau selang parameter dalam Grafana. Apabila anda tidak mahu mendapatkan graf aneh apabila zum masuk/keluar dalam panel, adalah disyorkan untuk menggunakan pembolehubah $__interval. Ini ialah perubahan Grafana dalaman dan ia memilih julat data itu sendiri. Dan VictoriaMetrics sendiri boleh memahami julat ini. Dan anda tidak perlu mengemas kini semua pertanyaan anda. Ia akan menjadi lebih mudah.
Fungsi kedua ialah rujukan selang. Anda boleh menggunakan jarak ini dalam ungkapan anda. Anda boleh mendarab, membahagi, memindahkan, merujuk kepadanya.
Seterusnya ialah keluarga fungsi rollup. Fungsi rollup mengubah mana-mana siri masa anda kepada tiga siri masa yang berasingan. Ini ialah min, maks dan purata. Saya rasa ia sangat mudah, kerana kadangkala ia boleh menunjukkan beberapa penyimpangan (anomali) dan ketidaktepatan.
Dan jika anda hanya marah atau menilai, maka anda mungkin terlepas beberapa kes di mana siri masa tidak berkelakuan seperti yang anda inginkan. Ia lebih mudah untuk dilihat dengan fungsi ini, katakan maks adalah sangat jauh daripada purata.
Seterusnya ialah pembolehubah lalai. Lalai - ini bermakna nilai yang perlu kita lukis dalam Grafana jika kita tidak mempunyai siri masa pada masa ini. Bilakah ia berlaku? Katakan anda mengeksport beberapa metrik ralat. Dan anda mempunyai aplikasi yang hebat sehingga apabila anda mulakan, anda tidak mempunyai ralat malah tiada ralat untuk tiga jam seterusnya atau sehari. Dan anda mempunyai papan pemuka yang menunjukkan hubungan daripada kejayaan kepada kesilapan. Dan mereka tidak akan menunjukkan kepada anda apa-apa kerana anda tidak mempunyai metrik ralat. Dan secara lalai anda boleh menentukan apa sahaja.
Keep_last_Value - menyimpan nilai terakhir metrik jika tiada. Jika Prometheus selepas pengikisan seterusnya tidak menemuinya dalam masa 5 minit, maka di sini kami akan mengingati nilai terakhirnya dan carta anda tidak akan pecah lagi.
Scrape_interval - menunjukkan kekerapan Prometheus mengumpul data pada metrik anda, dengan kekerapan. Di sini anda boleh melihat pas, sebagai contoh.
Penggantian label ialah ciri yang popular. Tetapi kami fikir ia agak rumit kerana ia memerlukan hujah integer. Dan anda perlu bukan sahaja mengingati 5 hujah, tetapi juga mengingati urutannya.
Oleh itu, mengapa tidak menjadikannya lebih mudah? Iaitu, pecahkannya kepada fungsi kecil dengan sintaks yang jelas.
Dan kini yang paling menarik. Mengapa kami fikir ia dilanjutkan PromQL? Kerana kami menyokong Ungkapan Jadual Biasa. Anda boleh mengikuti kod QR (), lihat pautan dengan contoh, dari taman permainan, di mana anda boleh menjalankan pertanyaan terus dalam VictoriaMetrics tanpa memasangnya hanya dalam penyemak imbas.
Dan apa itu? Permintaan dari atas ini adalah permintaan yang agak popular. Saya fikir dalam mana-mana papan pemuka di banyak syarikat anda menggunakan penapis yang sama untuk segala-galanya. Selalunya begitu. Tetapi apabila anda perlu menambah beberapa penapis baharu, anda perlu mengemas kini setiap panel, atau memuat turun papan pemuka, membukanya dalam JSON, lakukan penggantian carian, yang juga memerlukan masa. Mengapa tidak menyimpan nilai ini dalam pembolehubah dan menggunakannya semula? Ia kelihatan, pada pendapat saya, lebih mudah dan lebih jelas.
Sebagai contoh, apabila saya perlu mengemas kini penapis dalam Grafana dalam semua permintaan, dan papan pemuka boleh menjadi besar atau mungkin terdapat beberapa daripadanya. Dan bagaimana saya ingin menyelesaikan masalah ini di Grafana?
Saya menyelesaikan masalah ini seperti ini: Saya membuat commonFilter dan menentukan penapis ini di dalamnya, dan kemudian saya menggunakannya semula dalam pertanyaan. Tetapi jika anda melakukan perkara yang sama sekarang, ia tidak akan berfungsi kerana Grafana tidak membenarkan anda menggunakan pembolehubah di dalam pembolehubah pertanyaan. Dan ia sedikit pelik.
Jadi saya membuat pilihan yang membolehkan anda melakukan ini. Dan jika anda berminat atau mahukan ciri sedemikian, maka sokong atau tidak suka jika anda tidak menyukai idea ini.
Lebih lanjut mengenai PromQL dilanjutkan. Di sini kita mentakrifkan bukan sahaja pembolehubah, tetapi secara langsung keseluruhan fungsi. Dan kami memanggilnya ru (penggunaan sumber). Dan fungsi ini menerima sumber percuma, had sumber dan penapis. Sintaks nampaknya mudah. Dan sangat mudah untuk menggunakan fungsi ini dan mengira peratusan memori percuma yang kita ada. Iaitu, berapa banyak memori yang kita ada, berapa had dan bagaimana untuk menapis. Ia kelihatan lebih baik jika anda menulis semuanya menggunakan semula penapis yang sama, kerana ia akan bertukar menjadi pertanyaan besar dan besar.
Dan inilah contoh permintaan yang begitu besar dan besar. Ia daripada papan pemuka rasmi NodeExporter untuk Grafana. Tetapi saya tidak begitu faham apa yang berlaku di sini. Itu, sudah tentu, saya faham jika anda melihat dengan teliti, tetapi bilangan kurungan boleh mengurangkan motivasi untuk memahami apa yang berlaku di sini. Dan mengapa tidak menjadikannya lebih mudah dan lebih jelas?
Sebagai contoh, seperti ini, menonjolkan perkara atau bahagian penting dalam pembolehubah. Dan kemudian lakukan matematik asas anda. Ini sudah lebih seperti pengaturcaraan, inilah yang saya ingin lihat pada masa hadapan di Grafana.
Berikut ialah contoh kedua bagaimana kita boleh menjadikannya lebih mudah jika kita sudah mempunyai fungsi ru ini, dan ia sudah wujud secara langsung dalam VictoriaMetrics. Dan kemudian anda hanya lulus nilai cache yang anda isytiharkan dalam CTE.
Saya telah bercakap tentang betapa pentingnya menggunakan bahasa pengaturcaraan yang betul. Dan, mungkin, sesuatu yang berbeza sedang berlaku di Grafana di setiap syarikat. Dan, mungkin, anda masih memberikan akses kepada Grafana kepada pembangun anda, dan pembangun melakukan sesuatu sendiri. Dan mereka semua melakukannya dengan cara yang berbeza. Tetapi saya mahu ia entah bagaimana sama, iaitu, dikurangkan kepada standard biasa.
Katakan anda tidak mempunyai jurutera sistem, malah mungkin anda mempunyai pakar, devops atau SRE. Mungkin anda mempunyai pakar yang tahu apa itu pemantauan, tahu apa itu Grafana, iaitu mereka telah bekerja dengan ini selama bertahun-tahun dan mereka tahu dengan tepat cara melakukannya dengan betul. Dan mereka sudah menulisnya 100 kali dan menerangkannya kepada semua orang, tetapi atas sebab tertentu tiada siapa yang mendengar.
Bagaimana jika mereka boleh meletakkan pengetahuan ini terus ke dalam Grafana supaya pengguna lain boleh menggunakan semula fungsi tersebut? Dan jika perlu untuk mengira peratusan memori percuma, maka mereka hanya akan menggunakan fungsi itu. Tetapi bagaimana jika pencipta pengeksport, bersama-sama dengan produk mereka, turut menyediakan satu set fungsi, cara bekerja dengan metrik mereka, kerana mereka tahu dengan tepat apakah metrik ini dan cara mengiranya dengan betul?
Yang ini sebenarnya tidak wujud. Inilah yang saya lakukan sendiri. Ini ialah sokongan perpustakaan di Grafana. Katakan orang yang membuat NodeExporter melakukan apa yang saya nyatakan. Dan juga menyediakan satu set ciri.
Iaitu, ia kelihatan seperti ini. Anda menyambungkan pustaka ini kepada Grafana, anda pergi ke pengeditan, dan di sini adalah sangat mudah dalam JSON cara bekerja dengan metrik ini. Iaitu, beberapa set fungsi, huraian mereka dan apa yang mereka terungkap.
Pada pendapat saya, ini boleh berguna, kerana kemudian anda akan menulis dalam Grafana begitu sahaja. Dan Grafana "memberitahu" anda bahawa terdapat fungsi ini dan ini dari perpustakaan itu dan ini - mari kita gunakannya. Saya fikir ia akan menjadi sangat keren.
Sedikit tentang VictoriaMetrics. Kami melakukan banyak perkara yang menarik. Baca artikel kami tentang pemampatan, tentang persaingan kami dengan aplikasi data siri masa yang lain, penjelasan kami tentang cara bekerja dengan PromQL, kerana terdapat ramai lagi pemula dalam hal ini, serta tentang kebolehskalaan menegak dan tentang konfrontasi dengan Thanos.
Soalan:
Saya akan mulakan soalan saya dengan kisah hidup yang mudah. Apabila saya mula menggunakan Grafana, saya menulis pertanyaan 5 baris yang sangat meyakinkan. Hasil akhirnya adalah carta yang sangat meyakinkan. Graf ini hampir masuk ke dalam pengeluaran. Tetapi apabila diteliti lebih dekat, ternyata carta ini menunjukkan karut mutlak yang tidak ada kena mengena dengan realiti, walaupun angka-angka itu jatuh ke dalam julat yang kami jangkakan untuk melihat. Dan soalan saya. Kami mempunyai perpustakaan, kami mempunyai fungsi, tetapi bagaimana kami menulis ujian untuk Grafana? Anda telah menulis pertanyaan kompleks yang mempengaruhi keputusan perniagaan - untuk memesan bekas sebenar pelayan atau tidak untuk memesan. Dan seperti yang kita tahu, fungsi yang melukis graf ini adalah serupa dengan kebenaran. Terima kasih.
Terima kasih atas soalan. Terdapat dua bahagian di sini. Pertama, saya mendapat tanggapan, berdasarkan pengalaman saya, bahawa kebanyakan pengguna, apabila mereka melihat carta mereka, tidak memahami apa yang mereka tunjukkan kepada mereka. Entah bagaimana, orang sangat mahir untuk mengemukakan alasan untuk sebarang anomali yang berlaku pada carta, walaupun ia adalah pepijat dalam fungsi. Dan bahagian kedua - nampaknya saya menggunakan fungsi sedemikian akan lebih sesuai untuk menyelesaikan masalah anda, dan bukannya setiap pembangun anda melakukan perancangan kapasiti mereka sendiri dan membuat kesilapan dengan beberapa kemungkinan.
Bagaimana untuk menyemak?
Bagaimana untuk menyemak? Mungkin tidak.
Sebagai ujian di Grafana.
Dan bagaimana dengan Grafana? Grafana menterjemah permintaan ini terus ke DataSource.
Dengan menambah sedikit pada parameter.
Tidak, tiada apa yang ditambahkan pada Grafana. Mungkin terdapat parameter GET, seperti langkah. Ia tidak dinyatakan secara eksplisit, tetapi anda boleh mengatasinya, anda tidak boleh mengatasinya, tetapi ia ditambah secara automatik. Anda tidak menulis ujian di sini. Saya tidak fikir anda harus bergantung pada Grafana di sini sebagai sumber kebenaran.
Terima kasih atas laporan itu! Terima kasih atas pemampatan! Anda teringat tentang memetakan pembolehubah dalam graf, bahawa dalam Grafana anda tidak boleh menggunakan pembolehubah dalam pembolehubah. Adakah awak faham apa yang saya maksudkan?
Ya.
Ini pada mulanya sakit kepala apabila saya ingin membuat amaran di Grafana. Dan di sana anda perlu melakukan makluman untuk setiap hos secara berasingan. Inilah perkara yang anda lakukan ini, adakah ia berfungsi untuk makluman dalam Grafana?
Jika Grafana tidak mengakses pembolehubah dalam beberapa cara lain, maka ya, ia akan berfungsi. Tetapi nasihat saya adalah untuk tidak menggunakan amaran dalam Grafana sama sekali, anda lebih baik menggunakan alertmanager.
Ya, saya menggunakannya, tetapi nampaknya lebih mudah untuk disediakan di Grafana, tetapi terima kasih atas petuanya!
Sumber: www.habr.com