🛌🏽 👨🏽‍🚒 👨🏻‍🔧 ثانوس - بروميثيوس قابلة للتحجيم 📂 😯 👩‍👧

تم إعداد ترجمة المقال خصيصًا لطلاب الدورة التدريبية "DevOps Practices and Tools" .

(Fabian Reinartz) — , Go . Prometheus Kubernetes SIG instrumentation. production- SoundCloud CoreOS. Google.

(Bartek Plotka) — Improbable. . Intel, Mesos production- SRE Improbable. . : Golang, open source .

بالنظر إلى منتج SpatialOS الرائد لدينا ، يمكنك تخمين أن Impobable يحتاج إلى بنية تحتية عالمية سحابية ديناميكية للغاية مع العشرات من مجموعات Kubernetes. كنا من أول من استخدم نظام بروميثيوس للرصد . Prometheus قادر على تتبع الملايين من المقاييس في الوقت الحقيقي ويأتي مع لغة استعلام قوية لاسترداد المعلومات الضرورية.

البساطة والموثوقية يعد بروميثيوس أحد مزاياه الرئيسية. ومع ذلك ، بعد اجتياز مقياس معين ، واجهنا العديد من العوائق. لحل هذه المشاكل ، قمنا بتطوير ثانوس- مشروع مفتوح المصدر تم إنشاؤه بواسطة "غير محتمل" لتحويل مجموعات بروميثيوس الحالية بسلاسة إلى نظام مراقبة واحد مع مستودع غير محدود للبيانات التاريخية. ثانوس متاح على جيثب هنا .

ابق على اطلاع على آخر الأخبار من غير محتمل.

أهدافنا مع ثانوس

على نطاق معين ، تنشأ مشاكل تتجاوز قدرات الفانيليا بروميثيوس. كيف يتم تخزين بيتابايت من البيانات التاريخية بشكل موثوق به واقتصاديًا؟ هل يمكن القيام بذلك دون الإخلال بوقت الاستجابة للطلب؟ هل من الممكن الوصول إلى جميع المقاييس الموجودة على خوادم Prometheus المختلفة باستخدام طلب API واحد؟ هل من الممكن دمج البيانات المنسوخة التي تم جمعها باستخدام Prometheus HA بطريقة أو بأخرى؟

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

استعلام البيانات من مثيلات متعددة من Prometheus (استعلام عام)

يقدم بروميثيوس نهجًا وظيفيًا للتجزئة. حتى خادم Prometheus يوفر قابلية تطوير كافية لتحرير المستخدمين من صعوبات المشاركة الأفقية في جميع حالات الاستخدام تقريبًا.

على الرغم من أن هذا نموذج نشر ممتاز ، إلا أنه غالبًا ما يلزم الوصول إلى البيانات على خوادم Prometheus المختلفة من خلال واجهة برمجة تطبيقات واحدة أو واجهة مستخدم - عرض عالمي. بالطبع ، من الممكن عرض عدة طلبات في لوحة Grafana واحدة ، ولكن يمكن تنفيذ كل طلب على خادم Prometheus واحد فقط. من ناحية أخرى ، باستخدام Thanos ، يمكنك الاستعلام عن البيانات وتجميعها من خوادم Prometheus المتعددة ، حيث يمكن الوصول إليها جميعًا من نقطة نهاية واحدة.

في السابق ، للحصول على عرض عالمي لـ Impobable ، قمنا بتنظيم مثيلات Prometheus في مستويات متعددةالاتحاد الهرمي . وهذا يعني إنشاء خادم ميتا Prometheus واحد يجمع جزءًا من المقاييس من كل خادم طرفية ،

والذي ثبت أنه يمثل مشكلة ، مما يعقد التكوين ، ويضيف نقطة فشل محتملة إضافية ويطبق قواعد معقدة لتزويد نقطة النهاية المتحدة بالبيانات الصحيحة فقط. بالإضافة إلى ذلك ، لا يسمح لك الاتحاد من هذا النوع بالحصول على رؤية عالمية حقيقية ، حيث لا يمكن الوصول إلى جميع البيانات من طلب API واحد.

يرتبط هذا بشكل وثيق بهذا العرض التقديمي الوحيد للبيانات التي تم جمعها على خوادم Prometheus عالية التوفر (HA). يقوم نموذج Prometheus HA بجمع البيانات بشكل مستقل مرتين ، وهو أمر بسيط للغاية بحيث لا يمكن أن يكون أبسط. ومع ذلك ، فإن استخدام تمثيل مجمع ومضاعف تكرار لكل من الخيوط سيكون أكثر ملاءمة.

