خلال PromCon Online 2020 ، ألقيت محاضرة بعنوان "مستقبل بروميثيوس ونظامها البيئي". وأريد أن أشارككم نقاطه الرئيسية.
ملخص
منذ المؤتمر الأخير PromCon - 2019 ، كان هناك العديد من التغييرات في بروميثيوس.
2.14
يقدم الإصدار 2.14 واجهة جديدة في React. على الرغم من أنها لا تزال متأخرة من حيث الوظيفة ، إلا أننا نعمل عليها ونواصل تحسينها.
2.15
جاء الإصدار 2.15 تحت شعار Metadata API. و بروميثيوس تنسيق التعرض تدعم منذ أمد تعبيرات خاصة
HELP، TYPEوما إلى ذلك، لكن بروميثيوس نفسها المستخدمة ببساطة تجاهل هذه البيانات. الآن بعد أن ظلوا ، يمكنك فتح الوصول الخارجي إليهم من خلال API. على سبيل المثال ، تستفيد Grafana بالفعل من هذه الفرصة وتزود المستخدمين بمعلومات إضافية حول السلسلة الزمنية التي يعملون بها:
2.16
يركز الإصدار 2.16 على العديد من التحسينات والاستقرار. على سبيل المثال ، منذ عام 2016 ، كان المستخدمون يسألون عن القدرة على تحديد التوقيت المحلي في واجهة المستخدم ، بالإضافة إلى تنفيذ سجل الاستعلام - كان من الجيد إغلاق هذه المشكلات.
2.17
عند الحديث عن طلبات الميزات العالقة ، جلب الإصدار 2.17 أخيرًا الحرف "I" الذي طال انتظاره في ACID لقاعدة البيانات : العزل .
2.18
في 2.18 ، تم تحسين التتبع والدعم لمثيلات تنسيق التعريض. المثيلات هي أول تأثير ملحوظ للمستخدم لتطبيق OpenMetrics في بروميثيوس. من خلال دمجها مع Grafana ، يمكنك تحقيق الدقة المريحة ، مما يتيح لك الانتقال من:
... إلى:
2.19
في 2.19 ، قللنا من استهلاك الذاكرة بنسبة تصل إلى 50٪! على الرغم من أن بروميثيوس فعال بالفعل ، إلا أن هناك إمكانية كبيرة للتحسين يكون مثيرًا ومخيفًا.
هذا الرسم البياني هو توضيح رائع لهذا:
2.20
يحتوي الإصدار 2.20 على أطول سجل تغيير منذ الإصدار 2.6 (!). ربما يكون العامل الرئيسي هو دعم اكتشاف الخدمة الأصلي لـ Docker Swarm و DigitalOcean.
ولكن هناك تغيير أكثر أهمية يتجاوز تنفيذ آليتين مستقلتين لاكتشاف الخدمة: نحن نفصل بروميثيوس ونلقي نظرة جديدة على العديد من الحلول القديمة والأساليب الراسخة. لقد تغير العالم (ربما كان لدينا أيضًا يد في هذا) - يجب أن يؤخذ هذا في الاعتبار في كل من المشروع نفسه وفي الآخرين.
node_exporter
للتلخيص ، أود أن أشير إلى أن node_exporter قد وصل إلى الإصدار 1.0 ويتضمن الآن دعم TLS التجريبي . قامت مؤسسة Cloud Native Computing Foundation برعاية تدقيق node_exporter بواسطة Cure53 (غطت كل من المصدر بشكل عام وتنفيذ TLS بشكل خاص). وكان الأمر يستحق ذلك بشكل مضاعف: لم نتحقق فقط من TLS قبل نسخه إلى مصدرين آخرين ، ولكننا استخدمنا أيضًا node_exporter كخنزير غينيا يتم نسخ أنماط أخرى منه.
مستقبل
أشعر أحيانًا أننا ، كمشروع ، نستريح على أمجادنا. منذ فترة ، أجريت جلسة عصف ذهني داخل جرافانا تحت شعار "بروميثيوس يفتقد ميزات" وشجعت ريد هات على فعل الشيء نفسه. على طول الطريق ، أنشأنا مستندًا عن كل شيء ، وهو متاح لفريق Prometheus بأكمله. إنه بمثابة إطار عمل لتناول موضوعات محددة ، مقسمة إلى نقاط للمناقشة أثناء مؤتمرات القمة الإنمائية (بمجرد أن تصبح هذه النقاط جاهزة).
المطور القمم
في العام الماضي ، عقدنا قمتين للتطوير: واحدة بعد KubeCon EU ، والثانية بعد PromCon. كان من المخطط أن تفعل الشيء نفسه في عام 2020 ، لكن COVID منع. لم تكن هناك اجتماعات قمة هذا العام ، لكنني أعتقد أننا وجدنا مخرجًا: اجتماعات أقصر وأكثر تواترًا وافتراضية. نقضي مجموعات من 4 ساعات بدلاً من جمعها لمدة يوم أو يومين في وقت واحد. عُقدت أول قمة من هذا النوع في 10 يوليو ، ومن المحتمل أن تعقد القمة التالية في 7 أغسطس. سنستمر في إجرائها حتى نحلل جميع الأسئلة المتراكمة (على الرغم من أن عددها يتزايد باستمرار مع إضافة المزيد والمزيد من العناصر من المستند أعلاه).
الآن أريد أن أفعل شيئين:
- , . , , . , . — , , .
- , , . , , .
بدأت البيانات الوصفية في جلب قيمة حقيقية إلى بروميثيوس (انظر 2.15 أعلاه). نحتاج إلى تنفيذ المزيد من الخيارات للعمل مع البيانات الوصفية (على سبيل المثال ، توزيعها عبر القراءة / الكتابة عن بُعد). الإجماع أدناه لا يغطي أسئلة مثيرة للاهتمام مثل "ماذا لو تغيرت البيانات الوصفية / اختفت؟" أو "ماذا لو أصبحوا ناقل للهجوم؟"
التوافق: نريد الحفاظ على البيانات الوصفية بشكل أفضل. سيتم تنفيذ العمل في وثيقة خاصة .
التوافق: سيتم استخدام PR 6815 كحل تجريبي. على الأرجح ، سيكون مختلفًا في الإصدارات 3.x.
تغييرات سير العمل و s / master / main /
لا يتطلب موضوع تنظيف القمامة المتراكمة في عمليات العمل شرحًا خاصًا ، ولكن يجب قول بضع كلمات حول التخلص من الكلام (وحدة المصطلحات). نحن جادون في تنظيف المصطلحات: ليس هذا هو الشيء الأكثر أهمية ، ولكنه شيء يمكننا القيام به الآن. بينما ننتظر مجموعة الأدوات المقابلة من GitHub. بمجرد ظهوره ، سنحاول جذب متدرب بأجر إلى هذا العمل من خلال Community Bridge.
أنا في محادثات مع Linux Foundation و CNCF لتنفيذ ذلك في جميع المشاريع. فرصة رائعة لأي شخص مهتم بهذا الموضوع: فرصة استكشاف العديد من المشاريع ، والعمل باستخدام أدوات متنوعة ، ومقابلة العديد من الأشخاص. تواصل معي على تويتر ( TwitchiH ) أو عبر البريد ( richih على grafana.com) إذا كنت مهتمًا.
التوافق: قم بتعيين "طلب فحوصات الحالة قبل الدمج" في جميع البروميثيوس / المستودعات ... لا تسمح بالدفع المباشر في الفرع الرئيسي؟ لا تسمح بدفع القوة في الفرع الرئيسي؟
التوافق: تعطيل دفع القوة لجميع الفروع الرئيسية.
التوافق: يسمح السلوك الافتراضي بالضغط في الفرع الرئيسي ، ولكن يجب تعطيله لبعض عمليات إعادة الشراء "المهمة" ، على سبيل المثال ، بروميثيوس / بروميثيوس (وفقًا لتقدير المشرف).
التعبئة بالبيانات (الردم)
هذا واحد من أقدم طلبات الميزات ومثال جيد على كيفية التعامل مع الإجماع. هناك العديد من الآراء المختلفة المتداولة في فريق بروميثيوس حول هذه المسألة ، ومن الصعب الوصول إلى قاسم مشترك. لذلك ، كتبت مقترحًا إجماعيًا محدودًا ومحددًا للغاية مع ثلاثة معايير: "نريد دعم الردم عبر الشبكة على الأقل في الكتل التي لا تتداخل مع كتلة الرأس ".
بعد مناقشات مطولة ومحاولات للتوصل إلى توافق ، أصبح من الواضح أن ذلك لن يكون سهلاً. لذلك ، أعدت صياغة الاقتراح على النحو التالي: "نريد دعم الردم عبر الشبكة على الأقل من خلال التدفقات التي لا تتقاطع مع كتلة الرأس".
فقط عن طريق إجبار الجميع للتعبير عن رأيه الخاص بشأن هذه المسألة، تمكنا من التوصل إلى الصيغة النهائية: "نود أن دعم الردم عبر الشبكة في كتل التي لا تتقاطع مع رئيس كتلة، شريطة أن يتم تنفيذه بشكل صحيح ." تم اختيار كل كلمة هنا لتعكس المدى الدقيق وحدود الإجماع.
: Prometheus OpenMetrics, CSV- .
: backfilling , .
: backfilling , .
: backfilling , .
من المهام الأخرى المرتبطة بترتيب الأشياء. هنا أريد أن أنتقد Go: لقد تم تطويره في عالم يكون فيه monorep هو القاعدة. تقوم Google بتخزين كل (أو معظم) التعليمات البرمجية الشائعة في مستودع واحد. هذا النهج له العديد من المزايا ، لكنه لا يترجم جيدًا إلى ظروف العالم الحقيقي. اذهب ببطء ولكن بثبات تبتعد عن هذا الإرث.
حقيقة ممتعة: لقد كتبت اقتراح الإجماع في بداية المناقشة تقريبًا. كان من الواضح أننا سنحاول ذلك على الأقل. كان من الواضح أن بن كوشي سيتطوع للقيام بذلك. وكان من الواضح أن node_exporter ستصبح "الضحية". كقاعدة عامة ، نسعى جاهدين لتحسين سير العمل ، و Ben دائمًا متطوع ، و node_exporter هو مقعد الاختبار الذي ننسخ النتائج منه بعد ذلك إلى المصدرين الآخرين. ونعم ، كان من المهم أن تستمر المناقشة لفترة وأن يأتي الناس إلى هذا بمفردهم ، بدلاً من مواجهتهم بحقيقة.
التوافق: حذفه في node_exporter ومعرفة ما إذا كنا سعداء بالنتيجة.
القوائم البريدية و IRC
تم حظر Google في الصين ، لكن قوائمنا البريدية تعمل على ذلك. قررنا محاولة جعل الاشتراك عن طريق البريد الإلكتروني ممكنًا. راجعت: prometheus-users+subscribe@googlegroups.com يعمل. يمكنك أيضًا قراءة الأرشيف ( https://www.mail-archive.com/prometheus-users@googlegroups.com/maillist.html ) إذا كنت ترغب في ذلك.
بالإضافة إلى ذلك ، تأكدنا من أن كل شخص يمكنه استخدام IRC من خلال المصفوفة ، نظرًا لأن بعض xkcd 1782 مناسب جدًا.
:
, Google ; - .
docs/community , Google.
IRC, Matrix; , .
اسمحوا لي أن أكرر ما قلته في القمة: "أول شيء لم يعجبني في بروميثيوس في عام 2015 كان التوثيق. في عام 2020 ، أنا أكرهها فقط. إنه صعب الاستخدام وعديم الفائدة تقريبًا ، وهو مناسب فقط لأولئك الذين يعرفون بالفعل ما يفعلونه ، أو على الأقل لديهم فكرة جيدة عن المفاهيم ". باختصار ، سنعمل في هذا الاتجاه:
:
:
* (user manual) .
* (reference) , PromQL /.
* (guides), .
Diana Payton , .. .
.
إذا كنت مهتمًا ، فنحن نبحث حاليًا عن كاتب تقني على Grafana Cloud للعمل على وثائق المنبع الرسمية لشركة Prometheus. في نهاية اليوم ، نأخذ التزامنا تجاه المجتمع على محمل الجد.
كالعادة ، سيتم نشر الملاحظات من قمة dev. يمكنك أيضا قراءة نتائج القمة 2020-1 و القمم في السنوات الماضية .
PS من المترجم
اقرأ أيضًا على مدونتنا:
- " المراقبة و Kubernetes " (مراجعة وتقرير بالفيديو) ؛
- " جهاز وآلية مشغل بروميثيوس في Kubernetes " ؛
- " تقديم k8s-image -ability-exporter لاكتشاف الصور المفقودة في Kubernetes ».