تم إعداد ترجمة المقال خصيصًا لطلاب الدورة .
هو مطور برمجيات ، انطلق متعصبًا وحل المشكلات. وهو أيضًا المشرف على شركة Prometheus والمؤسس المشارك لأجهزة Kubernetes SIG. في الماضي ، كان مهندس إنتاج في SoundCloud وقاد فريق المراقبة في CoreOS. يعمل حاليا في جوجل.
- مهندس البنية التحتية في غير محتمل. إنه مغرم بالتقنيات الجديدة ومشاكل الأنظمة الموزعة. لديه خبرة برمجة منخفضة المستوى في Intel ، وخبرة مساهم في Mesos ، وخبرة عالمية في إنتاج SRE في غير محتمل. منخرط في تحسين عالم الخدمات المصغرة. أحبه الثلاثة هم Golang والمصدر المفتوح والكرة الطائرة.
بالنظر إلى منتجنا الرائد SpatialOS ، يمكنك تخمين أن غير محتمل يحتاج إلى بنية أساسية سحابية عالمية ديناميكية للغاية مع عشرات من مجموعات Kubernetes. كنا من بين الأوائل الذين بدأوا في استخدام نظام المراقبة . بروميثيوس قادر على تتبع ملايين المقاييس في الوقت الفعلي ويأتي مع لغة استعلام قوية لاستخراج المعلومات التي تحتاجها.
تعد بساطة وموثوقية بروميثيوس إحدى مزاياها الرئيسية. ومع ذلك ، بعد اجتياز مقياس معين ، واجهنا العديد من العيوب. لحل هذه المشاكل ، قمنا بتطويرها هو مشروع مفتوح المصدر تم إنشاؤه بواسطة غير محتمل لتحويل مجموعات بروميثيوس الحالية بسلاسة إلى نظام مراقبة واحد مع تخزين بيانات تاريخية غير محدود. ثانوس متاح على جيثب .
أهدافنا مع ثانوس
على نطاق معين ، تنشأ مشاكل تتجاوز قدرات الفانيليا بروميثيوس. كيف يتم تخزين بيتابايتات من البيانات التاريخية بشكل آمن واقتصادي؟ هل يمكن القيام بذلك دون المساومة بوقت استجابة الاستعلام؟ هل من الممكن الوصول إلى جميع المقاييس الموجودة على خوادم بروميثيوس المختلفة بطلب واحد لواجهة برمجة التطبيقات؟ هل هناك أي طريقة لدمج البيانات المنسوخة التي تم جمعها مع Prometheus HA؟
لمعالجة هذه القضايا ، أنشأنا ثانوس. تصف الأقسام التالية كيف تعاملنا مع هذه القضايا وشرح الأهداف التي سعينا إليها.
بيانات الاستعلام من مثيلات بروميثيوس متعددة (استعلام عمومي)
يقدم بروميثيوس نهجًا وظيفيًا للتجزئة. حتى خادم Prometheus واحد يوفر قابلية توسعية كافية لتحرير المستخدمين من تعقيدات التجزئة الأفقية في جميع حالات الاستخدام تقريبًا.
على الرغم من أن هذا نموذج نشر رائع ، إلا أنه غالبًا ما يكون مطلوبًا للوصول إلى البيانات الموجودة على خوادم Prometheus المختلفة من خلال واجهة برمجة تطبيقات أو واجهة مستخدم واحدة - العرض العام. بالطبع ، من الممكن عرض طلبات متعددة في لوحة Grafana واحدة ، ولكن لا يمكن تقديم كل طلب إلا إلى خادم Prometheus واحد. من ناحية أخرى ، باستخدام Thanos ، يمكنك الاستعلام عن البيانات وتجميعها من خوادم Prometheus المتعددة حيث يمكن الوصول إليها جميعًا من نفس نقطة النهاية.
في وقت سابق ، من أجل الحصول على عرض عام في "غير محتمل" ، قمنا بتنظيم مثيلات بروميثيوس لدينا في مستويات متعددة . وهذا يعني إنشاء خادم تعريف بروميثيوس واحد يجمع جزءًا من المقاييس من كل خادم "طارئ".
أثبت هذا النهج إشكالية. نتج عن ذلك تكوين أكثر تعقيدًا ، وإضافة نقطة فشل محتملة إضافية ، وتطبيق قواعد معقدة لتزويد نقطة النهاية الموحدة بالبيانات التي تحتاجها فقط. بالإضافة إلى ذلك ، لا يسمح لك هذا النوع من الاتحاد بالحصول على عرض عام حقيقي ، حيث لا تتوفر جميع البيانات من طلب واجهة برمجة تطبيقات واحد.
ترتبط ارتباطًا وثيقًا بهذا العرض الفردي للبيانات التي تم جمعها على خوادم Prometheus عالية التوفر (HA). يجمع نموذج Prometheus HA البيانات بشكل مستقل مرتين ، وهو أمر بسيط بقدر ما يحصل. ومع ذلك ، فإن استخدام التمثيل المجمع وغير المكرر لكلا الدفقين سيكون أكثر ملاءمة.
بالطبع ، هناك حاجة لخوادم بروميثيوس عالية التوفر. في غير محتمل ، نحن جادون حقًا في مراقبة البيانات كل دقيقة ، ولكن وجود مثيل بروميثيوس واحد لكل مجموعة هو نقطة فشل واحدة. من المحتمل أن يؤدي أي خطأ في التكوين أو فشل في الأجهزة إلى فقدان البيانات المهمة. حتى النشر البسيط يمكن أن يؤدي إلى مواطن الخلل الطفيفة في جمع المقاييس لأن إعادة التشغيل يمكن أن تكون أطول بكثير من فترة الكشط.
تخزين موثوق للبيانات التاريخية
إن تخزين المقاييس الرخيصة والسريع والطويل الأجل هو حلمنا (يتقاسمه غالبية مستخدمي Prometheus). في غير المحتمل ، اضطررنا إلى تعيين فترة الاحتفاظ بالمقاييس على تسعة أيام (لـ Prometheus 1.8). يضيف هذا حدودًا واضحة إلى أي مدى يمكن أن ننظر إلى الوراء.
تم تحسين Prometheus 2.0 في هذا الصدد ، حيث لم يعد عدد السلاسل الزمنية يؤثر على الأداء العام للخادم (انظر أدناه). ). ومع ذلك ، يقوم Prometheus بتخزين البيانات على محرك الأقراص المحلي. على الرغم من أن ضغط البيانات عالي الكفاءة يمكن أن يقلل بشكل كبير من استخدام SSD المحلي ، إلا أنه يوجد في النهاية حد لمقدار البيانات التاريخية التي يمكن تخزينها.
بالإضافة إلى ذلك ، في غير محتمل ، نهتم بالموثوقية والبساطة والتكلفة. تعد محركات الأقراص المحلية الكبيرة أكثر صعوبة في الصيانة والنسخ الاحتياطي. إنها تكلف أكثر وتتطلب المزيد من أدوات النسخ الاحتياطي ، مما يؤدي إلى تعقيد غير ضروري.
الاختزال
بمجرد أن بدأنا العمل مع البيانات التاريخية ، أدركنا أن هناك صعوبات أساسية في O الكبيرة تجعل الاستعلامات أبطأ وأبطأ إذا عملنا مع البيانات لأسابيع وشهور وسنوات.
سيكون الحل القياسي لهذه المشكلة (الاختزال) - تقليل وتيرة أخذ العينات للإشارة. من خلال الاختزال ، يمكننا "تصغير" إلى نطاق زمني أكبر والحفاظ على نفس العدد من العينات ، مما سيبقي استفساراتنا متجاوبة.
يعد اختزال البيانات القديمة مطلبًا حتميًا لأي حل تخزين طويل الأجل ويتجاوز الفانيليا بروميثيوس.
أهداف إضافية
كان أحد الأهداف الأصلية لمشروع Thanos هو التكامل السلس مع أي من تركيبات Prometheus الحالية. الهدف الثاني كان عملية بسيطة مع الحد الأدنى من الحواجز للدخول. يجب إرضاء أي تبعيات بسهولة لكل من المستخدمين الصغار والكبار ، مما يعني أيضًا تكلفة أساسية لا تذكر.
العمارة ثانوس
بعد أن أدرجنا أهدافنا في القسم السابق ، فلنعمل عليها ونرى كيف يحل ثانوس هذه المشاكل.
نظرة شاملة
للحصول على عرض عام أعلى مثيلات بروميثيوس الحالية ، نحتاج إلى ربط نقطة إدخال طلب واحدة بجميع الخوادم. هذا هو بالضبط ما يفعله مكون ثانوس. . يتم نشره بجوار كل خادم من خوادم Prometheus ويعمل كوكيل يخدم بيانات Prometheus المحلية عبر واجهة برمجة تطبيقات gRPC Store ، والتي تتيح لك تحديد بيانات السلاسل الزمنية حسب الطابع الزمني والنطاق الزمني.
على الجانب الآخر ، يوجد مكون Querier قابل للتوسع أفقيًا وعديم الحالة ولا يفعل أكثر من مجرد الاستجابة لاستعلامات PromQL من خلال Prometheus HTTP API. تتفاعل المكونات Querier و Sidecar وغيرهما من ثانوس عبر .
- عند تلقي طلب ، يتصل Querier بخادم Store API المقابل ، أي بـ Sidecars ، ويتلقى بيانات السلاسل الزمنية من خوادم Prometheus المقابلة.
- بعد ذلك ، يجمع بين الردود وينفذ استعلام PromQL عليها. يمكن لـ Querier تجميع كل من البيانات غير المتداخلة والبيانات المكررة من خوادم Prometheus HA.
هذا يحل الجزء الرئيسي من اللغز الخاص بنا - دمج البيانات من خوادم Prometheus المعزولة في عرض واحد. في الواقع ، لا يمكن استخدام Thanos إلا لهذه الفرصة. لا تتطلب خوادم بروميثيوس الحالية أي تعديلات!
وقت تخزين غير محدود!
ومع ذلك ، سنرغب عاجلاً أم آجلاً في تخزين البيانات التي تتجاوز وقت الاحتفاظ العادي في بروميثيوس. لتخزين البيانات التاريخية ، اخترنا تخزين الكائنات. وهي متوفرة على نطاق واسع في أي سحابة وكذلك في مراكز البيانات المحلية وهي فعالة للغاية من حيث التكلفة. بالإضافة إلى ذلك ، يتوفر أي تخزين للعناصر تقريبًا من خلال واجهة S3 API المعروفة.
بروميثيوس يكتب البيانات من ذاكرة الوصول العشوائي إلى القرص كل ساعتين تقريبًا. تحتوي كتلة البيانات المخزنة على جميع البيانات لفترة زمنية محددة وغير قابلة للتغيير. يعد هذا مناسبًا للغاية ، حيث يمكن لـ Thanos Sidecar إلقاء نظرة على دليل بيانات Prometheus ، وعندما تظهر كتل جديدة ، قم بتحميلها في دلاء تخزين الكائنات.
كما أن التحميل في وحدة تخزين العناصر فور الكتابة على القرص يحافظ أيضًا على بساطة "الكاشطة" (بروميثيوس وثانوس سايدكار). هذا يبسط صيانة النظام وتكلفته وتصميمه.
كما ترى ، من السهل جدًا تنفيذ النسخ الاحتياطي للبيانات. ولكن ماذا عن الاستعلام عن البيانات في تخزين الكائنات؟
يعمل مكون Thanos Store كوكيل للحصول على البيانات من مخزن العناصر. مثل Thanos Sidecar ، تشارك في مجموعة القيل والقال وتنفذ Store API. وبالتالي ، يمكن لـ Queriers الحاليين معاملته على أنه Sidecar ، كمصدر آخر لبيانات السلاسل الزمنية - لا يلزم تكوين خاص.
تتكون كتل بيانات السلاسل الزمنية من عدة ملفات كبيرة. سيكون تحميلها عند الطلب غير فعال إلى حد ما ، وسيتطلب تخزينها مؤقتًا محليًا قدرًا هائلاً من الذاكرة ومساحة القرص.
بدلاً من ذلك ، يعرف Store Gateway كيفية التعامل مع تنسيق تخزين Prometheus. بفضل مخطط الاستعلام الذكي والتخزين المؤقت فقط لأجزاء الفهرس الضرورية من الكتل ، أصبح من الممكن تقليل الطلبات المعقدة إلى الحد الأدنى من طلبات HTTP لملفات تخزين الكائنات. وبالتالي ، من الممكن تقليل عدد الطلبات بمقدار أربعة إلى ستة أوامر من حيث الحجم وتحقيق وقت استجابة يصعب تمييزه عمومًا عن طلبات البيانات على SSD محلي.
كما هو موضح في الرسم البياني أعلاه ، يقلل Thanos Querier بشكل كبير من تكلفة كل طلب للبيانات في تخزين الكائنات باستخدام تنسيق تخزين Prometheus ووضع البيانات ذات الصلة جنبًا إلى جنب. باستخدام هذا النهج ، يمكننا دمج العديد من الطلبات الفردية في أقل عدد ممكن من العمليات المجمعة.
الضغط والاختزال
بعد تحميل كتلة جديدة من بيانات السلاسل الزمنية بنجاح في مخزن العناصر ، فإننا نعتبرها بيانات "تاريخية" ، والتي تتوفر على الفور من خلال Store Gateway.
ومع ذلك ، بعد مرور بعض الوقت ، تتراكم الكتل من مصدر واحد (بروميثيوس مع Sidecar) ولم تعد تستخدم الإمكانات الكاملة للفهرسة. لحل هذه المشكلة ، قدمنا مكونًا آخر يسمى Compactor. إنه ببساطة يطبق آلية ضغط Prometheus المحلية على البيانات التاريخية في تخزين الكائنات ويمكن تشغيله كوظيفة دفعية دورية بسيطة.
نظرًا للضغط الفعال ، فإن الاستعلام عن التخزين على مدى فترة زمنية طويلة لا يمثل مشكلة من حيث حجم البيانات. ومع ذلك ، فإن التكلفة المحتملة لتفريغ مليار قيمة وتشغيلها من خلال معالج الاستعلام ستؤدي حتمًا إلى زيادة كبيرة في وقت تنفيذ الاستعلام. من ناحية أخرى ، نظرًا لوجود مئات من نقاط البيانات لكل بكسل على الشاشة ، يصبح من المستحيل حتى عرض البيانات بدقة كاملة. وبالتالي ، فإن الاختزال ليس ممكنًا فحسب ، ولكنه لن يؤدي إلى فقدان ملحوظ في الدقة.
لاختزال البيانات ، تقوم أداة Compactor بتجميع البيانات باستمرار بدقة تبلغ خمس دقائق وساعة واحدة. لكل جزء خام تم ترميزه بضغط TSDB XOR ، يتم تخزين أنواع مختلفة من البيانات المجمعة ، مثل الحد الأدنى أو الحد الأقصى أو المجموع لكتلة واحدة. يسمح هذا لـ Querier بتحديد إجمالي مناسب لاستعلام PromQL محدد تلقائيًا.
لا يلزم تكوين خاص للمستخدم لاستخدام بيانات منخفضة الدقة. يقوم Querier تلقائيًا بالتبديل بين الدقة المختلفة والبيانات الأولية أثناء قيام المستخدم بالتكبير والتصغير. إذا رغبت في ذلك ، يمكن للمستخدم التحكم في هذا مباشرة من خلال معلمة "الخطوة" في الطلب.
نظرًا لأن تكلفة التخزين البالغة XNUMX جيجابايت منخفضة ، فإن Thanos يحفظ البيانات الأصلية افتراضيًا ، والبيانات بدقة خمس دقائق وساعة واحدة. ليست هناك حاجة لحذف البيانات الأصلية.
قواعد التسجيل
حتى مع Thanos ، تعد قواعد التسجيل جزءًا أساسيًا من مكدس المراقبة. فهي تقلل التعقيد ووقت الاستجابة وتكلفة الاستعلامات. كما أنها مريحة للمستخدمين للحصول على بيانات مجمعة حسب المقاييس. يعتمد ثانوس على مثيلات الفانيليا من بروميثيوس ، لذلك من المقبول تمامًا الاحتفاظ بقواعد التسجيل وقواعد التنبيه على خادم بروميثيوس الحالي. ومع ذلك ، قد لا يكون هذا كافيًا في بعض الحالات:
- تنبيه عام وقاعدة (على سبيل المثال ، تنبيه عند تعطل إحدى الخدمات في أكثر من مجموعتين من المجموعات الثلاث).
- حكم للبيانات خارج التخزين المحلي.
- الرغبة في تخزين جميع القواعد والتنبيهات في مكان واحد.
لجميع هذه الحالات ، يتضمن Thanos مكونًا منفصلاً يسمى Ruler يقوم بتقييم القاعدة والتنبيه عبر Thanos Queries. من خلال توفير StoreAPI المشهور ، يمكن لعقدة الاستعلام الوصول إلى المقاييس المحسوبة حديثًا. في وقت لاحق ، يتم تخزينها أيضًا في تخزين الكائنات وإتاحتها من خلال Store Gateway.
ربما من ثانوس
ثانوس مرن بما يكفي لتخصيصه حسب احتياجاتك. هذا مفيد بشكل خاص عند الهجرة من بروميثيوس عادي. دعنا نراجع بسرعة ما تعلمناه عن مكونات Thanos باستخدام مثال صغير. إليك كيفية إحضار Vanilla Prometheus إلى عالم "التخزين المتري غير المحدود":
- أضف Thanos Sidecar إلى خوادم Prometheus - على سبيل المثال ، حاوية مجاورة في حجرة Kubernetes.
- انشر عدة نسخ متماثلة من Thanos Querier لعرض البيانات. في هذه المرحلة ، من السهل إعداد ثرثرة بين Scraper و Querier. للتحقق من تفاعل المكونات ، استخدم مقياس "thanos_cluster_members".
هاتان الخطوتان وحدهما كافيتان لتوفير رؤية شاملة وإلغاء البيانات المكررة السلس من النسخ المتماثلة المحتملة من Prometheus HA! ما عليك سوى توصيل لوحات المعلومات بنقطة نهاية HTTP Querier أو استخدام واجهة Thanos UI مباشرة.
ومع ذلك ، إذا كنت بحاجة إلى الاحتفاظ بنسخة احتياطية من المقاييس والاحتفاظ بها على المدى الطويل ، فهناك ثلاث خطوات أخرى يتعين عليك اتخاذها:
- أنشئ حاوية AWS S3 أو GCS. قم بإعداد Sidecar لنسخ البيانات إلى هذه الحاويات. يمكنك الآن تقليل تخزين البيانات المحلية.
- انشر بوابة المتجر وقم بتوصيلها بمجموعة ثرثرة موجودة. الآن يمكنك إرسال طلبات للبيانات في النسخ الاحتياطية!
- قم بنشر الضاغط لتحسين أداء الاستعلام على مدى فترات طويلة من الوقت باستخدام الضغط والاختزال.
إذا كنت تريد معرفة المزيد ، فلا تتردد في إلقاء نظرة على и !
في خمس خطوات فقط ، قمنا بتحويل بروميثيوس إلى نظام مراقبة قوي مع نظرة عالمية ، ووقت تخزين غير محدود ، وإمكانية توفر عالية للمقاييس.
طلب السحب: نحن بحاجة إليك!
كان مشروعًا مفتوح المصدر من البداية. التكامل السلس مع Prometheus والقدرة على استخدام جزء فقط من Thanos يجعلها خيارًا رائعًا لتوسيع نطاق نظام المراقبة الخاص بك دون عناء.
نرحب دائمًا بطلبات السحب والمشكلات على GitHub. في غضون ذلك ، لا تتردد في الاتصال بنا عبر Github Issues أو Slackإذا كانت لديك أسئلة أو تعليقات ، أو ترغب في مشاركة تجربتك! إذا أعجبك ما نقوم به في غير محتمل ، فلا تتردد في الاتصال بنا - !
المصدر: www.habr.com