Prometheus: أداة تنسيق القاعدة.

: +1: *: 100:

نعم ، سيكون ذلك رائعًا. الحفاظ على التعليقات هو أكبر مشكلة (وبشكل أساسي فقط). والاتفاق على كيفية تقسيم التعبيرات على عدة أسطر.

ألسنا في منتصف إضافة هذا إلى برومتول؟

ذات صلة: https://github.com/prometheus/prometheus/pull/1779

بعض الملاحظات:

• باستخدام تنسيق القاعدة 2.x (YAML تضمين PromQL) ، نريد أن يعمل هذا على ملفات YAML أيضًا.
• يجب أن تحتفظ بكل من التعليقات في YAML و PromQL.
• المسافة البادئة أمر بالغ الأهمية (ليس فقط فواصل الأسطر).
• يجب أن نرى ما إذا كان يجب الاحتفاظ بفواصل أسطر معينة في الإدخال في المخرجات (راجع كيف يقوم gofmt بذلك).
• أينما يتم تقديم قاعدة ، يجب تطبيق نفس التنسيق ، لا سيما على علامتي التبويب _Alerts_ و _Rules_ لواجهة مستخدم ويب Prometheus. هذا يعني أن AST بحاجة إلى الاحتفاظ بالتعليقات (وربما فواصل أسطر معينة ، انظر النقطة السابقة).

يجب أن تحافظ على كلا التعليقين في YAML

مكتبة YAML الحالية لدينا لا تفعل ذلك ، ولكنها تأمل "قريبًا".

أود تضمين هذا في اقتراح gsoc الخاص بي. @ brian-brazil ، هل يمكنك الارتباط بمكتبة YAML التي تشير إليها؟

https://github.com/go-yaml/yaml ، لكنني سأضع نطاقًا على PromQL فقط كما هو الحال.

@ brian-brazil ولكن نظرًا لأن PromQL من القواعد مضمّن دائمًا في ملفات YAML ، يجب على الأقل الاحتفاظ بتعليقات YAML ، أليس كذلك؟ وإلا فلن تكون الأداة مفيدة للغاية حيث لا أحد يريد أن يفقد تعليقاته من ميزة التنسيق.

سيكون هذا رائعًا ، لكن يمكننا الحصول على فوائد بدون ذلك. أفضل أيضًا عدم الاعتماد على شيء ذي جدول زمني غير واضح لمشروع gsoc.

لنبدأ بجزء PromQL. يجب أن يكون جزء YAML تافهًا تقريبًا بمجرد أن تحتفظ المكتبة بالتعليقات وأشياء مثل تلميح المسافة البادئة |2 للسلاسل متعددة الأسطر.

نعم!

الإصدار 3 من مكتبة YAML خارج ، مما يسمح بكل هذا.

لمعلوماتك قاعدة قابلة للقراءة تمامًا في التكوين

(
    kube_job_status_failed > 0
    UNLESS kube_job_status_succeeded > 0
)
* on (namespace, job_name) group_left(maintainer) label_replace(kube_job_labels, "maintainer", "$1", "label_maintainer", "(.*)")
* on (namespace, job_name) group_left(pager) label_replace(kube_job_labels, "pager", "$1", "label_pager", "(.*)")
* on (namespace, job_name) group_left(paging) label_replace(kube_job_labels, "paging", "$1", "label_paging", "(.*)")

مقابل تمثيلها المهمل في واجهة مستخدم الويب

(kube_deployment_status_replicas_available
  / kube_deployment_spec_replicas * 100) * on(namespace, deployment) group_left(maintainer)
  label_replace(kube_deployment_labels, "maintainer", "$1", "label_maintainer",
  "(.*)") * on(namespace, deployment) group_left(pager) label_replace(kube_deployment_labels,
  "pager", "$1", "label_pager", "(.*)") * on(namespace,
  deployment) group_left(paging) label_replace(kube_deployment_labels, "paging",
  "$1", "label_paging", "(.*)") < 100

sylr أعتقد أنك نشرت بعض القواعد الأخرى من واجهة مستخدم الويب. أيضا @ beorn7 بدأت العمل على هذه المسألة.

هذا ما يظهر لي من حكمك:

(kube_job_status_failed
  > 0 unless kube_job_status_succeeded > 0) * on(namespace, job_name) group_left(maintainer)
  label_replace(kube_job_labels, "maintainer", "$1", "label_maintainer",
  "(.*)") * on(namespace, job_name) group_left(pager) label_replace(kube_job_labels,
  "pager", "$1", "label_pager", "(.*)") * on(namespace,
  job_name) group_left(paging) label_replace(kube_job_labels, "paging", "$1",
  "label_paging", "(.*)")