بالطبع ، هناك حاجة لخوادم Prometheus المتاحة للغاية. في Impobable ، نحن جادون حقًا في مراقبة البيانات كل دقيقة ، ولكن وجود مثيل واحد من Prometheus لكل عنقود هو نقطة واحدة للفشل. من المحتمل أن يؤدي أي خطأ في التكوين أو فشل في الأجهزة إلى فقدان البيانات المهمة. حتى عمليات النشر البسيطة يمكن أن تؤدي إلى خلل طفيف في مجموعة المقاييس ، حيث يمكن أن تكون إعادة التشغيل أطول بكثير من فترة الكشط.

تخزين موثوق للبيانات التاريخية

إن تخزين المقاييس رخيصة وسريعة وطويلة الأجل هو حلمنا (يشترك فيه معظم مستخدمي بروميثيوس). في "غير محتمل" ، اضطررنا إلى تعيين فترة التخزين للمقاييس على تسعة أيام (لـ Prometheus 1.8). وهذا يضيف قيودًا واضحة إلى أي مدى يمكننا أن ننظر إلى الوراء.

يعد Prometheus 2.0 أفضل في هذا الصدد ، حيث لم يعد عدد السلاسل الزمنية يؤثر على الأداء العام للخادم (انظر KubeCon keyn about Prometheus 2 ). ومع ذلك ، يقوم Prometheus بتخزين البيانات على محرك أقراص محلي. على الرغم من أن ضغط البيانات عالي الكفاءة يمكن أن يقلل بشكل كبير من استخدام SSD محلي ، لا يزال هناك قيود على كمية البيانات التاريخية التي يتم حفظها.

في Impobable ، نهتم أيضًا بالموثوقية والبساطة والتكلفة. محركات الأقراص المحلية الكبيرة أكثر صعوبة في التشغيل والنسخ الاحتياطي. فهي أكثر تكلفة وتتطلب المزيد من أدوات النسخ الاحتياطي ، مما يؤدي إلى التعقيد غير الضروري.

الاختزال

بمجرد أن بدأنا العمل مع البيانات التاريخية ، أدركنا أن هناك صعوبات أساسية مع O-big تجعل الاستعلامات أبطأ وأبطأ إذا عملنا مع البيانات لأسابيع وشهور وسنوات.

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

يعد اختزال البيانات القديمة مطلبًا لا مفر منه لأي حل تخزين طويل الأجل ويتجاوز الفانيليا بروميثيوس.

أهداف إضافية

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

ثانوس للهندسة المعمارية

بعد سرد أهدافنا في القسم السابق ، دعنا نعمل عليها ونرى كيف يحل ثانوس هذه المشاكل.

نظرة شاملة

للحصول على نظرة عامة على أعلى مثيلات Prometheus الحالية ، نحتاج إلى ربط نقطة إدخال طلب واحد مع جميع الخوادم. هذا هو بالضبط ما يفعله مكون ثانوس سيديكار . يتم نشره بجوار كل خادم Prometheus ويعمل كوكيل ، يخدم بيانات Prometheus المحلية من خلال واجهة gRPC الخاصة بالمخزن ، مما يسمح لك بتحديد بيانات السلاسل الزمنية حسب التصنيف والنطاق الزمني.

من ناحية أخرى ، هناك مكون Querier القابل للتحجيم أفقياً عديم الحالة والذي يقوم بأكثر من مجرد الاستجابة لطلبات PromQL من خلال واجهة برمجة تطبيقات Prometheus HTTP القياسية. مكونات Querier و Sidecar و Thanos الأخرى تتواصل عبر بروتوكول القيل والقال .

يتصل Querier ، عند استلام الطلب ، بخادم Store API المقابل ، أي Sidecar ، ويستقبل بيانات السلاسل الزمنية من خوادم Prometheus المقابلة.
بعد ذلك ، يجمع بين الإجابات وينفذ استعلام PromQL عليها. يمكن أن يجمع Querier كلاً من البيانات المنفصلة والبيانات المكررة من خوادم Prometheus HA.

هذا يحل الجزء الأكبر من اللغز لدينا - يجمع البيانات من خوادم Prometheus المعزولة في عرض واحد. في الواقع ، لا يمكن استخدام ثانوس إلا لهذه الفرصة. لا تحتاج خوادم Prometheus الحالية إلى إجراء أي تغييرات!

مدة صلاحية غير محدودة!

ومع ذلك ، عاجلاً أم آجلاً ، سنريد حفظ البيانات التي تتجاوز وقت التخزين العادي لـ Prometheus. لتخزين البيانات التاريخية ، اخترنا تخزين الكائن. وهي متاحة على نطاق واسع في أي سحابة ، وكذلك في مراكز البيانات المحلية وهي اقتصادية للغاية. بالإضافة إلى ذلك ، يمكن الوصول إلى أي تخزين للكائنات تقريبًا من خلال S3 API المعروفة.

