پیشنهاد می کنم متن گزارش رومن خاروننکو "ExtendedPromQL" را بخوانید.
خلاصه در مورد من اسم من رومن است. من برای CloudFlare کار می کنم و در لندن زندگی می کنم. اما من یک نگهدارنده VictoriaMetrics نیز هستم.
و من نویسنده هستم برای گرافانا و یک پروکسی کوچک برای ClickHouse است.
ما با قسمت اول که «مشکلات ترجمه» نام دارد شروع می کنیم و در آن درباره این واقعیت صحبت خواهم کرد که هر زبانی یا حتی فقط یک زبان ارتباطی بسیار مهم است. زیرا این گونه است که افکار خود را به شخص یا سیستم دیگری منتقل می کنید، چگونه یک درخواست را فرموله می کنید. مردم در اینترنت در مورد اینکه کدام زبان بهتر است بحث می کنند - جاوا یا زبان دیگر. برای خودم، تصمیم گرفتم که انتخاب یک کار ضروری است، زیرا همه اینها خاص است.
بیایید از همان ابتدا شروع کنیم. PromQL چیست؟ PromQL زبان پرس و جو Prometheus است. اینگونه است که ما در Prometheus کوئری ها را برای بدست آوردن داده های سری زمانی، سری های زمانی تشکیل می دهیم.
داده های سری زمانی چیست؟ به معنای واقعی کلمه، اینها سه پارامتر هستند.
این ها عبارتند از:
- ما داریم به چه چیزی نگاه می کنیم.
- وقتی به آن نگاه می کنیم.
- و چه ارزشی را نشان می دهد.
اگر به این نمودار نگاه کنید (این نمودار مربوط به گوشی من است که آمار مراحل من را نشان می دهد) در اینجا می توانید به سرعت به این سوالات پاسخ دهید.
ما در حال بررسی مراحل هستیم. وقتی به آن نگاه می کنیم معنا را می بینیم و زمان را می بینیم. یعنی با دیدن این نمودار به راحتی می توان گفت که روز یکشنبه حدود 15 قدم راه رفتم. این داده های سری زمانی است.
حالا بیایید آنها را در قالب یک جدول به مدل داده دیگری "تبدیل" کنیم. در اینجا ما نیز چیزی را داریم که به آن نگاه می کنیم. در اینجا من یک داده اضافی اضافه کردم که ما آن را متا دیتا می نامیم، یعنی این من نبودم که از آن عبور کردم، بلکه دو نفر به عنوان مثال جی و سایلنت باب. این چیزی است که ما به آن نگاه می کنیم. چه چیزی را نشان می دهد و چه زمانی آن ارزش را نشان می دهد.
حالا بیایید سعی کنیم تمام این داده ها را در پایگاه داده ذخیره کنیم. برای مثال، من دستور ClickHouse را گرفتم. و در اینجا ما یک جدول به نام "Steps" ایجاد می کنیم، یعنی چیزی که به آن نگاه می کنیم. در اینجا زمانی است که ما به آن نگاه می کنیم. آنچه را نشان می دهد و برخی متا داده ها را در جایی ذخیره می کنیم که کیست: جی و سایلنت باب.
و برای اینکه سعی کنیم همه آن را تجسم کنیم، از Grafana استفاده می کنیم، زیرا اولاً زیبا است.
همچنین ما از این افزونه استفاده خواهیم کرد. دو دلیل برای این وجود دارد. اولین دلیل این است که من آن را نوشتم. و من دقیقا می‌دانم که استخراج داده‌های سری زمانی از ClickHouse برای نمایش آن در Grafana چقدر سخت است.
ما در پنل نمودار نمایش خواهیم داد. این محبوب ترین پنل در Grafana است و ارزش را در مقابل زمان نشان می دهد، بنابراین ما فقط به دو پارامتر نیاز داریم.
بیایید ساده ترین پرس و جو را بنویسیم - نحوه نمایش آمار مرحله در Grafana، ذخیره این داده ها در ClickHouse، در جدولی که ایجاد کردیم. و ما چنین پرس و جوی ساده ای می نویسیم. ما از بین مراحل انتخاب می کنیم. یک مقدار را انتخاب می کنیم و زمان این مقادیر، یعنی همان سه پارامتری که در مورد آن صحبت کردیم را انتخاب می کنیم.
و در نتیجه این نمودار را دریافت می کنیم. کی میدونه چرا اینقدر عجیبه؟
درست است، شما باید بر اساس زمان مرتب کنید.
و در پایان ما یک برنامه بهتر، اما هنوز هم عجیب و غریب به دست می آوریم. چه کسی می داند چرا؟ درست است، دو شرکت کننده وجود دارد، و ما دو سری زمانی را در Grafana تقدیم می کنیم، زیرا اگر دوباره با مدل داده سروکار داشته باشیم، هر سری زمانی ترکیبی منحصر به فرد از یک نام و همه برچسب ها کلید-مقدار است.
بنابراین، ما باید یک فرد خاص را انتخاب کنیم. ما جی را انتخاب می کنیم.
و دوباره نقاشی کنید. اکنون نمودار به نظر حقیقت می رسد. اکنون برنامه عادی است و همه چیز به خوبی پیش می رود.
و احتمالاً شما می دانید که چگونه در مورد همان کار انجام دهید، اما در Prometheus از طریق PromQL. تقریبا اینجوری کمی راحت تر و بیایید همه چیز را تجزیه کنیم. قدم برداشتیم و فیلتر توسط جی. ما در اینجا مشخص نمی کنیم که باید یک مقدار بدست آوریم و زمان را انتخاب نمی کنیم.
حالا بیایید سعی کنیم سرعت حرکت جی یا سایلنت باب را محاسبه کنیم. در ClickHouse، باید runDifference را انجام دهیم، یعنی تفاوت بین جفت نقاط را محاسبه کرده و آنها را بر زمان تقسیم کنیم تا سرعت دقیق را بدست آوریم. درخواست چیزی شبیه به این خواهد بود.
و تقریباً این مقادیر را نشان خواهد داد، یعنی تقریباً 1,8 قدم در ثانیه Silent Bob یا Jay.
و در پرومتئوس شما نیز می دانید که چگونه این کار را انجام دهید. خیلی راحت تر از قبل
و برای اینکه انجام آن در Grafana نیز آسان شود، چنین لفافی را اضافه کردم که بسیار شبیه به PromQL است. اسمش Rate Macros هست یا هر چی میخوای اسمش بذاری. در Grafana، شما فقط می نویسید "نرخ"، اما در جایی در اعماق آن به یک درخواست بزرگ تبدیل می شود. و حتی لازم نیست به آن نگاه کنید، جایی وجود دارد، اما در زمان زیادی صرفه جویی می کنید، زیرا نوشتن چنین پرس و جوهای SQL عظیمی همیشه گران است. شما به راحتی می توانید اشتباه کنید و بعد مدت طولانی متوجه نشوید که چه اتفاقی دارد می افتد.
و این پرس و جوی است که حتی در یک اسلاید هم قرار نمی گرفت و حتی مجبور شدم آن را به دو ستون تقسیم کنم. این نیز یک درخواست در ClickHouse است که نرخ یکسانی دارد، اما برای هر دو سری زمانی: Silent Bob و Jay، به طوری که ما دو سری زمانی در پنل داشته باشیم. و این در حال حاضر بسیار دشوار است، به نظر من.
و به قول پرومتئوس جمع (نرخ) خواهد بود. برای ClickHouse یک ماکرو جداگانه به نام RateColumns ساختم که شبیه یک پرس و جو Prometheus است.
ما نگاه کردیم و به نظر می‌رسد که PromQL بسیار جالب است، اما البته محدودیت‌هایی دارد.
این ها عبارتند از:
- انتخاب محدود.
- Edge JoINs.
- بدون داشتن پشتیبانی
و اگر برای مدت طولانی با آن کار کرده اید، پس می دانید که گاهی اوقات انجام کاری در PromQL بسیار دشوار است و در SQL تقریباً همه چیز را می توانید انجام دهید، زیرا تمام این گزینه هایی که ما در مورد آنها صحبت کردیم می توانند در SQL انجام شوند. . اما آیا استفاده از آن راحت خواهد بود؟ و این باعث می شود فکر کنم که همیشه قوی ترین زبان نمی تواند راحت ترین باشد.
بنابراین، گاهی اوقات لازم است زبانی را برای کارها انتخاب کنید. مثل نبرد بین بتمن و سوپرمن است. واضح است که سوپرمن قوی تر است، اما بتمن توانست او را شکست دهد زیرا او عملی تر است و دقیقاً می دانست که دارد چه می کند.
و قسمت بعدی Extending PromQL است.
یک بار دیگر در مورد VictoriaMetrics. VictoriaMetrics چیست؟ این یک پایگاه داده سری زمانی است، در OpenSource است، ما نسخه های تک و خوشه ای آن را توزیع می کنیم. با توجه به معیارهای ما، این سریعترین است که در حال حاضر در بازار وجود دارد و از نظر فشرده سازی مشابه است، یعنی افراد زنده فشرده سازی را در حدود 0,4 بایت در هر نقطه گزارش می کنند، در حالی که Prometheus دارای 1,2-1,4 است.
ما نه تنها از پرومتئوس حمایت می کنیم. ما از InfluxDB، Graphite، OpenTSDB پشتیبانی می کنیم.
شما می توانید در ما "نوشتن" کنید، یعنی می توانید داده های قدیمی را انتقال دهید.
و همچنین با Prometheus و Grafana کاملاً کار می کنیم، یعنی از موتور PromQL پشتیبانی می کنیم. و در Grafana، شما به سادگی می توانید نقطه پایانی Prometheus را به VictoriaMetrics تغییر دهید و تمام داشبوردهای شما مانند قبل کار خواهند کرد.
اما می توانید از تراشه های اضافی ارائه شده توسط VictoriaMetrics نیز استفاده کنید.
ما به سرعت ویژگی هایی را که اضافه کرده ایم مرور خواهیم کرد.
پارامتر فاصله را حذف کنید - می توانید فاصله پارامتر را در Grafana رد کنید. هنگامی که نمی خواهید نمودارهای عجیب و غریب هنگام بزرگنمایی/کوچ کردن در پانل دریافت کنید، توصیه می شود از متغیر استفاده کنید. $__interval. این یک تغییر داخلی Grafana است و خود محدوده داده را انتخاب می کند. و VictoriaMetrics خودش می تواند بفهمد که این محدوده باید چقدر باشد. و شما مجبور نیستید تمام سوالات خود را به روز کنید. خیلی راحت تر خواهد بود.
تابع دوم ارجاع فاصله است. می توانید از این فاصله در عبارات خود استفاده کنید. می توانید ضرب کنید، تقسیم کنید، انتقال دهید، به آن رجوع کنید.
بعدی خانواده توابع جمع آوری است. تابع rollup هر یک از سری های زمانی شما را به سه سری زمانی جداگانه تبدیل می کند. اینها حداقل، حداکثر و میانگین هستند. من آن را بسیار راحت می دانم، زیرا گاهی اوقات می تواند برخی موارد دور از ذهن (ناهنجاری) و نادرستی را نشان دهد.
و اگر فقط در حال انجام خشم یا رتبه‌بندی هستید، احتمالاً می‌توانید مواردی را از دست بدهید که در آن سری‌های زمانی آنطور که می‌خواهید رفتار نمی‌کنند. مشاهده با این تابع بسیار ساده تر است، فرض کنید حداکثر مقدار بسیار پایین است.
بعد متغیر پیش فرض است. پیش فرض - این بدان معناست که اگر در حال حاضر سری زمانی نداشته باشیم، باید چه مقداری را در Grafana ترسیم کنیم. چه زمانی اتفاق می افتد؟ فرض کنید برخی از معیارهای خطا را صادر کرده اید. و شما یک برنامه جالب دارید که وقتی شروع می کنید، برای سه ساعت یا حتی یک روز آینده هیچ خطایی و حتی هیچ خطایی ندارید. و داشبوردهایی دارید که روابط را از موفقیت تا خطا نشان می دهد. و آنها چیزی به شما نشان نمی دهند زیرا معیار خطا ندارید. و در حالت پیش فرض می توانید هر چیزی را مشخص کنید.
Keep_last_Value - آخرین مقدار معیار را در صورت عدم وجود آن ذخیره می کند. اگر Prometheus بعد از خراش بعدی آن را در عرض 5 دقیقه پیدا نکرد، در اینجا آخرین مقدار آن را به خاطر می آوریم و نمودارهای شما دوباره شکسته نمی شوند.
Scrape_interval - نشان می دهد که Prometheus هر چند وقت یکبار داده ها را در متریک شما جمع آوری می کند، با چه فرکانس. در اینجا می توانید برای مثال پاس را ببینید.
تعویض برچسب یک ویژگی محبوب است. اما ما فکر می کنیم کمی پیچیده است زیرا به آرگومان های عدد صحیح نیاز دارد. و شما باید نه تنها 5 آرگومان را به خاطر بسپارید، بلکه دنباله آنها را نیز به خاطر بسپارید.
بنابراین، چرا آنها را ساده تر نمی کنیم؟ یعنی آن را به توابع کوچک با نحو واضح تقسیم کنید.
و حالا جالب ترین. چرا فکر می کنیم که PromQL توسعه یافته است؟ زیرا ما از Common Table Expressions پشتیبانی می کنیم. می توانید کد QR را دنبال کنید ()، پیوندهایی را با نمونه‌هایی از زمین بازی ببینید، جایی که می‌توانید درخواست‌ها را مستقیماً در VictoriaMetrics بدون نصب آن فقط در مرورگر اجرا کنید.
و این چیه؟ این درخواست از بالا یک درخواست نسبتاً محبوب است. من فکر می کنم در هر داشبوردی در بسیاری از شرکت ها از یک فیلتر برای همه چیز استفاده می کنید. معمولا اینطور است. اما زمانی که نیاز به افزودن فیلتر جدید دارید، باید هر پنل را به‌روزرسانی کنید، یا داشبورد را دانلود کنید، آن را با JSON باز کنید، جایگزینی را پیدا کنید، که این نیز زمان می‌برد. چرا این مقدار را در یک متغیر ذخیره نمی کنید و دوباره از آن استفاده نمی کنید؟ به نظر من بسیار ساده تر و واضح تر به نظر می رسد.
به عنوان مثال، زمانی که من نیاز به به روز رسانی فیلترها در Grafana در همه درخواست ها دارم، و داشبورد می تواند بزرگ باشد یا حتی می تواند چندین مورد از آنها وجود داشته باشد. و چگونه می خواهم این مشکل را در گرافانا حل کنم؟
من این مشکل را به این صورت حل می کنم: یک CommonFilter می سازم و این فیلتر را در آن تعریف می کنم و سپس از آن در کوئری ها استفاده می کنم. اما اگر همین کار را اکنون انجام دهید، کار نمی کند زیرا Grafana به شما اجازه نمی دهد که از متغیرها در متغیرهای query استفاده کنید. و کمی عجیب است.
و بنابراین من گزینه ای ساختم که به شما امکان می دهد این کار را انجام دهید. و اگر به چنین ویژگی علاقه مند هستید یا می خواهید، اگر این ایده را دوست ندارید از آن حمایت کنید یا آن را دوست نداشته باشید.
اطلاعات بیشتر در مورد PromQL توسعه یافته است. در اینجا ما نه تنها یک متغیر، بلکه مستقیماً کل تابع را تعریف می کنیم. و ما آن را ru (استفاده از منابع) می نامیم. و این تابع منابع رایگان، محدودیت منابع و فیلتر را می پذیرد. نحو به نظر ساده است. و استفاده از این تابع و محاسبه درصد حافظه خالی که داریم بسیار آسان است. یعنی چقدر حافظه داریم، چه محدودیتی داریم و چگونه فیلتر کنیم. اگر بخواهید همه آن را با استفاده مجدد از فیلترهای یکسان بنویسید بسیار بهتر به نظر می رسد، زیرا به یک جستار بزرگ و بزرگ تبدیل می شود.
و در اینجا نمونه ای از چنین درخواست بزرگ و بزرگی وجود دارد. این از داشبورد رسمی NodeExporter برای Grafana است. اما من واقعا نمی فهمم اینجا چه خبر است. البته اگر دقت کنید متوجه می‌شوم، اما تعداد براکت‌ها می‌تواند بلافاصله انگیزه درک آنچه در اینجا اتفاق می‌افتد را کاهش دهد. و چرا آن را ساده تر و واضح تر نمی کنیم؟
به عنوان مثال، مانند این، برجسته کردن چیزها یا بخش های مهم در متغیرها. و سپس ریاضیات اولیه خود را انجام دهید. این بیشتر شبیه برنامه نویسی است، این چیزی است که من دوست دارم در آینده در Grafana ببینم.
در اینجا مثال دومی وجود دارد که چگونه می‌توانیم آن را حتی ساده‌تر کنیم، اگر قبلاً این تابع ru را داشتیم، و از قبل مستقیماً در VictoriaMetrics وجود دارد. و سپس فقط مقدار کش شده ای را که در CTE اعلام کرده اید، ارسال می کنید.
قبلاً در مورد اهمیت استفاده از زبان برنامه نویسی مناسب صحبت کرده ام. و احتمالاً در هر شرکتی چیز متفاوتی در گرافانا در حال وقوع است. و احتمالاً شما همچنان به توسعه دهندگان خود دسترسی به Grafana را می دهید و توسعه دهندگان کاری برای خودشان انجام می دهند. و همه آنها این کار را به روش دیگری انجام می دهند. اما من آن را به نوعی می خواستم، یعنی به یک استاندارد مشترک کاهش یابد.
فرض کنید شما حتی فقط مهندسان سیستم ندارید، شاید حتی متخصصان، توسعه دهندگان یا SREها داشته باشید. شاید شما کارشناسانی داشته باشید که می دانند نظارت چیست، می دانند گرافانا چیست، یعنی سال ها با این کار کار می کنند و دقیقاً می دانند چگونه آن را به درستی انجام دهند. و آنها قبلاً آن را 100 بار نوشته اند و برای همه توضیح داده اند ، اما به دلایلی کسی گوش نمی دهد.
اگر آنها بتوانند این دانش را مستقیماً در Grafana قرار دهند تا سایر کاربران بتوانند دوباره از توابع استفاده کنند، چه می‌شود؟ و اگر لازم باشد درصد حافظه آزاد محاسبه شود، آنها به سادگی تابع را اعمال می کنند. اما اگر سازندگان صادرکنندگان همراه با محصول خود، مجموعه ای از توابع را نیز ارائه دهند، چگونه با معیارهای خود کار کنند، زیرا آنها دقیقاً می دانند که این معیارها چیست و چگونه آنها را به درستی محاسبه کنند؟
این یکی واقعا وجود ندارد. این چیزی است که من خودم انجام دادم. این پشتیبانی از کتابخانه در Grafana است. بیایید بگوییم افرادی که NodeExporter را ساخته اند، آنچه را که من توضیح دادم انجام دادند. و همچنین مجموعه ای از ویژگی ها را ارائه کرد.
یعنی چیزی شبیه این است. شما این کتابخانه را به Grafana متصل می‌کنید، وارد ویرایش می‌شوید و در اینجا نحوه کار با این متریک در JSON بسیار ساده است. یعنی مجموعه ای از توابع، توصیف آنها و آنچه در آنها آشکار می شود.
به نظر من، این می تواند مفید باشد، زیرا در آن صورت شما در Grafana همینطور می نویسید. و Grafana به شما می گوید که فلان تابع از فلان کتابخانه وجود دارد - بیایید از آن استفاده کنیم. من فکر می کنم که بسیار جالب خواهد بود.
کمی در مورد VictoriaMetrics ما کارهای جالب زیادی انجام می دهیم. مقالات ما در مورد فشرده سازی، در مورد رقابت ما با سایر برنامه های داده سری زمانی، توضیح ما در مورد نحوه کار با PromQL را بخوانید، زیرا مبتدیان بسیار بیشتری در این زمینه وجود دارد، همچنین در مورد مقیاس پذیری عمودی و در مورد رویارویی با Thanos.
پرسش:
من سوالم را با یک داستان ساده زندگی شروع می کنم. وقتی برای اولین بار استفاده از Grafana را شروع کردم، یک پرس و جو 5 خطی بسیار متقاعدکننده نوشتم. نتیجه نهایی یک نمودار بسیار قانع کننده است. این نمودار تقریباً به مرحله تولید رسیده است. اما با بررسی دقیق تر، مشخص شد که این نمودار مزخرف مطلق را نشان می دهد که هیچ ربطی به واقعیت ندارد، اگرچه اعداد در محدوده ای قرار می گیرند که انتظار داشتیم ببینیم. و سوال من ما کتابخانه داریم، توابع داریم، اما چگونه برای Grafana تست بنویسیم؟ شما یک پرس و جو پیچیده نوشته اید که بر تصمیم تجاری تأثیر می گذارد - سفارش یک کانتینر واقعی از سرورها یا عدم سفارش. و همانطور که می دانیم این تابعی که نمودار رسم می کند مشابه حقیقت است. متشکرم.
ممنون بابت سوال در اینجا دو بخش وجود دارد. اول، من بر اساس تجربه خود این تصور را دارم که اکثر کاربران، وقتی به نمودارهای خود نگاه می کنند، متوجه نمی شوند که چه چیزی را به آنها نشان می دهند. به نوعی، مردم در ارائه بهانه ای برای هر ناهنجاری که در نمودارها اتفاق می افتد، بسیار خوب هستند، حتی اگر این یک اشکال در یک تابع باشد. و بخش دوم - به نظر من استفاده از چنین توابعی برای حل مشکل شما بسیار مناسب تر است، به جای اینکه هر یک از توسعه دهندگان شما برنامه ریزی ظرفیت خود را انجام دهند و با احتمال کمی اشتباه کنند.
چگونه برای چک کردن
چگونه بررسی کنیم؟ احتمالا نه.
به عنوان یک آزمایش در Grafana.
و در مورد گرافانا چطور؟ Grafana این درخواست را مستقیماً به DataSource ترجمه می کند.
با اضافه کردن کمی به پارامترها.
نه، چیزی به Grafana اضافه نشده است. ممکن است پارامترهای GET مانند step وجود داشته باشد. به صراحت مشخص نشده است، اما می توانید آن را لغو کنید، نمی توانید آن را لغو کنید، اما به طور خودکار اضافه می شود. اینجا تست نمینویسی من فکر نمی کنم در اینجا به عنوان منبع حقیقت به Grafana تکیه کنید.
با تشکر از گزارش! با تشکر از فشرده سازی! شما در مورد نگاشت یک متغیر در یک نمودار به یاد آوردید که در Grafana نمی توانید از یک متغیر در یک متغیر استفاده کنید. آیامنظور من را می فهمی؟
بله.
وقتی می خواستم در Grafana هشدار بدهم، در ابتدا سردرد بود. و در آنجا باید هشدار را برای هر میزبان جداگانه انجام دهید. این کاری است که انجام دادید، آیا برای هشدارها در Grafana کار می کند؟
اگر Grafana به روش دیگری به متغیرها دسترسی نداشته باشد، بله، کار خواهد کرد. اما توصیه من این است که اصلاً از alerting در گرافانا استفاده نکنید، بهتر است از alertmanager استفاده کنید.
بله، من از آن استفاده می‌کنم، اما به نظر می‌رسید که راه‌اندازی آن در Grafana راحت‌تر باشد، اما از راهنمایی شما متشکرم!
منبع: www.habr.com