مرحبا بالجميع. يوجد أدناه نسخة من التقرير مع Big Monitoring Meetup 4 .
بروميثيوس هو نظام مراقبة للأنظمة والخدمات المختلفة ، حيث يمكن لمسؤولي النظام جمع المعلومات حول المعلمات الحالية للأنظمة وتكوين التنبيهات لتلقي إخطارات الانحرافات في تشغيل الأنظمة.
سيقارن التقرير بين Thanos و VictoriaMetrics ، مشاريع للتخزين طويل الأجل لمقاييس Prometheus.
أولاً ، سأتحدث عن بروميثيوس. هذا نظام مراقبة يجمع المقاييس من أهداف معينة ويحفظها في التخزين المحلي. يمكن لـ Prometheus أن يكتب المقاييس إلى مستودع بعيد ، ويمكن أن يولد تنبيهات وقواعد التسجيل.
حدود بروميثيوس:
- لا يحتوي على عرض استعلام عام. هذا عندما يكون لديك العديد من الحالات المستقلة للبروميثيوس. يقومون بجمع المقاييس. وتريد تقديم طلب فوق كل هذه المقاييس التي تم جمعها من حالات مختلفة من بروميثيوس. بروميثيوس لا يسمح بذلك.
- مع prometheus ، يقتصر الأداء على خادم واحد فقط. لا يمكن لـ Prometheus القياس تلقائيًا إلى خوادم متعددة. يمكنك تقسيم أهدافك يدويًا فقط بين بروميثيوس المتعددة.
- يقتصر حجم المقاييس في Prometheus على خادم واحد فقط لنفس السبب الذي يتعذر عليه القياس تلقائيًا إلى خوادم متعددة.
- في Prometheus ، ليس من السهل تنظيم أمان البيانات.
حل هذه المشاكل / التحديات؟
الحلول هي:
كل حلول التخزين عن بُعد التي جمعتها بروميثيوس. يقومون بحل مشكلة التخزين عن بُعد من الشريحة السابقة بطرق مختلفة. في هذا العرض التقديمي ، سأتحدث فقط عن الحلين الأولين: Thanos و VictoriaMetrics .
لأول مرة ، ظهرت معلومات حول Thanos على هذا الرابط . وهو يصف بنية Thanos وكيف يعمل.
Thanos يأخذ البيانات التي حفظها Prometheus على القرص المحلي ونسخها إلى S3 ، إلى GCS أو إلى تخزين كائن آخر.
بهذه الطريقة ، يوفر Thanos طريقة عرض استعلام عمومي. يمكنك طلب البيانات المخزنة في تخزين الكائن من مثيلات متعددة من بروميثيوس.
يدعم Thanos PromQL و API الاستعلام Prometheus .
يستخدم Thanos رمز Prometheus لتخزين البيانات.
يتم تطوير Thanos بواسطة نفس المطورين مثل Prometheus.
حول VictoriaMetrics . هنا هو الرابط حيث تحدثنا لأول مرة عن VictoriaMetrics .
يتلقى VictoriaMetrics بيانات من عدة بروميثيوس عبر بروتوكول API للكتابة عن بُعد المدعوم من بروميثيوس.
يوفر VictoriaMetrics طريقة عرض استعلام عامة ، حيث يمكن لمثيلات متعددة من Prometheus كتابة البيانات إلى VictoriaMetrics واحدة. وفقا لذلك ، يمكنك تقديم طلبات لجميع هذه البيانات.
يدعم VictoriaMetrics أيضًا ، مثل Thanos و PromQL و Prometheus الاستعلام عن API.
على عكس Thanos ، تتم كتابة شفرة مصدر VictoriaMetrics من نقطة الصفر وتحسين للسرعة والموارد.
VictoriaMetrics ، على عكس Thanos ، يحجم رأسياً وأفقياً. هناك نسخة أحادية العقدة تحجيم رأسياً. يمكنك أن تبدأ بمعالج واحد و 1 جيجابايت من الذاكرة وتنمو تدريجياً إلى مئات المعالجات و 1 تيرابايت من الذاكرة. يمكن لـ VictoriaMetrics استخدام كل هذه الموارد. سيزيد أدائها بنحو 100 مرة مقارنة بنظام أحادي النواة.
بدأ تاريخ Thanos في نوفمبر 2017 ، عندما ظهر أول التزام عام. قبل ذلك ، تم تطوير Thanos داخليًا بواسطة improbable.io .
في يونيو 2019 ، كان هناك إصدار تاريخي 0.5.0 ، حيث تمت إزالة بروتوكول القيل والقال . تمت إزالته من Thanos لأنه لم يفعل ما بوسعه. غالبًا لا تعمل مجموعة Thanos بشكل صحيح ، والعُقد المتصلة بها بشكل غير صحيح بسبب بروتوكول gossip. لذلك ، قرروا إزالته من هناك. أعتقد أن هذا هو القرار الصحيح.
وفي يونيو 2019 أيضًا ، أرسلوا رقم الطلب 256 إلى مؤسسة Cloud Native Computing Foundation .
وبعد بضعة أشهر ، انضم Thanos إلى مؤسسة Cloud Native Computing Foundation ، والتي تشمل Prometheus و Kubernetes وغيرها من المشاريع الشعبية.
في يناير 2018 ، بدأ تطوير VictoriaMetrics.
في أيلول (سبتمبر) 2018 ، ذكرتُ أولاً VictoriaMetrics.
في ديسمبر 2018 ، تم نشر الإصدار المفرد.
في مايو 2019 ، تم نشر مصادر كل من عقدة واحدة وإصدار نظام المجموعة.
في يونيو 2019 ، مثل Thanos ، تقدمنا بطلب إلى مؤسسة CNCF بالرقم 255 . طبقنا يوم واحد قبل تطبيق Thanos.
لكن لسوء الحظ ، ما زلنا لم نقبل هناك. بحاجة الى مساعدة من المجتمع.
النظر في أهم الشرائح التي تبين بنية Thanos و VictoriaMetrics.
لنبدأ مع Thanos. المكونات الصفراء هي مكونات بروميثيوس. كل شيء آخر هو مكونات Thanos. لنبدأ مع المكون الأكثر أهمية. Thanos Sidecar هو مكون مثبت بجانب كل Prometheus. إنه ملتزم بتحميل بيانات Prometheus من التخزين المحلي إلى S3 أو في تخزين كائن آخر.
يوجد أيضًا مكون مثل Thanos Store Gateway ، والذي يمكنه قراءة هذه البيانات من تخزين الكائن بناءً على الطلبات الواردة من Thanos Query. يقوم Thanos Query بتنفيذ PromQL و Prometheus API. وهذا هو ، من الخارج يبدو وكأنه بروميثيوس. يقبل استعلامات PromQL ، يرسلها إلى Thanos Store Gateway ، يسترد Thanos Store Gateway البيانات الضرورية من Object Storage ، ويرسلها مرة أخرى.
لكننا قمنا بتخزين البيانات في "تخزين الكائنات" دون الساعتين الأخيرتين بسبب خصوصية تطبيق Thanos Sidecar ، الذي لا يمكن تحميل الساعتين الأخيرتين إلى Object Storage S3 ، لأن هاتين الساعتين لم يقم بروميثيوس بإنشاء ملفات في التخزين المحلي.
كيف قرروا الالتفاف على هذا؟ يقوم Thanos Query ، بالإضافة إلى الطلبات المقدمة من Thanos Store Gateway ، بإرسال طلبات متوازية إلى كل Thanos Sidecar بجوار Prometheus.
و Thanos Sidecar ، بدوره ، الوكلاء يطلبون المزيد في بروميثيوس ، ويحصلون على بيانات للساعتين الأخيرتين.
بالإضافة إلى هذه المكونات ، هناك أيضًا مكون اختياري لن تشعر Thanos به جيدًا. هذا هو Thanos Compact ، الذي يدمج الملفات الصغيرة على Object Object في ملفات أكبر تم تحميلها من قبل Thanos Sidecar. يقوم Thanos Sidecar بتحميل ملفات البيانات هناك خلال ساعتين. هذه الملفات ، إذا لم تقم بدمجها في ملفات أكبر ، فيمكن أن يزيد عددها بشكل كبير. كلما زاد عدد هذه الملفات ، زادت الحاجة إلى ذاكرة Thanos Store Gateway ، زادت الموارد اللازمة لنقل البيانات عبر الشبكة ، بيانات التعريف. Thanos Store Gateway أصبح غير فعال. لذلك ، يجب عليك بالتأكيد تشغيل Thanos Compact ، والذي يدمج الملفات الصغيرة في ملفات أكبر بحيث يكون عدد هذه الملفات أقل وتقليل الحمل على Thanos Store Gateway.
يوجد أيضًا مكون مثل Thanos Ruler. يتبع قواعد تنبيه Prometheus ويمكنه حساب قواعد تسجيل Prometheus من أجل كتابة البيانات مرة أخرى إلى Object Storage. ولكن هذا العنصر غير مستحسن ، لأنه يميل إلى إرجاع بيانات غير كاملة .
هذا هو مخطط بسيط ل Thanos.
قارن الآن مع مخطط VictoriaMetrics.
يحتوي VictoriaMetrics على نسختين: العقدة المفردة والنسخة العنقودية. يتم تشغيل العقدة المفردة على جهاز كمبيوتر واحد. عقدة واحدة لا تحتوي على هذه المكونات ، فقط ثنائي واحد. هذا الثنائي على الشريحة يشبه هذا المربع. كل ما بداخل المربع هو محتويات الملف الثنائي لإصدار عقدة واحدة. لا تحتاج أن تعرف عنه. مجرد بداية الثنائية - ويعمل كل شيء بالنسبة لنا.
إصدار الكتلة أكثر تعقيدًا. داخلها هناك ثلاثة مكونات مختلفة: vmselect ، vminsert و vmstorage. من اسمهم يجب أن يكون واضحا ما يفعله كل منهم. يقبل المكون Insert البيانات بتنسيقات مختلفة: من واجهة برمجة تطبيقات Prometheus للكتابة عن بُعد وبروتوكول خط التدفق وبروتوكول الجرافيت وبروتوكول OpenTSDB. يقبل المكون Insert ، ويوزعها ويوزعها بين مكونات التخزين الحالية ، حيث يتم تخزين البيانات بالفعل. المكون Select ، بدوره ، يقبل استعلامات PromQL. يقوم بتنفيذ PromQL وكذلك واجهة برمجة تطبيقات الاستعلام Prometheus ، ويمكن استخدامه كبديل لـ Prometheus في Grafana أو عملاء API Prometheus الآخرين. حدد يقبل طلب promql ، ويقوم بتوزيعه ، وقراءة البيانات اللازمة لتنفيذ هذا الطلب من عقدة التخزين ، ومعالجة هذه البيانات وإرجاع استجابة.
قارن صعوبة تثبيت Thanos و VictoriaMetrics.
لنبدأ مع Thanos. قبل أن تبدأ العمل مع Thanos ، تحتاج إلى إنشاء دلو في "Object Object" ، مثل S3 أو GCS ، حتى يتمكن Thanos Sidecar من كتابة البيانات هناك.
ثم لكل بروميثيوس تحتاج إلى تثبيت Thanos Sidecar. قبل ذلك ، عليك أن تتذكر تعطيل ضغط البيانات في Prometheus. يضغط ضغط البيانات بشكل دوري البيانات في التخزين المحلي لـ Prometheus من أجل تقليل استهلاك الموارد.
عند تثبيت Thanos Sidecar على Prometheus ، يجب عليك تعطيل ضغط البيانات هذا ، لأن Thanos Sidecar لا يمكنه العمل بشكل طبيعي عند تمكين ضغط البيانات. هذا يعني أن Prometheus الخاص بك يبدأ في حفظ البيانات في كتل من ساعتين ويتوقف عن دمج هذه الكتل في كتل أكبر. وفقًا لذلك ، إذا قمت بتقديم طلبات أطول من الساعتين الأخيرتين ، فلن تعمل بكفاءة قدر الإمكان إذا تم تمكين ضغط البيانات.
لذلك ، يوصي Thanos بتقليل وقت الاحتفاظ بالبيانات في التخزين المحلي إلى 6-8 ساعات من أجل تقليل هذا الحمل لعدد كبير من القطع الصغيرة.
بعد تثبيت Thanos Sidecar ، يجب عليك تثبيت مكونين لكل دلو تخزين كائن. هذه هي Thanos Compactor و Thanos Store Gateway.
بعد ذلك ، تحتاج إلى تثبيت Thanos Query وتهيئته بحيث يعرف كيفية الاتصال بكل بوابة متجر Thanos الموجودة لديك ، ويعرف أيضًا كيفية الاتصال بجميع Thanos Sidecar.
قد تكون هناك مشكلة صغيرة.
تحتاج إلى تكوين اتصال موثوق وآمن من Thanos Query إلى هذه المكونات. وإذا كان موقع Prometheus الخاص بك موجودًا في مراكز بيانات مختلفة أو في أجهزة VPC مختلفة ، فسيتم حظر الاتصالات الخارجية بها. لكن لكي يعمل Thanos Query ، تحتاج إلى تكوين الاتصال هناك بطريقة ما ، وعليك التوصل إلى طريقة ما.
إذا كان لديك الكثير من مراكز البيانات هذه ، فستقل بالتالي موثوقية النظام بأكمله. نظرًا لأن Thanos Query يجب أن يظل متصلاً باستمرار بجميع Thanos Sidecar الموجود في مراكز بيانات مختلفة. مع كل طلب وارد ، سيقوم بإعادة توجيه الطلبات إلى Thanos Sidecar. إذا تمت مقاطعة الاتصال ، فستتلقى إما مجموعة غير كاملة من البيانات ، أو ستحصل على إجابة "الكتلة لا تعمل".
في VictoriaMetrics ، الأمور أسهل قليلاً. بالنسبة لإصدار Single-node ، يكفي تشغيل ثنائي واحد فقط ويعمل كل شيء.
في نسخة مجمعة ، يكفي تشغيل جميع الأنواع الثلاثة المذكورة أعلاه من المكونات بأي كمية تحتاجها ، أو استخدام مخطط الدفة لأتمتة إطلاق المكونات في Kubernetes. ما زلنا نخطط لإنشاء مشغل Kubernetes. مخطط هيلم لا يغطي بعض الحالات ، ويسمح لك بإطلاق النار على ساقك. على سبيل المثال ، يسمح لك بتقليل عدد عقدة التخزين ، مما يؤدي إلى فقد البيانات.
بعد تشغيل إصدار ثنائي أو نظام مجموعة ، تحتاج فقط إلى إضافة إعداد عنوان url للكتابة عن بعد إلى تكوين Prometheus بحيث يبدأ في كتابة البيانات بالتوازي مع التخزين المحلي والتخزين عن بُعد. كما لاحظت ، يجب أن يعمل هذا التكوين بشكل أكثر موثوقية مقارنةً بتكوين Thanos. لا نحتاج إلى إبقاء VictoriaMetrics على اتصال بجميع Prometheus ، لأن Prometheus أنفسهم يتصلون بـ VictoriaMetrics ونقل البيانات.
النظر في مرافقة Thanos و VictoriaMetrics.
يحتاج Thanos إلى مراقبة Sidecar بحيث لا يتوقف عن تحميل البيانات في Object Object. قد يوقفون تحميل هذه البيانات بسبب أخطاء التحميل ، على سبيل المثال ، اتصال الشبكة الخاص بك مع Object Storage غير متصل مؤقتًا ، أو أن Object Object غير متاح مؤقتًا. Thanos Sidecar في هذه اللحظة سوف تلاحظ ذلك ، تبلغ عن خطأ ، وقد تسقط ثم تتوقف عن العمل. إذا لم تراقبها ، فلن يتم بعد ذلك نقل بياناتك إلى تخزين الكائنات. إذا مر وقت الاستبقاء (6-8 ساعات موصى به) ، فستفقد البيانات التي لم تقع في "تخزين الكائنات".
ضاغطات Thanos قد تتوقف عن العمل بسبب السباق مع Sidecar . يأخذ الضاغطون البيانات من تخزين الكائنات ويدمجونها في مجموعات أكبر من البيانات. نظرًا لأن الضواغط غير متزامنة مع Sidecar ، فقد يحدث هذا: لم يتم إنهاء Sidecar من كتابة الكتلة ، يقرر Compactor تسجيل هذه الكتلة بالكامل. الضاغط يبدأ في قراءته. لا يقرأ الكتلة بالكامل ويتوقف عن العمل. انظر التفاصيل هنا .
قد توفر بوابة المتجر بيانات غير متسقة بسبب السباق بين الضاغط و Sidecar. هذا هو نفس الشيء ، لأن بوابة المتجر ليست في أي حال من الأحوال متزامنة مع Compactor's و Sidecar. وفقًا لذلك ، قد تحدث حالة السباق عندما لا ترى بوابة المتجر جزءًا من البيانات أو ترى بيانات زائدة.
يتخلف مكون Query في Thanos عن نتائج جزئية في حالة عدم توفر بعض Sidecar أو Gateway Store في الوقت الحالي. ستتلقى جزءًا من البيانات ، ولن تعرف حتى أنه لم يتم استلام جميع البيانات. أنه يعمل مثل هذا افتراضيا. في موقف مشابه ، تُرجع VictoriaMetrics البيانات المحددة بأنها جزئية.
بخلاف Thanos ، نادرًا ما تفقد VictoriaMetrics البيانات. حتى إذا تمت مقاطعة الاتصال من Prometheus إلى VictoriaMetrics ، فإن هذه ليست مشكلة ، لأن Prometheus لا يزال يسجل البيانات الجديدة الواردة في سجل Write Ahead ، الذي يبلغ حجمه ساعتين. إذا قمت بإعادة الاتصال بـ VictoriaMetrics خلال ساعتين ، فلن تضيع البيانات. يمكن لـ Prometheus إضافة بيانات بعد إعادة الاتصال بـ VictoriaMetrics .
بخلاف Thanos ، الذي يكتب البيانات فقط لتخزين الكائنات بعد ساعتين ، يقوم Prometheus تلقائيًا بعمل نسخ متماثل للبيانات عبر بروتوكول الكتابة عن بُعد للتخزين البعيد ، مثل VictoriaMetrics. أنت لا تخاف من فقدان التخزين المحلي في بروميثيوس. إذا فقد التخزين المحلي فجأة ، في أسوأ الأحوال ، ستفقد الثواني الأخيرة من البيانات التي لم يكن لديها وقت للكتابة إلى وحدة التخزين عن بُعد.
تقوم Kubernetes بإدارة المجموعة تلقائيًا ، على عكس Thanos. يصعب وضع جميع مكونات Thanos في مجموعة Kubernetes واحدة ، على عكس مكونات الكتلة VictoriaMetrics.
يحتوي VictoriaMetrics على ترقية بسيطة جدًا إلى الإصدار الجديد. مجرد إيقاف VictoriaMetrics ، تحديث الثنائيات وتشغيلها. عند التوقف من خلال إشارة SIGINT ، تقوم جميع ثنائيات VictoriaMetrics بإغلاق رشيق. يقومون بحفظ البيانات الضرورية بشكل صحيح ، ويقومون بإغلاق الاتصالات الواردة بشكل صحيح حتى لا تفقد أي شيء. لذلك ، لن تفقد أي شيء عند الترقية.
VictoriaMetrics لديه طريقة بسيطة للغاية لتوسيع الكتلة. فقط أضف المكونات الضرورية واستمر في العمل.
حول المزالق في Thanos وفيكتوريا Metrics.
Thanos لديه المزالق التالية. يجب على بروميثيوس تخزين البيانات خلال الساعتين الأخيرتين. في حالة ضياعها ، فستفقدها تمامًا ، حيث لم تتمكن بعد من التسجيل في تخزين الكائنات ، مثل S3.
قد يتطلب مكون مخزن البوابة ومكون الضاغط مساحة كبيرة من الذاكرة للعمل مع "تخزين الكائنات" الكبير إذا تم تخزين العديد من الملفات الصغيرة هناك. كلما زاد عدد الملفات وحجمها ، زاد عدد بوابة المتجر والذاكرة الضاغطة لتخزين المعلومات الوصفية. لدى Thanos الكثير من المشكلات حول Store Gateway و الضاغطة التي تسقط مع متوسط البيانات المسجلة .
توصف Thanos أنه يمكن أن تتوسع إلى أجل غير مسمى بمقدار كمية Prometheus الخاصة بك. هذا في الواقع ليس صحيحا. نظرًا لأن جميع الطلبات تمر عبر مكون Query ، الذي يجب أن يقوم في وقت واحد باستطلاع جميع مكونات بوابة المتجر وجميع مكونات Sidecar ، فقم بسحب البيانات من هناك ثم تجهيزها مسبقًا. من الواضح أن سرعة الاستعلام محدودة بواسطة أبطأ رابط ضعيف ، أو أبطأ بوابة للمخزن ، أو أبطأ Sidecar.
قد يتم تحميل هذه المكونات بشكل غير متساو. على سبيل المثال ، لديك بروميثيوس يجمع ملايين المقاييس في الثانية. وهناك بروميثيوس ، الذي يجمع آلاف المقاييس في الثانية. تقوم بروميثيوس ، التي تجمع ملايين المقاييس في الثانية ، بتحميل الخادم الذي يتم تشغيله على أكثر من ذلك بكثير. تبعا لذلك ، Sidecar أبطأ هناك. بشكل عام ، كل شيء يعمل ببطء هناك. وسيقوم مكون Query بسحب البيانات ببطء شديد من هناك. وفقًا لذلك ، سيتم تقييد أداء المجموعة بالكامل بواسطة Sidecar البطيء.
بشكل افتراضي ، ترجع Thanos بيانات جزئية في حالة عدم توفر بعض Sidecar وإما بوابة المتجر. على سبيل المثال ، إذا كان لديك Sidecar منتشرة في جميع أنحاء العالم في مراكز بيانات مختلفة ، فإن احتمال قطع الاتصال وعدم توفر المكونات يزيد بشكل كبير. وفقًا لذلك ، في معظم الحالات ، ستتلقى بيانات جزئية دون معرفة ذلك.
VictoriaMetrics لديها أيضا المزالق. الحفرة الأولى هي خيار يحدد مقدار ذاكرة الوصول العشوائي المستخدمة في ذاكرة التخزين المؤقت VictoriaMetrics. بشكل افتراضي ، فإنه يساوي 60 ٪ من ذاكرة الوصول العشوائي على الجهاز حيث يتم تشغيل VictoriaMetrics ، أو 60 ٪ من ذاكرة الوصول العشوائي قرنة VictoriaMetrics في Kubernetes.
إذا قمت بتغيير هذه القيمة بشكل غير صحيح ، فيمكنك تدمير أداء VictoriaMetrics. على سبيل المثال ، إذا قمت بتعيين القيمة منخفضة جدًا ، فقد لا يتم احتواء البيانات في ذاكرة التخزين المؤقت لـ VictoriaMetrics. ولهذا السبب ، سيتعين عليها القيام بعمل إضافي وتحميل المعالج مع القرص. إذا جعلت هذا الخيار كبيرًا جدًا ، فستزيد أولاً من احتمال تعطل VictoriaMetrics بسبب خطأ الذاكرة ، وثانياً ، سيؤدي ذلك إلى بقاء ذاكرة تشغيلية قليلة جدًا في نظام التشغيل الذاكرة لذاكرة التخزين المؤقت الملف. وتعتمد VictoriaMetrics على ذاكرة التخزين المؤقت للملفات للحصول على الأداء. إذا لم يكن ذلك كافيًا ، فيمكن أن يزيد الحمل على القرص بشكل كبير. لذلك ، نصيحة: لا تقم بتغيير المعلمة إلا عند الضرورة القصوى.
الخيار الثاني. هذا هو retentionPeriod - الفترة التي يتم ضبطها على شهر واحد افتراضيًا. هذا هو الوقت الذي تقوم فيه VictoriaMetrics بتخزين البيانات. بعد هذه الفترة ، تحذف VictoriaMetrics البيانات.
يقوم العديد منهم بتشغيل VictoriaMetrics بدون هذه المعلمة ، ويقومون بتسجيل البيانات لمدة شهر. ثم يسألون: لماذا اختفت البيانات للشهر السابق؟ لأن retentionPeriod هو شهر افتراضيًا. لذلك ، تحتاج إلى معرفة وتعيين retentionPeriod الصحيح.
دعنا نسير عبر الفرص الفريدة.
لدى Thanos ميزة مثل الاختزال: فواصل زمنية مدتها 5 دقائق وساعة ، والتي لا تعمل غالبًا بشكل صحيح . إذا كنت غوغل نظرت إلى مشكلتهم على github ، فهناك الكثير من المشكلات المتعلقة بهذا الاختزال ، أو أنها لا تعمل في بعض الأحيان بشكل صحيح ، أو أنها لا تعمل كما يتوقع المستخدمون.
Thanos لديه إلغاء البيانات المكررة لأزواج Prometheus HA. عندما يقوم اثنان من بروميثيوسا بجمع نفس المقاييس من نفس الهدف ويضعها ثانو في تخزين الكائنات. Thanos , VictoriaMetrics.
Thanos alert , Thanos. production .
Thanos , Thanos Prometheus — . Thanos Prometheus . Thanos Prometheus .
VictoriaMetrics — MetricsQL. VictoriaMetrics PromQL, big monitoring metup.
VictoriaMetrics . VictoriaMetrics Prometheus, Influx, OpenTSDB Graphite.
VictoriaMetrics Thanos Prometheus.
, 2-5 Prometheus Thanos.
VictoriaMetrics — .
.
Thanos , object storage, .
object storage, ($10 ). object storage, , AWS — . , $10 $230 1. , Thanos .
Thanos Compact, Store Gateway, Query , , .
VictoriaMetrics . GCE HDD , $40 1. VictoriaMetrics HDD , SSD, . VictoriaMetrics HDD.
يحتاج VictoriaMetrics إلى خوادم للمكونات: إما بمفرده أو للمكونات العنقودية ، والتي ، على عكس مكونات Thanos ، تتطلب وحدة المعالجة المركزية وذاكرة RAM أقل بكثير - ستكون أرخص وفقًا لذلك.
أمثلة على التنفيذ.
مثال تنفيذ Thanos هو Gitlab. Gitlab مدعوم بالكامل من قبل Thanos. ولكن ليس هناك سلس جدا. إذا نظرت إلى مشكلاتهم ، يمكنك أن ترى أن لديهم باستمرار نوعًا من المشاكل التشغيلية مع Thanos : لا توجد ذاكرة كافية لمكونات Store Gateway أو Query. لديهم باستمرار لزيادة كمية الذاكرة.
ولهذا السبب ، تزداد تكاليف حل هذه المشكلات.
التنفيذ الثاني ، الذي قد يكون أكثر نجاحًا ، هو شركة غير محتملة ، والتي بدأت تطوير Thanos. نشروا مصدر Thanos. غير محتمل هي شركة تقوم بتطوير محركات الألعاب.
أمثلة عامة من تطبيق VictoriaMetrics هي:
- wix.com بناء الموقع
- أديداس تقدم VictoriaMetrics بل قدمت عرضًا تقديميًا في أحدث PromCon 2019
- TrafficStars - شبكة الإعلانات
- Seznam.cz هو محرك بحث تشيكي شهير.
ثم انتقل إلى اسم الشركة ، والذي لا يمكنني تسميته الآن. لم يتفقوا.
- مطور لعبة رئيسي واحد. أكبر منهم غير محتمل.
- مطور برمجيات بيانية رئيسي.
- بنك روسي كبير.
- الشركة الأوروبية لصناعة توربينات الرياح التي نجحت في اختبار VictoriaMetrics. تطبق هذه الشركة المصنعة VictoriaMetrics لمراقبة البيانات من توربينات الرياح بسرعة 50 عينة في الثانية لكل جهاز استشعار. كل توربينات الرياح لديها عدة مئات من أجهزة الاستشعار. لديهم عدة مئات من توربينات الرياح.
- شركات الطيران الروسية التي ترغب في تقديم VictoriaMetrics ، ولكن لا يزال لا يمكن. نحن في مرحلة العقد معهم.
الاستنتاجات.
VictoriaMetrics و Thanos يحلان مشكلات مماثلة ، لكن بطرق مختلفة:
- عرض الاستعلام العالمي
- التحجيم الأفقي
- الاحتفاظ التعسفي
شكرا لك
نحن في انتظارك على قناة البرقية لدينا.