يكتب بروميثيوس البيانات من ذاكرة الوصول العشوائي إلى القرص كل ساعتين تقريبًا. تحتوي كتلة البيانات المخزنة على جميع البيانات لفترة زمنية محددة وهي ثابتة. هذا أمر مريح للغاية ، حيث يمكن لـ Thanos Sidecar ببساطة إلقاء نظرة على كتالوج بيانات Prometheus ، وعند ظهور كتل جديدة ، تحميلها في دلاء تخزين الكائنات.

يتيح لك التنزيل إلى تخزين الكائن مباشرة بعد الكتابة على قرص أيضًا الحفاظ على بساطة "مكشطة" (Prometheus و Thanos Sidecar) بسيطة. مما يبسط الدعم والتكلفة وتصميم النظام.

كما ترى ، يعد النسخ الاحتياطي للبيانات أمرًا بسيطًا للغاية. ولكن ماذا عن الاستعلام عن البيانات في تخزين الكائن؟

يعمل مكون متجر Thanos كوكيل لاسترداد البيانات من تخزين الكائن. مثل ثانوس سيديكار ، تشارك في مجموعة القيل والقال وتطبق Store API. وبالتالي ، يمكن اعتبار Querier الحالي أنها Sidecar ، كمصدر آخر لبيانات السلاسل الزمنية - لا يلزم تكوين خاص.

تتكون كتل بيانات السلاسل الزمنية من عدة ملفات كبيرة. سيكون تنزيلها عند الطلب غير فعال إلى حد كبير ، ويتطلب التخزين المؤقت المحلي ذاكرة ضخمة ومساحة على القرص.

بدلاً من ذلك ، يعرف Store Gateway كيفية التعامل مع تنسيق تخزين Prometheus. بفضل مخطط الاستعلام الذكي والتخزين المؤقت لأجزاء الفهرس الضرورية فقط من الكتل ، أصبح من الممكن تقليل الاستعلامات المعقدة إلى الحد الأدنى لعدد طلبات HTTP لكائنات تخزين الملفات. وبالتالي ، من الممكن تقليل عدد الطلبات بأربعة إلى ستة أوامر من حيث الحجم وتحقيق أوقات الاستجابة التي يصعب بشكل عام تمييزها عن طلبات البيانات على SSD محلي.

كما هو موضح في الرسم البياني أعلاه ، يقلل Thanos Querier بشكل كبير من تكلفة طلب بيانات واحد في تخزين الكائن باستخدام تنسيق تخزين Prometheus ووضع البيانات ذات الصلة جنبًا إلى جنب. باستخدام هذا النهج ، يمكننا دمج العديد من الاستعلامات الفردية في الحد الأدنى من العمليات المجمعة.

الضغط والاختزال

بعد تحميل كتلة بيانات السلاسل الزمنية الجديدة بنجاح في تخزين الكائن ، نعتبرها بيانات "تاريخية" تصبح متاحة على الفور من خلال بوابة المتجر.

ومع ذلك ، بعد فترة ، تتراكم الكتل من مصدر واحد (Prometheus with Sidecar) ولم تعد تستخدم إمكانات الفهرسة الكاملة. لحل هذه المشكلة ، قدمنا مكونًا آخر يسمى Compactor. إنه ببساطة يطبق آلية ضغط Prometheus المحلية على البيانات التاريخية في ملف تخزين العناصر ويمكن تشغيلها كمهمة دورية بسيطة.

بفضل الضغط الفعال ، فإن الاستعلام في المستودع لفترة طويلة من الزمن لا يمثل مشاكل من حيث حجم البيانات. ومع ذلك ، فإن التكلفة المحتملة لتفريغ مليار قيمة وتشغيلها من خلال معالج الاستعلام ستؤدي حتمًا إلى زيادة حادة في وقت تنفيذ الاستعلام. من ناحية أخرى ، نظرًا لوجود مئات نقاط البيانات لكل بكسل من الشاشة ، يصبح من المستحيل حتى تصور البيانات بدقة كاملة. وبالتالي ، فإن الاختزال ليس ممكنًا فحسب ، ولكنه لن يؤدي إلى فقدان ملحوظ للدقة.

بالنسبة لبيانات الاختزال ، يقوم Compactor باستمرار بتجميع البيانات بدقة خمس دقائق وساعة واحدة. لكل جزء خام مشفر باستخدام ضغط TSDB XOR ، يتم تخزين أنواع مختلفة من البيانات المجمعة ، مثل min أو max أو sum لكتلة واحدة. يسمح هذا لـ Querier بتحديد التجميع الملائم لاستعلام PromQL هذا تلقائيًا.

