VictoriaMetrics عبارة عن نظام DBMS سريع وقابل للتطوير لتخزين البيانات ومعالجتها في شكل سلسلة زمنية (يشكل السجل وقتًا ومجموعة من القيم المقابلة لهذا الوقت ، على سبيل المثال ، يتم الحصول عليها من خلال الاستقصاء الدوري لحالة المستشعرات أو جمع المقاييس).
اسمي بافل كولوبايف. DevOps و SRE و LeroyMerlin ، كل شيء يشبه الكود - الأمر كله يتعلق بنا: عني وعن موظفي LeroyMerlin الآخرين.
هناك سحابة تعتمد على OpenStack. هناك ارتباط صغير بالرادار التقني.
إنه مبني على أساس Kubernetes iron ، وكذلك على جميع الخدمات ذات الصلة بـ OpenStack والتسجيل.
هذا هو المخطط الذي كان لدينا في التطوير. عندما طورنا كل هذا ، كان لدينا مشغل بروميثيوس ، الذي يخزن البيانات داخل مجموعة K8s نفسها. يجد تلقائيًا ما يحتاج إلى حكه ويضعه تحت قدميه ، ويتحدث تقريبًا.
سنحتاج إلى نقل جميع البيانات خارج مجموعة Kubernetes ، لأنه إذا حدث شيء ما ، فعلينا أن نفهم ماذا وأين.
الحل الأول هو أننا نستخدم الاتحاد عندما يكون لدينا طرف ثالث بروميثيوس عندما نذهب إلى مجموعة Kubernetes من خلال آلية الاتحاد.
لكن هناك بعض المشاكل البسيطة هنا. في حالتنا ، بدأت المشاكل عندما كان لدينا 250 مقياس ، وعندما أصبح 000 مقياس ، أدركنا أنه لا يمكننا العمل بهذه الطريقة. لقد قمنا بزيادة مدة scrape_timeout إلى 400 ثانية.
لماذا كان علينا أن نفعل هذا؟ يبدأ بروميثيوس في حساب المهلة من بداية لحظة الالتقاط. لا يهم أن البيانات لا تزال تتدفق. إذا لم يتم دمج البيانات خلال هذه الفترة الزمنية المحددة ولم يتم إغلاق الجلسة عبر http ، فسيتم اعتبار أن الجلسة قد فشلت وأن البيانات لا تدخل إلى Prometheus نفسها.
يعرف الجميع الرسوم البيانية التي نحصل عليها عندما يكون جزء من البيانات مفقودًا. الرسومات ممزقة ولسنا سعداء بها.
الخيار التالي هو التجزئة بناءً على بروميثيوسين مختلفين من خلال آلية الاتحاد نفسها.
على سبيل المثال ، ما عليك سوى أخذها وتقسيمها بالاسم. يمكن استخدام هذا أيضًا ، لكننا قررنا المضي قدمًا.
سيتعين علينا الآن معالجة هذه القطع بطريقة ما. يمكنك أن تأخذ برومكسي ، الذي ينزل إلى منطقة الشظايا ، يضاعف البيانات. يعمل مع شريحتين كنقطة دخول واحدة. يمكن تنفيذ ذلك من خلال promxy ، لكنه معقد للغاية في الوقت الحالي.
الخيار الأول - نريد التخلي عن آلية الاتحاد لأنها بطيئة للغاية.
يقول مطورو بروميثيوس صراحة: "يا رفاق ، استخدموا TimescaleDB الأخرى ، لأننا لن ندعم التخزين طويل المدى للمقاييس." هذه ليست مهمتهم.
نكتب على قطعة من الورق ما زلنا بحاجة إلى تفريغها في الخارج ، حتى لا نخزن كل شيء في مكان واحد.
العيب الثاني هو استهلاك الذاكرة. نعم ، أفهم أن الكثيرين سيقولون أنه في عام 2020 ، فإن بضع غيغابايت من الذاكرة تستحق بنسًا واحدًا ، ولكن مع ذلك.
الآن لدينا بيئة مطورة وبيئة إنتاج. في dev ، يبلغ هذا حوالي 9 غيغابايت لكل 350 مقياس. في المنتج ، هذا هو 000 غيغابايت مع 14،780 مقياس صغير. في الوقت نفسه ، لدينا وقت احتفاظ لمدة 000 دقيقة فقط. هذا سيء. والآن سأشرح السبب.
نجري عملية حسابية ، أي بمليون ونصف مقياس ، ونحن بالفعل قريبون منهم ، في مرحلة التصميم نحصل على 35-37 جيجا بايت من الذاكرة. ولكن بالفعل بمقدار 4 ملايين مقياس ، هناك حاجة بالفعل لحوالي 90 جيجا بايت من الذاكرة. أي أنه تم حسابه وفقًا للصيغة التي قدمها مطورو بروميثيوس. نظرنا إلى الارتباط وأدركنا أننا لا نريد دفع مليونين مقابل خادم للمراقبة فقط.
لن نزيد عدد الأجهزة فحسب ، بل نراقب أيضًا الأجهزة الافتراضية نفسها. لذلك ، كلما زاد عدد الأجهزة الافتراضية ، زادت المقاييس من مختلف الأنواع ، وما إلى ذلك. سيكون لدينا نمو خاص في مجموعتنا من حيث المقاييس.
مع مساحة القرص ، كل شيء ليس حزينًا هنا ، لكني أرغب في تحسينه. تلقينا إجمالي 15 جيجا بايت في 120 يومًا ، منها 100 بيانات مضغوطة ، و 20 بيانات غير مضغوطة ، لكنك تريد دائمًا أقل.
وفقًا لذلك ، نكتب نقطة أخرى - هذا استهلاك كبير للموارد التي ما زلنا نريد توفيرها ، لأننا لا نريد أن تستهلك مجموعة المراقبة الخاصة بنا موارد أكثر من المجموعة التي تدير OpenStack.
هناك عيب آخر لبروميثيوس ، والذي حددناه لأنفسنا ، هذا على الأقل نوع من قيود الذاكرة. مع بروميثيوس ، كل شيء أسوأ بكثير هنا ، لأنه ليس لديه مثل هذه التقلبات على الإطلاق. استخدام حد عامل الإرساء ليس خيارًا أيضًا. إذا انخفض سلاح الجو الملكي البريطاني فجأة وكان هناك 20-30 غيغابايت ، فسيستغرق ارتفاعه وقتًا طويلاً جدًا.
هذا سبب آخر لعدم ملاءمة بروميثيوس لنا ، أي أننا لا نستطيع الحد من استهلاك الذاكرة.
سيكون من الممكن التوصل إلى مثل هذا المخطط. نحن بحاجة إلى هذا المخطط من أجل تنظيم مجموعة HA. نريد أن تكون مقاييسنا متاحة في أي وقت وفي أي مكان ، حتى إذا تعطل الخادم الذي يخزن هذه المقاييس. وبالتالي علينا بناء مثل هذا المخطط.
يقول هذا المخطط أنه سيكون لدينا ازدواجية في القطع ، وبالتالي ازدواجية تكاليف الموارد المستهلكة. يمكن تحجيمها أفقيًا تقريبًا ، ولكن مع ذلك سيكون استهلاك الموارد جهنميًا.
العيوب بالترتيب ، بالشكل الذي كتبناه لأنفسنا:
- يتطلب تحميل المقاييس إلى الخارج.
- ارتفاع استهلاك الموارد.
- لا يمكنك الحد من استهلاك الذاكرة.
- التنفيذ المعقد والمكثف للموارد HA.
لأنفسنا ، قررنا أننا نبتعد عن بروميثيوس كمستودع.
لقد حددنا متطلبات إضافية نحتاجها لأنفسنا. هذا:
- هذا هو دعم promql ، لأنه تمت كتابة الكثير بالفعل لبروميثيوس: الاستعلامات والتنبيهات.
- ومن ثم لدينا جرافانا ، والتي تمت كتابتها بالفعل بنفس الطريقة تحت بروميثيوس كخلفية. لا أريد إعادة كتابة لوحات المعلومات.
- نريد بناء بنية HA عادية.
- نريد تقليل استهلاك أي موارد.
- هناك فارق بسيط آخر. لا يمكننا استخدام أنواع مختلفة من الأنظمة السحابية لجمع المقاييس. لا نعرف ما الذي سينتقل إلى هذه المقاييس في الوقت الحالي. وبما أن أي شيء يمكن أن يطير إلى هناك ، علينا أن نقتصر على التنسيب المحلي.
كان الاختيار صغيرًا. لقد جمعنا كل شيء لدينا خبرة فيه. ألقينا نظرة على صفحة بروميثيوس في قسم التكامل ، قرأنا مجموعة من المقالات ، نظرنا إلى ما هو متاح بشكل عام. وبالنسبة لأنفسنا ، اخترنا VictoriaMetrics كبديل لبروميثيوس.
لماذا؟ لأن:
- قادرة على برومكل.
- هناك بنية معيارية.
- لا يتطلب أي تغييرات على جرافانا.
- والأهم من ذلك ، أننا سنوفر على الأرجح تخزينًا للمقاييس داخل شركتنا كخدمة ، لذلك نحن نتطلع مقدمًا نحو أنواع مختلفة من القيود حتى يتمكن المستخدمون من استخدام جميع موارد الكتلة بطريقة محدودة ، لأن هناك فرصة أنه سيكون متعدد الشركات.
نجري المقارنة الأولى. نأخذ نفس بروميثيوس داخل الكتلة ، يذهب إليها بروميثيوس الخارجي. نضيف عبر remoteWrite VictoriaMetrics.
سأقوم بالحجز على الفور لأننا اكتشفنا زيادة طفيفة في استهلاك وحدة المعالجة المركزية من VictoriaMetrics. يوضح موقع VictoriaMetrics wiki أي المعلمات هي الأنسب. فحصناها. لقد قللوا بشكل جيد من استهلاك وحدة المعالجة المركزية.
في حالتنا ، لم يزد استهلاك ذاكرة بروميثيوس ، الموجود في مجموعة Kubernetes ، بشكل ملحوظ.
نحن نقارن بين مصدري بيانات من نفس البيانات. في بروميثيوس ، نرى نفس البيانات المفقودة. كل شيء جيد في VictoriaMetrics.
نتائج الاختبارات مع مساحة القرص. نحن في Prometheus حصلنا على إجمالي 120 جيجا بايت. في VictoriaMetrics ، نحصل بالفعل على 4 جيجا بايت في اليوم. هناك آلية مختلفة قليلاً عما اعتدت رؤيته في بروميثيوس. أي أن البيانات مضغوطة جيدًا بالفعل ليوم واحد لمدة نصف ساعة. لقد تم جنيها جيدًا بالفعل في يوم واحد ، خلال نصف ساعة ، على الرغم من حقيقة أنه سيتم دمج البيانات لاحقًا. نتيجة لذلك ، قمنا بحفظ مساحة القرص.
نحن نوفر أيضًا على استهلاك موارد الذاكرة. في وقت الاختبارات ، كان لدينا بروميثيوس منتشرًا على جهاز افتراضي - 8 نوى ، 24 جيجا بايت. بروميثيوس يأكل كل شيء تقريبًا. لقد سقط على OOM Killer. في الوقت نفسه ، تم ضخ 900 مقياس نشط فقط فيه. هذا هو حوالي 000-25 مقياس في الثانية.
كانت VictoriaMetrics تعمل على جهاز افتراضي ثنائي النواة بسعة 8 غيغابايت من ذاكرة الوصول العشوائي. تمكنا من جعل VictoriaMetrics تعمل بشكل جيد من خلال تعديل بعض الأشياء على جهاز سعة 8 جيجابايت. نتيجة لذلك ، احتفظنا في حدود 7 غيغابايت. في الوقت نفسه ، حصلنا على سرعة توصيل المحتوى ، أي المقاييس ، أعلى من سرعة بروميثيوس.
وحدة المعالجة المركزية أفضل بكثير من بروميثيوس. يستهلك بروميثيوس هنا 2,5 نواة ، وتستهلك VictoriaMetrics 0,25 نواة فقط. في البداية - 0,5 النوى. عندما يندمج ، يصل إلى نواة واحدة ، لكن هذا نادر للغاية.
في حالتنا ، وقع الاختيار على VictoriaMetrics لأسباب واضحة ، أردنا توفير المال والادخار.
نقوم بشطب نقطتين مباشرة من الخفافيش - هذا هو تفريغ المقاييس واستهلاك كبير للموارد. ويبقى لنا أن نقرر نقطتين ما زلنا نتركه لأنفسنا.
هنا سأقوم بالحجز على الفور ، فنحن نعتبر VictoriaMetrics مستودعًا للمقاييس. ولكن نظرًا لأننا على الأرجح سنوفر VictoriaMetrics كمخزن لجميع Leroy ، فنحن بحاجة إلى تقييد أولئك الذين سيستخدمون هذه المجموعة حتى لا يضعوها لنا.
هناك معلمة رائعة تسمح لك بالحد من الوقت وكمية البيانات ووقت التنفيذ.
وهناك أيضًا خيار ممتاز يسمح لك بالحد من استهلاك الذاكرة ، وبالتالي يمكننا إيجاد التوازن الذي يسمح لنا بالحصول على السرعة العادية والاستهلاك الكافي للموارد.
ناقص نقطة أخرى ، أي أننا شطبنا النقطة - لا يمكنك الحد من استهلاك الذاكرة.
في التكرارات الأولى ، اختبرنا عقدة VictoriaMetrics المفردة. بعد ذلك ننتقل إلى إصدار VictoriaMetrics Cluster.
هنا لدينا مطلق الحرية في موضوع فصل الخدمات المختلفة في VictoriaMetrics ، اعتمادًا على ما ستدور عليه والموارد التي ستستهلكها. هذا حل مرن ومريح للغاية. لقد استخدمناه بأنفسنا.
المكونات الرئيسية لـ VictoriaMetrics Cluster Version هي vmstsorage. قد يكون هناك رقم N. في حالتنا ، هناك 2 منهم.
وهناك vminsert. هذا خادم وكيل يسمح لنا بما يلي: ترتيب التجزئة بين جميع المخازن التي أخبرناه عنها ، ويسمح بنسخة متماثلة أخرى ، أي سيكون لديك كل من التجزئة والنسخة المتماثلة.
يدعم Vminsert بروتوكولات OpenTSDB و Graphite و InfluxDB و remoteWrite من بروميثيوس.
هناك أيضا vmselect. وتتمثل مهمتها الرئيسية في الانتقال إلى vmstorage ، والحصول على البيانات منها ، وإزالة هذه البيانات وإعطائها للعميل.
هناك شيء رائع مثل vmagent. نحن حقا نحبها. يتيح لك التهيئة تمامًا مثل Prometheus وما زلت تفعل كل شيء تمامًا مثل Prometheus. أي أنه يجمع المقاييس من الكيانات والخدمات المختلفة ويرسلها إلى vminsert. ثم كل شيء يعتمد عليك.
خدمة رائعة أخرى هي vmalert ، والتي تتيح لك استخدام VictoriaMetrics كخلفية ، وتلقي البيانات المعالجة من vminsert وإرسال البيانات المعالجة إلى vmselect. يقوم بمعالجة التنبيهات نفسها ، بالإضافة إلى القواعد. في حالة التنبيهات ، نحصل على تنبيه من خلال alertmanager.
يوجد مكون wmauth. من المحتمل أن نستخدمه ، وربما لا (لم نقرر هذا بعد) كنظام ترخيص لإصدارات المجموعات متعددة الاستئجار. وهو يدعم remoteWrite لبروميثيوس ويمكنه الاعتماد على أساس عنوان url ، أو بالأحرى الجزء الثاني منه ، حيث يمكنك الكتابة أو لا تستطيع الكتابة.
يوجد أيضًا vmbackup و vmrestore. هذا ، في الواقع ، هو استعادة جميع البيانات ونسخها احتياطيًا. قادرة على S3 ، GCS ، ملف.
تم إجراء أول تكرار لعنقودنا أثناء الحجر الصحي. في ذلك الوقت ، لم يكن هناك نسخة طبق الأصل ، لذلك تألف التكرار لدينا من مجموعتين مختلفتين ومستقلتين ، تلقينا فيهما البيانات عبر remoteWrite.
هنا سأحجز أنه عندما قمنا بالتبديل من VictoriaMetrics Single Node إلى VictoriaMetrics Cluster Version ، ظللنا في نفس الموارد المستهلكة ، أي أن العنصر الرئيسي هو الذاكرة. بهذه الطريقة تقريبًا تم توزيع بياناتنا ، أي استهلاك الموارد.
تمت إضافة نسخة طبق الأصل هنا بالفعل. لقد جمعنا كل هذا في مجموعة واحدة كبيرة نسبيًا. يتم تجزئة جميع البيانات وتكرارها.
تحتوي المجموعة بأكملها على نقاط دخول N ، أي يمكن لـ Prometheus إضافة البيانات عبر HAPROXY. هنا نقطة دخولنا. ومن خلال نقطة الدخول هذه ، يمكنك تسجيل الدخول باستخدام Grafana.
في حالتنا ، HAPROXY هو المنفذ الوحيد الذي يختاره الوكلاء ويدرجونه والخدمات الأخرى في هذه المجموعة. في حالتنا ، كان من المستحيل إنشاء عنوان واحد ، كان علينا إنشاء عدة نقاط دخول ، لأن الأجهزة الافتراضية نفسها ، التي تعمل عليها مجموعة VictoriaMetrics ، تقع في مناطق مختلفة من نفس مزود السحابة ، أي ليس داخل السحابة الخاصة بنا ، ولكن بالخارج.
لدينا تنبيه. نحن نستخدمه. نحن نستخدم تنبيه مدير من بروميثيوس. نحن نستخدم Opsgenie و Telegram كقناة توصيل تنبيه. في Telegram ، يتدفقون من المطورين ، ربما شيئًا من المنتج ، لكنهم أشبه بشيء إحصائي يحتاجه المهندسون. و Opsgenie أمر بالغ الأهمية. هذه هي المكالمات ، إدارة الحوادث.
السؤال القديم: "من يراقب المراقبة؟". في حالتنا ، تراقب المراقبة المراقبة نفسها ، لأننا نستخدم vmagent على كل عقدة. ونظرًا لوجود العقد الخاصة بنا في مراكز بيانات مختلفة لنفس المزود ، فلكل مركز بيانات قناة خاصة به ، وهي مستقلة ، وحتى إذا جاء دماغ منقسم ، فسوف نستمر في تلقي التنبيهات. نعم ، سيكون هناك المزيد منها ، ولكن من الأفضل تلقي تنبيهات أكثر من عدم تلقي أي تنبيهات.
ننهي قائمتنا مع تنفيذ HA.
علاوة على ذلك ، أود أن أشير إلى تجربة التواصل مع مجتمع VictoriaMetrics. اتضح أنها إيجابية للغاية. الرجال يستجيبون. يحاولون الخوض في كل حالة يتم عرضها.
لقد أنشأت مشكلات على GitHub. تم حلها بسرعة كبيرة. هناك مشكلتان أخريان لم يتم إغلاقهما تمامًا ، لكن يمكنني بالفعل أن أرى من الكود أن العمل جارٍ في هذا الاتجاه.
كان الألم الرئيسي أثناء التكرار بالنسبة لي هو أنه إذا قمت بقطع العقدة ، فلن يتمكن vminsert خلال أول 30 ثانية من فهم عدم وجود خلفية. الآن قد تقرر بالفعل. وفي غضون ثانية أو ثانيتين ، يتم أخذ البيانات من جميع العقد المتبقية ، ويتوقف الطلب عن انتظار تلك العقدة المفقودة.
أردنا في وقت ما من VictoriaMetrics أن نكون مشغل VictoriaMetrics. انتظرناه. نحن الآن بصدد بناء ارتباط عبر مشغل VictoriaMetrics لأخذ جميع قواعد الحساب المسبق ، وما إلى ذلك. بروميثيوس ، لأننا نستخدم القواعد التي تأتي مع مشغل بروميثيوس بنشاط.
هناك اقتراحات لتحسين تنفيذ الكتلة. لقد أوجزتهم أعلاه.
وأريد أيضًا الاختزال. في حالتنا ، هناك حاجة إلى الاختزال حصريًا لعرض الاتجاهات. بشكل تقريبي ، يكفي مقياس واحد خلال النهار. هذه الاتجاهات مطلوبة لمدة عام أو ثلاث أو خمس أو عشر سنوات. وقيمة مترية واحدة كافية.
- لقد عرفنا الألم ، كما يعرفه بعض زملائنا ، أثناء استخدام بروميثيوس.
- اخترنا VictoriaMetrics لأنفسنا.
- إنه يتدرج بشكل جيد عموديًا وأفقيًا.
- يمكننا توزيع مكونات مختلفة على عدد مختلف من العقد في الكتلة ، وتحديدها من حيث الذاكرة ، وإضافة الذاكرة ، وما إلى ذلك.
سوف نستخدم VictoriaMetrics في المنزل ، لأننا أحببناها حقًا. إليكم ما حدث وما حدث.
زوجان من رموز qr لدردشة VictoriaMetrics ، وجهات الاتصال الخاصة بي ، ورادار LeroyMerlin الفني.
المصدر: www.habr.com