أقترح قراءة نص تقرير رومان خافرونينكو "ExtendedPromQL"
باختصار عني. اسمي رومان. أعمل لدى CloudFlare وأعيش في لندن. لكنني أيضًا مشرف VictoriaMetrics.
وأنا المؤلف من أجل Grafana و هو وكيل صغير لـ ClickHouse.
سنبدأ بالجزء الأول ، والذي يسمى "صعوبات الترجمة" ، وسأتحدث فيه عن حقيقة أن أي لغة أو حتى مجرد لغة اتصال مهمة للغاية. لأن هذه هي الطريقة التي تنقل بها أفكارك إلى شخص أو نظام آخر ، كيف تصوغ طلبًا. الناس على الإنترنت يتجادلون حول أي لغة أفضل - جافا أم لغة أخرى. بالنسبة لي ، قررت أنه من الضروري اختيار مهمة ، لأن كل هذا محدد.
لنبدأ من البداية. ما هو PromQL؟ PromQL هي لغة Prometheus Query. هذه هي الطريقة التي نشكل بها الاستعلامات في بروميثيوس للحصول على بيانات السلاسل الزمنية ، السلاسل الزمنية.
ما هي بيانات السلاسل الزمنية؟ حرفيا ، هذه ثلاث معلمات.
وهذه هي:
- ما الذي ننظر إليه.
- عندما ننظر إليها.
- وما هي القيمة التي تظهرها.
إذا نظرت إلى هذا المخطط (هذا المخطط من هاتفي ، والذي يعرض إحصائيات خطواتي) ، فيمكنك هنا الإجابة بسرعة على هذه الأسئلة.
نحن نبحث في الخطوات. نرى المعنى ونرى الوقت عندما ننظر إليه. أي بالنظر إلى هذا الرسم البياني ، يمكنك بسهولة القول إنني مشيت يوم الأحد حوالي 15 خطوة. هذه بيانات السلاسل الزمنية.
الآن دعنا "نقسم" (نحول )هم إلى نموذج بيانات آخر في شكل جدول. هنا لدينا أيضًا ما ننظر إليه. لقد أضفت هنا القليل من البيانات الإضافية ، والتي سنسميها البيانات الوصفية ، أي ، لم أكن أنا من مررت ، ولكن شخصين ، على سبيل المثال ، جاي وسايلنت بوب. هذا ما نبحث عنه. ما يظهر ومتى يظهر تلك القيمة.
الآن دعنا نحاول تخزين كل هذه البيانات في قاعدة البيانات. على سبيل المثال ، أخذت بناء جملة ClickHouse. وها نحن نقوم بإنشاء جدول واحد يسمى "الخطوات" ، أي ما نبحث عنه. هناك وقت هنا عندما ننظر إليه ؛ ما يظهر وبعض البيانات الوصفية حيث سنخزن من هو: جاي وسايلنت بوب.
ومن أجل محاولة تصور كل شيء ، سوف نستخدم غرافانا ، لأنه ، أولاً ، إنه جميل.
أيضا سوف نستخدم هذا البرنامج المساعد. هناك سببان لهذا. الأول لأنني كتبته. وأنا أعلم تمامًا مدى صعوبة سحب بيانات السلاسل الزمنية من ClickHouse لعرضها في Grafana.
سنعرض في لوحة الرسم البياني. هذه هي اللوحة الأكثر شيوعًا في Grafana وتُظهر القيمة مقابل الوقت ، لذلك نحتاج فقط إلى معلمتين.
لنكتب أبسط استعلام - كيفية إظهار إحصائيات الخطوة في Grafana ، وتخزين هذه البيانات في ClickHouse ، في الجدول الذي أنشأناه. ونكتب مثل هذا الاستعلام البسيط. نختار من بين الخطوات. نختار قيمة ونختار وقت هذه القيم ، أي نفس المعلمات الثلاثة التي تحدثنا عنها.
ونتيجة لذلك ، حصلنا على هذا التمثيل البياني. من يعرف لماذا هو غريب جدا؟
هذا صحيح ، تحتاج إلى الفرز حسب الوقت.
وفي النهاية نحصل على جدول أفضل ، لكنه لا يزال غريبًا. من يعرف لماذا؟ هذا صحيح ، هناك اثنان من المشاركين ، ونمنح سلسلتين زمنيتين في جرافانا ، لأننا إذا تعاملنا مع نموذج البيانات مرة أخرى ، فإن كل سلسلة زمنية هي مزيج فريد من الاسم وجميع العلامات والقيم الرئيسية.
لذلك ، نحن بحاجة إلى اختيار شخص معين. نختار جاي.
وارسم مرة أخرى. الآن يبدو الرسم البياني مثل الحقيقة. الآن أصبح الجدول الزمني عاديًا وكل شيء يعمل بشكل جيد.
وربما تعرف كيف تفعل الشيء نفسه ، لكن في بروميثيوس عبر PromQL. تقريبا مثل هذا. أسهل قليلا. ودعنا نقسمها كلها. اتخذنا خطوات. وتصفية بواسطة جاي. لا نحدد هنا أننا بحاجة للحصول على قيمة ولا نختار وقتًا.
لنحاول الآن حساب سرعة حركة جاي أو سايلنت بوب. في ClickHouse ، سنحتاج إلى تشغيل runDifference ، أي حساب الفرق بين أزواج من النقاط وقسمتهم على الوقت للحصول على السرعة بالضبط. سيبدو الطلب مثل هذا.
وسيُظهر هذه القيم تقريبًا ، أي ما يقرب من 1,8 خطوة في الثانية يفعل Silent Bob أو Jay.
وفي بروميثيوس أنت تعرف كيف تفعل ذلك أيضًا. أسهل بكثير من ذي قبل.
ولجعل الأمر سهلاً أيضًا في Grafana ، أضفت غلافًا مشابهًا جدًا لـ PromQL. يطلق عليه معدل وحدات الماكرو ، أو ما تريد تسميته. في Grafana ، تكتب فقط "معدل" ، ولكن في مكان ما في الأعماق يتحول إلى مثل هذا الطلب الكبير. ولا يتعين عليك حتى النظر إليها ، فهي موجودة في مكان ما ، لكنك توفر الكثير من الوقت ، لأن كتابة مثل هذه الاستعلامات الضخمة في SQL أمر مكلف دائمًا. يمكنك بسهولة ارتكاب خطأ ثم عدم فهم ما يحدث لفترة طويلة.
وهذا استعلام لم يتناسب حتى مع شريحة واحدة ، واضطررت حتى إلى تقسيمه إلى عمودين. هذا أيضًا طلب في ClickHouse ، والذي يقدم نفس المعدل ، ولكن لكل من السلسلتين الزمنيتين: Silent Bob و Jay ، بحيث يكون لدينا سلسلتان زمنيتان على اللوحة. وهذا بالفعل صعب للغاية ، في رأيي.
ووفقًا لبروميثيوس سيكون المبلغ (السعر). بالنسبة لـ ClickHouse ، قمت بعمل ماكرو منفصل يسمى RateColumns والذي يشبه استعلام Prometheus.
لقد نظرنا ويبدو أن PromQL كل شيء رائعًا ، لكن له قيودًا بالطبع.
وهذه هي:
- تحديد محدود.
- حافة JOINs.
- لا يوجد دعم.
وإذا كنت قد عملت معها لفترة طويلة ، فأنت تعلم أنه في بعض الأحيان يكون من الصعب جدًا القيام بشيء ما في PromQL ، وفي SQL يمكنك فعل كل شيء تقريبًا ، لأن كل هذه الخيارات التي تحدثنا عنها للتو يمكن إجراؤها في SQL . لكن هل سيكون من المناسب استخدامه؟ وهذا يجعلني أعتقد أنه ليس دائمًا أقوى لغة يمكن أن تكون الأكثر ملاءمة.
لذلك ، تحتاج أحيانًا إلى اختيار لغة للمهام. إنها مثل معركة بين باتمان وسوبرمان. من الواضح أن سوبرمان أقوى ، لكن باتمان كان قادرًا على هزيمته لأنه أكثر عملية ويعرف بالضبط ما كان يفعله.
والجزء التالي هو توسيع PromQL.
مرة أخرى حول VictoriaMetrics. ما هي VictoriaMetrics؟ هذه قاعدة بيانات متسلسلة زمنية ، وهي في OpenSource ، نوزع إصداراتها الفردية والمجموعة. وفقًا لمعاييرنا ، فهو الأسرع الموجود في السوق الآن وهو مشابه من حيث الضغط ، أي أن الأشخاص الأحياء يبلغون عن ضغط يبلغ حوالي 0,4 بايت لكل نقطة ، عندما يكون لدى بروميثيوس 1,2-1,4.
نحن ندعم ليس فقط بروميثيوس. نحن نؤيد InfluxDB ، الجرافيت ، OpenTSDB.
يمكنك "الكتابة" فينا ، أي يمكنك نقل البيانات القديمة.
ونعمل أيضًا بشكل مثالي مع Prometheus و Grafana ، أي أننا ندعم محرك PromQL. وفي Grafana ، يمكنك ببساطة تغيير نقطة نهاية Prometheus إلى VictoriaMetrics وستعمل جميع لوحات المعلومات كما فعلت.
ولكن يمكنك أيضًا استخدام شرائح إضافية مقدمة من VictoriaMetrics.
سننتقل بسرعة إلى الميزات التي أضفناها.
حذف معلمة الفاصل الزمني - يمكنك تخطي فاصل المعلمة في Grafana. عندما لا ترغب في الحصول على رسوم بيانية غريبة عند التكبير / التصغير في اللوحة ، يوصى باستخدام المتغير $__interval. هذا تغيير Grafana داخلي ويختار نطاق البيانات نفسه. وتستطيع VictoriaMetrics نفسها فهم ما يجب أن يكون عليه هذا النطاق. ولا يتعين عليك تحديث جميع استفساراتك. سيكون أسهل بكثير.
الوظيفة الثانية هي الإشارة إلى الفاصل الزمني. يمكنك استخدام هذا التباعد في التعبيرات الخاصة بك. يمكنك الضرب والقسمة والتحويل والرجوع إليها.
التالي هو عائلة وظيفة التجميع. تعمل وظيفة التجميع على تحويل أي سلسلة زمنية إلى ثلاث سلاسل زمنية منفصلة. هذه هي min و max و avg. أجده مناسبًا جدًا ، لأنه في بعض الأحيان يمكن أن يظهر بعض القيم المتطرفة (الشذوذ) وعدم الدقة.
وإذا كنت مجرد غاضب أو معدل ، فمن المحتمل أن تفوتك بعض الحالات التي لا تتصرف فيها السلسلة الزمنية بالطريقة التي تريدها. من السهل جدًا رؤية هذه الوظيفة ، دعنا نقول أن الحد الأقصى بعيد جدًا عن المتوسط.
التالي هو المتغير الافتراضي. افتراضي - هذا يعني القيمة التي نحتاج إلى رسمها في Grafana إذا لم يكن لدينا سلسلة زمنية في الوقت الحالي. عندما يحدث ذلك؟ لنفترض أنك قمت بتصدير بعض مقاييس الخطأ. ولديك مثل هذا التطبيق الرائع أنه عندما تبدأ ، لن يكون لديك أي أخطاء ولا أخطاء حتى لثلاث ساعات أو حتى يوم واحد. ولديك لوحات معلومات تُظهر العلاقات من النجاح إلى الخطأ. ولن يظهروا لك شيئًا لأنه ليس لديك مقياس خطأ. وبشكل افتراضي يمكنك تحديد أي شيء.
Keep_last_Value - يحفظ القيمة الأخيرة للمقياس إذا كانت مفقودة. إذا لم يعثر بروميثيوس بعد الكشط التالي في غضون 5 دقائق ، فسوف نتذكر هنا قيمته الأخيرة ولن تنكسر مخططاتك مرة أخرى.
Scrape_interval - يوضح عدد المرات التي يقوم فيها بروميثيوس بجمع البيانات حول المقياس الخاص بك ، وبأي تردد. هنا يمكنك رؤية الممر ، على سبيل المثال.
استبدال التسمية ميزة شائعة. لكننا نعتقد أنه معقد بعض الشيء لأنه يأخذ حججًا صحيحة. ولا تحتاج فقط إلى تذكر الحجج الخمس ، ولكن أيضًا تذكر تسلسلها.
لذلك ، لماذا لا نجعلها أبسط؟ أي ، قم بتقسيمها إلى وظائف صغيرة مع بناء جملة واضح.
والآن الأكثر إثارة للاهتمام. لماذا نعتقد أنه تم تمديد PromQL؟ لأننا ندعم تعبيرات الجدول المشتركة. يمكنك اتباع رمز الاستجابة السريعة () ، انظر الروابط مع الأمثلة ، من الملعب ، حيث يمكنك تشغيل الاستعلامات مباشرة في VictoriaMetrics دون تثبيتها في المتصفح فقط.
وما هو؟ هذا الطلب من أعلى هو طلب شائع إلى حد ما. أعتقد أنه في أي لوحة تحكم في العديد من الشركات تستخدم نفس الفلتر لكل شيء. عادة هكذا. ولكن عندما تحتاج إلى إضافة عامل تصفية جديد ، يجب عليك تحديث كل لوحة ، أو تنزيل لوحة القيادة ، وفتحها في JSON ، واستبدالها ، الأمر الذي يستغرق أيضًا وقتًا. لماذا لا تخزن هذه القيمة في متغير وتعيد استخدامها؟ يبدو ، في رأيي ، أبسط وأوضح بكثير.
على سبيل المثال ، عندما أحتاج إلى تحديث عوامل التصفية في Grafana في جميع الطلبات ، ويمكن أن تكون لوحة القيادة ضخمة أو يمكن أن يكون هناك العديد منها. وكيف أرغب في حل هذه المشكلة في جرافانا؟
لقد قمت بحل هذه المشكلة كالتالي: أقوم بعمل مرشح عام وأقوم بتعريف هذا المرشح فيه ، ثم أعيد استخدامه في الاستعلامات. ولكن إذا فعلت الشيء نفسه الآن ، فلن ينجح ذلك لأن Grafana لا يسمح لك باستخدام المتغيرات داخل متغيرات الاستعلام. وهو غريب بعض الشيء.
ولذلك قمت بعمل خيار يتيح لك القيام بذلك. وإذا كنت مهتمًا أو تريد هذه الميزة ، فقم بدعمها أو عدم الإعجاب بها إذا لم تعجبك هذه الفكرة.
تمديد المزيد حول PromQL. هنا نحدد ليس فقط المتغير ، ولكن مباشرة وظيفة كاملة. ونسميها ru (استخدام الموارد). وتقبل هذه الوظيفة الموارد المجانية وحدود الموارد وفلتر. يبدو أن بناء الجملة بسيط. ومن السهل جدًا استخدام هذه الوظيفة وحساب النسبة المئوية للذاكرة الخالية لدينا. هذا هو مقدار الذاكرة التي لدينا ، وما هو الحد وكيفية التصفية. يبدو الأمر أفضل كثيرًا إذا كنت ستكتبها كلها بإعادة استخدام نفس عوامل التصفية ، لأنها ستتحول إلى استعلام كبير وكبير.
وهنا مثال على مثل هذا الطلب الكبير والكبير. إنه من لوحة القيادة الرسمية لـ NodeExporter لـ Grafana. لكنني لا أفهم حقًا ما يحدث هنا. هذا ، بالطبع ، أتفهم إذا نظرت عن كثب ، لكن عدد الأقواس يمكن أن يقلل على الفور من الدافع لفهم ما يحدث هنا. ولماذا لا نجعلها أبسط وأوضح؟
على سبيل المثال ، مثل هذا ، إبراز الأشياء المهمة أو الأجزاء في المتغيرات. ثم قم بحساباتك الأساسية. هذا أشبه بالبرمجة ، هذا ما أود رؤيته في المستقبل في جرافانا.
فيما يلي مثال ثان عن كيفية جعل الأمر أسهل إذا كان لدينا بالفعل وظيفة ru هذه ، وهي موجودة بالفعل مباشرة في VictoriaMetrics. وبعد ذلك تقوم فقط بتمرير القيمة المخزنة مؤقتًا التي أعلنتها في CTE.
لقد تحدثت بالفعل عن مدى أهمية استخدام لغة البرمجة الصحيحة. وربما يحدث شيء مختلف في غرافانا في كل شركة. وربما لا تزال تمنح حق الوصول إلى Grafana لمطوريك ، ويقوم المطورون بشيء خاص بهم. وكلهم يفعلون ذلك بطريقة مختلفة. لكنني أردت ذلك بطريقة ما نفس الشيء ، أي تقليصه إلى معيار مشترك.
لنفترض أنه ليس لديك حتى مهندسو أنظمة فحسب ، بل ربما لديك خبراء أو مطورون أو SREs. ربما لديك خبراء يعرفون ماهية المراقبة ، ويعرفون ما هي Grafana ، أي أنهم يعملون مع هذا منذ سنوات ويعرفون بالضبط كيف يفعلون ذلك بشكل صحيح. وقد كتبوها بالفعل 100 مرة وشرحوها للجميع ، لكن لسبب ما لم يستمع إليها أحد.
ماذا لو تمكنوا من وضع هذه المعرفة مباشرة في Grafana حتى يتمكن المستخدمون الآخرون من إعادة استخدام الوظائف؟ وإذا كان من الضروري حساب النسبة المئوية للذاكرة الخالية ، فسيقومون ببساطة بتطبيق الوظيفة. ولكن ماذا لو قدم منشئو المصدرين ، جنبًا إلى جنب مع منتجهم ، مجموعة من الوظائف ، وكيفية التعامل مع مقاييسهم ، لأنهم يعرفون بالضبط ما هي هذه المقاييس وكيفية حسابها بشكل صحيح؟
هذا غير موجود حقًا. هذا ما فعلته بنفسي. هذا هو دعم المكتبة في جرافانا. لنفترض أن الأشخاص الذين صنعوا NodeExporter فعلوا ما وصفته. وقدمت أيضًا مجموعة من الميزات.
هذا هو ، يبدو شيء من هذا القبيل. تقوم بتوصيل هذه المكتبة بـ Grafana ، وتبدأ في التحرير ، وهنا من السهل جدًا في JSON كيفية التعامل مع هذا المقياس. هذا هو ، مجموعة من الوظائف ووصفها وما تتكشف فيه.
في رأيي ، قد يكون هذا مفيدًا ، لأنك ستكتب بعد ذلك بلغة Grafana تمامًا. ويخبرك غرافانا أن هناك وظيفة كذا وكذا من مكتبة كذا وكذا - فلنستخدمها. أعتقد أن هذا سيكون رائعًا جدًا.
قليلا عن VictoriaMetrics. نحن نقوم بالكثير من الاشياء الشيقة اقرأ مقالاتنا حول الضغط ، وحول منافستنا مع تطبيقات بيانات السلاسل الزمنية الأخرى ، وشرحنا لكيفية العمل مع PromQL ، نظرًا لوجود العديد من المبتدئين في هذا ، بالإضافة إلى قابلية التوسع الرأسي والمواجهة مع Thanos.
الأسئلة:
سأبدأ سؤالي بقصة حياة بسيطة. عندما بدأت استخدام Grafana لأول مرة ، كتبت استعلامًا مكونًا من 5 أسطر مقنعًا للغاية. النتيجة النهائية هي مخطط مقنع للغاية. دخل هذا الرسم البياني في الإنتاج تقريبًا. ولكن عند الفحص الدقيق ، اتضح أن هذا الرسم البياني يظهر هراء مطلق لا علاقة له بالواقع ، على الرغم من أن الأرقام تقع في النطاق الذي توقعنا رؤيته. وسؤالي. لدينا مكتبات ، لدينا وظائف ، لكن كيف نكتب اختبارات لـ Grafana؟ لقد كتبت استعلامًا معقدًا يؤثر على قرار العمل - لطلب حاوية حقيقية من الخوادم أو عدم الطلب. وكما نعلم ، هذه الدالة التي ترسم التمثيل البياني مشابهة للحقيقة. شكرًا لك.
شكرا على السؤال. هناك جزئين هنا. أولاً ، لدي انطباع ، بناءً على تجربتي ، أن معظم المستخدمين ، عندما ينظرون إلى مخططاتهم ، لا يفهمون ما يعرضونه عليهم. بطريقة ما ، الناس بارعون جدًا في التوصل إلى عذر لأي شذوذ يحدث على المخططات ، حتى لو كان خطأ داخل دالة. والجزء الثاني - يبدو لي أن استخدام مثل هذه الوظائف سيكون أكثر ملاءمة لحل مشكلتك ، بدلاً من قيام كل من مطوريك بتخطيط القدرات الخاصة بهم وارتكاب أخطاء مع بعض الاحتمالات.
كيف تحقق؟
كيف تفحص؟ على الاغلب لا.
كاختبار في جرافانا.
وماذا عن جرافانا؟ تقوم Grafana بترجمة هذا الطلب مباشرة إلى DataSource.
عن طريق إضافة القليل إلى المعلمات.
لا ، لم تتم إضافة أي شيء إلى Grafana. قد تكون هناك معلمات GET ، مثل الخطوة. لم يتم تحديده بشكل صريح ، ولكن يمكنك تجاوزه ، ولا يمكنك تجاوزه ، ولكن يتم إضافته تلقائيًا. أنت لا تكتب الاختبارات هنا. لا أعتقد أنه يجب عليك الاعتماد على جرافانا هنا كمصدر للحقيقة.
شكرا على التقرير! شكرا للضغط! لقد تذكرت عن تعيين متغير في رسم بياني ، أنه في Grafana لا يمكنك استخدام متغير في متغير. هل تفهم ما أقصد؟
نعم.
كان هذا في البداية صداعًا عندما أردت تنبيهًا في جرافانا. وهناك تحتاج إلى عمل تنبيه لكل مضيف على حدة. هذا هو الشيء الذي فعلته ، هل يعمل مع التنبيهات في Grafana؟
إذا لم تتمكن Grafana من الوصول إلى المتغيرات بطريقة أخرى ، فعندئذ نعم ، ستنجح. لكن نصيحتي هي عدم استخدام التنبيه في Grafana على الإطلاق ، فمن الأفضل استخدام alertmanager.
نعم ، أستخدمه ، ولكن بدا أنه من الأسهل إعداده في Grafana ، ولكن شكرًا على النصيحة!
المصدر: www.habr.com