لاستخدام البيانات بدقة منخفضة ، لا يحتاج المستخدم إلى أي تكوين خاص. يقوم Querier بالتبديل تلقائيًا بين درجات الدقة المختلفة والبيانات الأولية أثناء تكبير وتصغير المستخدم. إذا رغبت في ذلك ، يمكن للمستخدم التحكم في ذلك مباشرة من خلال معلمة "الخطوة" في الطلب.

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

قواعد التسجيل

حتى مع قواعد التسجيل ثانوس هي جزء أساسي من مكدس المراقبة. إنها تقلل من تعقيد الطلبات وكمونها وتكلفةها. كما أنها ملائمة للمستخدمين للحصول على بيانات المقاييس المجمعة. يعتمد Thanos على حالات الفانيليا من Prometheus ، لذلك من المقبول تمامًا تخزين قواعد التسجيل وقواعد التنبيه على خادم Prometheus الحالي. ومع ذلك ، في بعض الحالات ، قد لا يكون هذا كافيًا:

التنبيهات والقواعد العامة (على سبيل المثال ، التنبيهات عند تعطل الخدمة في أكثر من مجموعتين من المجموعات الثلاث).
قاعدة للبيانات خارج التخزين المحلي.
الرغبة في إبقاء كل القواعد واليقظة في مكان واحد.

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

قوة ثانوس

ثانوس مرنة بما فيه الكفاية ليتم تخصيصها لمتطلباتك. هذا مفيد بشكل خاص عند الهجرة من بروميثيوس البسيط. دعونا نلقي نظرة سريعة على ما تعلمناه عن مكونات ثانوس. فيما يلي كيفية نقل الفانيليا بروميثيوس إلى عالم "تخزين المقاييس غير محدود":

أضف Thanos Sidecar إلى خوادم Prometheus - على سبيل المثال ، الحاوية المجاورة في حجرة Kubernetes.
قم بتوسيع نسخ متماثلة ثانوس Querier لعرض البيانات. في هذه المرحلة ، من السهل إعداد النميمة بين Scraper و Querier. استخدم المقياس "thanos_cluster_members" لاختبار تفاعلات المكونات.

فقط هاتان الخطوتان تكفيان لتقديم نظرة عامة وإلغاء تكرار البيانات بسلاسة من النسخ المتماثلة Prometheus HA المحتملة! ما عليك سوى توصيل لوحات التحكم بنقطة نهاية Querier HTTP أو استخدام واجهة Thanos UI مباشرة.

ومع ذلك ، إذا كنت بحاجة إلى إجراء نسخ احتياطي للمقاييس والتخزين على المدى الطويل ، فستحتاج إلى تنفيذ ثلاث خطوات أخرى:

بناء دلو AWS S3 أو GCS. قم بتكوين Sidecar لنسخ البيانات إلى هذه المجموعات. الآن يمكنك تقليل تخزين البيانات المحلية.
قم بتوسيع بوابة المتجر وقم بتوصيلها بمجموعة القيل والقال الموجودة. الآن يمكنك إرسال طلبات البيانات في النسخ الاحتياطية!
نشر Compactor لتحسين أداء الاستعلام على مدى فترات طويلة باستخدام الضغط والاختزال.

إذا كنت تريد أن تعرف أكثر، لا تتردد في إلقاء نظرة على لدينا أمثلة على kubernetes واضح و بدء !

في خمس خطوات فقط ، قمنا بتحويل Prometheus إلى نظام مراقبة موثوق به مع عرض عالمي ووقت تخزين غير محدود وإمكانية توفر عالية للمقاييس.

سحب الطلب: نحن بحاجة إليك!

كان ثانوس مشروعًا مفتوح المصدر منذ البداية. التكامل السلس مع Prometheus والقدرة على استخدام جزء فقط من ثانوس يجعلها خيارًا ممتازًا لتغيير نظام المراقبة دون أي جهد إضافي.

نرحب دائمًا بطلب GitHub Pull والقضايا. في الوقت نفسه ، لا تتردد في الاتصال بنا من خلال Github Issues أو slack Improbable-eng #thanos إذا كان لديك أسئلة أو تعليقات ، أو تريد مشاركة تجربتك! إذا أعجبك ما نقوم به في "غير محتمل" ، فلا تتردد في الاتصال بنا - لدينا دائمًا وظائف شاغرة !

تعلم المزيد عن الدورة.

ثانوس - بروميثيوس قابلة للتحجيم