geekodour نعم ، لقد خلطت بين قاعدتين.

نظرًا لأن هذا لا يزال مفتوحًا وإضافته في أفكار المشروع لـ GSOC القادمة (https://github.com/cncf/soc#rule-formatting-tool) أود العمل على إكمال هذا خلال GSOC. أن أي تحديث في الآونة الأخيرة ومزيد من المعلومات حول هذا موضع تقديرcodesome @ بريان-البرازيلjuliusvgeekodoursimonpasquiersylr.
من قراءة التعليق والرابط المرجعي الآخر ، يبدو أن نقطة العمل التالية هي بناء مُنسق لتعبير promQL باستخدام promQL AST؟

haibeey كان هناك بالفعل بعض التقدم في هذا الاتجاه.

عند إنشاء مثل هذا المُنسق ، قد يكون من الأفضل البدء بما تم تنفيذه بالفعل هنا وإضافة مساحة بيضاء مناسبة ومعالجة التعليقات.

سيكون من الجيد أيضًا ، عندما يمكن دمج هذه الميزات مع خادم لغة PromQL القادم. داخل رمز خادم اللغة ، تم بالفعل تنفيذ الكثير من العناصر اللازمة لتنسيق ملفات YAML ، وقد يكون من المنطقي إعادة استخدام بعضها.

حسنا! شكرا slrtbtfs . سأبدأ في الاطلاع على الروابط المشتركة في أسرع وقت ممكن.

هل يمكنني تناول هذه المشكلة؟ احب ان تنفذ هذا

يبدو أن haibeey يخطط بالفعل بطريقة ما للعمل على هذا الأمر.

roidelapluie لقد قمت بالفعل بتنفيذ جزء منه من قبل. كل ما في الأمر أنني لم أذكره هنا.

لمعلوماتك قاعدة قابلة للقراءة تمامًا في التكوين

(
    kube_job_status_failed > 0
    UNLESS kube_job_status_succeeded > 0
)
* on (namespace, job_name) group_left(maintainer) label_replace(kube_job_labels, "maintainer", "$1", "label_maintainer", "(.*)")
* on (namespace, job_name) group_left(pager) label_replace(kube_job_labels, "pager", "$1", "label_pager", "(.*)")
* on (namespace, job_name) group_left(paging) label_replace(kube_job_labels, "paging", "$1", "label_paging", "(.*)")

مقابل تمثيلها المهمل في واجهة مستخدم الويب

(kube_deployment_status_replicas_available
  / kube_deployment_spec_replicas * 100) * on(namespace, deployment) group_left(maintainer)
  label_replace(kube_deployment_labels, "maintainer", "$1", "label_maintainer",
  "(.*)") * on(namespace, deployment) group_left(pager) label_replace(kube_deployment_labels,
  "pager", "$1", "label_pager", "(.*)") * on(namespace,
  deployment) group_left(paging) label_replace(kube_deployment_labels, "paging",
  "$1", "label_paging", "(.*)") < 100

هل أسلوب التنسيق هذا مقبول؟ codesomejuliusv @ بريان-البرازيل @ beorn7
أنا أكتب اقتراحي بناءً على هذا الأسلوب.

يمكن مناقشة التمثيل النهائي بعد التنسيق والبت فيه خلال فترة GSoC (ربما حتى الآن إذا أراد أي مشرف أن يتناغم ، لكن ليس لدي النطاق الترددي لمراجعته في الوقت الحالي). أود أن أقترح (لجميع الطامحين في GSoC) التركيز على _كيف_ هل ستحقق ذلك.

يستخدم https://prometheus.io/docs/practices/rules/ أفضل الممارسات.

لقد كتبت نموذجًا أوليًا تقريبيًا للحفاظ على التعليقات عن طريق زيادة قواعد قواعد goyacc قليلاً. الالتزام هنا https://github.com/haibeey/prometheus/commit/885566786ac20bfd400b2e7db470c92545919690

ملف القواعد
تسجيل القاعدة في واجهة الويب

هذا لا يبدو صحيحًا ، المشغلون ليسوا على خطهم الخاص

نعم بالتأكيد. أن الالتزام لا يصنع التزاوج. هو فقط للحفاظ على التعليقات في برومكل إكسبر بعد التقييم للطباعة.
الإصدارات السابقة تتجاهل جميع التعليقات بعد التقييم.

لقد كتبت نموذجًا أوليًا تقريبيًا للحفاظ على التعليقات عن طريق زيادة قواعد قواعد goyacc قليلاً. الالتزام هنا [haibeey @ 8855667]

يبدو وضع التعليقات في AST فكرة معقولة.

لقد تركت بعض التعليقات حول التنفيذ هناك.

يستخدم https://prometheus.io/docs/practices/rules/ أفضل الممارسات.

من فضلك لا تفرض:

sum without (instance)(instance_path:requests:rate5m{job="myjob"})

على

sum(instance_path:requests:rate5m{job="myjob"}) without (instance)

يعد تجميع المُعدِّلات أولاً هو أفضل ممارسة ، وهو بالفعل كيف نطبعها - من الصعب جدًا قراءة التعبيرات غير التافهة بخلاف ذلك.

نعم ، كان لدي آراء قوية حول هذا في البداية. في البداية ، دعم بروميثيوس sum(x) by(y) لأنها تقرأ أكثر مثل اللغة الإنجليزية بالنسبة لي ، وبالتالي كنت أفضلها كثيرًا ، ولكن بالنسبة لأي x غير تافه ، يصبح من الصعب حقًا معرفة الأبعاد التي تقوم بتجميعها / حفظ. كنت أتمنى لو أنني جعلت من البداية sum by(y) (x) وجعلت ذلك البديل القانوني الوحيد.

ما زلت لا أحب التنسيق الدقيق sum by (y)(x) ويفضل كثيرًا sum by(y) (x) (أكثر منطقية بالنسبة لي) ، لست متأكدًا من سبب اختيارنا للتنسيق الأخير في المستندات.

أعتقد أن لكل شخص الحق في إبداء رأيه الخاص حول هذا الأمر ، فأنا شخصيًا أجد أن "أفضل الممارسات" هي أن تكون بشعة ، ولكن نظرًا لأن جميع الجمل قانونية ، فيرجى عدم فرض إحداها على الآخرين.

الهدف الكامل من أداة promfmt هو ، إن لم يكن فرض ، على الأقل "تأييد" تنسيق "أساسي" معين ، يشبه إلى حد كبير gofmt ، مع سلسلة كاملة من الحجج التي تدعمه.

نعم ، تنسيق gofmt ليس هو المفضل لدى أي شخص ، لكنه على الأقل يخلق نمطًا واحدًا متسقًا بدلاً من العديد من الأنماط المختلفة ، وهي قيمة في حد ذاتها.

كملاحظة جانبية ، تم السعي بنشاط بعد إلى GSoC. haibeey أرى أنك مهتم أيضًا بـ GSoC. بينما أقدر العمل الأولي الذي قدمته الآن ، سأكون ممتنًا لبعض المناقشات المفتوحة ومشاركة التصميم ، في مقترح GSoC أو غير ذلك ، لتسهيل تنسيق المشاريع في GSoC :)

الاحتفاظ بالتعليقات مدعوم بالفعل بشكل جيد للغاية في مكتبة go-yamlv3 الجديدة. التنفيذ لا تشوبه شائبة لدرجة أنه لا يوجد فقدان للتعليقات. ومن ثم ، يمكننا الاحتفاظ بآلية مستقلة عن كود بروميثيوس دون أي قلق.

حسنا. أعتقد أن الوقت قد حان لمشاركة اقتراحي مسودة اقتراح GSoC .

سيكون موضع تقدير المراجعات قبل المسودة النهائية. شكرا

@ Harkishen-Singh هناك مستويان من التعليقات: تعليقات YAML وتعليقات داخل تعبير PromQL. https://github.com/prometheus/prometheus/issues/21#issuecomment -604213849 كان يتحدث عن PromQL تلك (لكن YAML سيكون من الجيد الاحتفاظ بها أيضًا).

الاحتفاظ بالتعليقات مدعوم بالفعل بشكل جيد للغاية في مكتبة go-yamlv3 الجديدة. التنفيذ لا تشوبه شائبة لدرجة أنه لا يوجد فقدان للتعليقات. ومن ثم ، يمكننا الاحتفاظ بآلية مستقلة عن كود بروميثيوس دون أي قلق.

أثناء تقييم تعبير PromQL يكون عند إزالة التعليقات.
ومع ذلك ، أعتقد أن التنسيق لا يتم فقط في ملفات القواعد ولكن في بعض الأماكن أيضًا مثل واجهة مستخدم الويب. هل هذا صحيح juliusv ؟
لذلك كما أوضح slrtbtfs ، سيتم إجراء معظم عمليات التنسيق

فيما يتعلق بتعليقات YAML ، هناك مشاكل في الإصدار 3 تتسبب في حدوث مشكلات لـ Cortex ، لذا يجب علينا تجنب المزيد من طرح ذلك حتى يتم حل كل ذلك.

ومع ذلك ، أعتقد أن التنسيق لا يتم فقط في ملفات القواعد ولكن في بعض الأماكن أيضًا مثل واجهة مستخدم الويب. هل هذا صحيح

واجهة مستخدم الويب هي المكان الوحيد الذي يتم ذلك فيه.