تخزين طويل الأجل لمقاييس بروميثيوس (أليكسي بالازتشينكو ، بيركونا)

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

حول هذا ، فك تشفير تقرير أليكسي Palazhchenko في RootConf 2018. في التقرير: Prometheus ، التخزين المحلي TSDB ، التخزين عن بعد ، Prometheus ، PromQL ، TSDB ، Clickhouse ، PromHouse ، InfluxDB قليلاً.

من يهتم ، من فضلك ، تحت القط.

أصدقاء! مرحبا بالجميع! اسمي أليكسي Palazhchenko. أنا أعمل في بيركونا. أود أن أخبركم عن التخزين طويل المدى للمقاييس في بروميثيوس.

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

من المهم أن نفهم أن هذه ليست ادارة العلاقات. ليس لدينا الإنتاج. يقع إنتاجنا مع عملائنا. للتجربة على ذلك ليست جيدة جدا. لدينا أقرب شيء يمكن أن يسمى الإنتاج - هذا هو https://pmmdemo.percona.com/ . في وقت التقرير ، كان لا بد من إيقاف pmmdemo.percona.com بسبب الناتج المحلي الإجمالي.

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

بعض الأشياء في بروميثيوس رائعة للغاية.

• لغة بروميثيوس للاستعلام هي في الحقيقة شيء رائع لا يوجد لديه مثيل في أي مكان.

  
  

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

  
  

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

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

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

إذا كنت في تقرير سابق في القاعة الرئيسية ، حيث كان هناك مقدمة جيدة في Prometheus ، فأنت تعلم أن التخزين المحلي عبارة عن مكتبة منفصلة تسمى TSDB. TSDB لا علاقة له مع OpenTSDB. TSDB عبارة عن حزمة Go منفصلة يمكنك استخدامها من برنامج Go. على مستوى مكتبة TSDB ، لا يوجد عميل أو خادم.

تم تحسين هذه المكتبة للعمل مع بيانات السلاسل الزمنية. على سبيل المثال ، يحتوي TSDB على ترميز دلتا ، والذي يسمح لك بتخزين ليس الأرقام نفسها ، ولكن التغييرات بين هذه الأرقام. هذا يسمح لك بتخزين 1 بايت بدلاً من 16 بايت. 1 بايت للوقت و 1 بايت للقيمة. أي أنك تخزن في المتوسط ​​1 أو 2 بايت على وجه التحديد بسبب هذا الضغط الجيد.

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

لا يوجد tsdb مضمن مختلط # 313 في TSDB. هناك مشكلة مفتوحة تم فيها مناقشة حول حقيقة أن هناك عمومًا مشروعات تقوم بروميثيوس بشيء وهناك اختزال هناك. حتى الآن ، الحل هو أن TSDB لن يضيف اختزال.

كيف نحصل على البيانات من TSDB؟ TSDB هي قاعدة بيانات على القرص. يمكنك العمل معه إذا كنت تكتب برنامج Go. ولكن إذا لم تكتب برنامجًا في Go ، فهناك واجهة برمجة تطبيقات JSON تتيح لك إجراء استعلامات استعلام. إذا كنت قد استخدمت Prometheus في أي وقت من الأوقات وقمت بإنشاء مخطط على الأقل ، فأنت تعرف واجهة برمجة تطبيقات Query القياسية ، حيث توجد معلمة استعلام يمكنك من خلالها تنفيذ أي استعلام PromQL ووقت اختياريًا. إذا لم يكن هناك وقت ، فسيتم أخذ الوقت الحالي.

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

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

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

واجهة برمجة التطبيقات الوصفية الثانية ، والتي تُرجعنا قيمة جميع التصنيفات. إذا كنا نريد أن نرى قائمة بجميع الوظائف ، فبدلاً من label_name ، نكتب الوظيفة ونحصل على هذه القائمة. ترجع واجهات برمجة التطبيقات هذه JSON إلينا.

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

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

كيف يمكن استخدام هذا؟

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

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

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

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

كيف يمكننا استخدام هذه المجموعة من هذه الأشياء لإجراء الاختزال والتخزين على المدى الطويل.

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

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

إذا كان لدينا Grafana وكان هناك العديد من Prometheus ، نحتاج إلى معرفة أي Prometheus لإرسال الطلب إليه. كيف نفعل هذا؟

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

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

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

نمر إلى التخزين البعيد. هل عمل أي شخص مع Remote Storage في بروميثيوس؟ قليل الأيدي. التخزين عن بُعد عبارة عن واجهة برمجة تطبيقات موجودة منذ فترة طويلة. الآن في الإصدار 2.2 التخزين عن بعد - تم وضع علامة على أنها تجريبية. علاوة على ذلك ، من المعروف أن واجهة برمجة تطبيقات التخزين البعيد ستتغير بالتأكيد.

التخزين عن بعد يسمح لك بالعمل فقط مع البيانات الخام. لا يوجد PromQL في الإدخال أو الإخراج. عندما تقرأ ، لا يمكنك استخدام القوة الكاملة لـ PromQL. يقوم بشكل أساسي بضخ جميع البيانات من Remote Storage التي تطابق الحالة. مزيد من PromQL يعمل بالفعل معهم. هذا له حمولة كبيرة جدا. تحتاج إلى ضخ الكثير من البيانات عبر الشبكة. لذلك ، في الإصدار 2.3 من بروميثيوس ، والذي لم يتم إصداره بعد ، لكن تم تأجيله بالفعل ، ستتم قراءة تلميح. سنتحدث عن هذا في وقت لاحق قليلا.

لا واجهة برمجة تطبيقات للبيانات الوصفية حتى الآن. لا يمكنك إنشاء واجهة برمجة التطبيقات التي ترجع جميع السلاسل الزمنية من التخزين البعيد. إذا قمت بتقديم طلب إلى API من Prometheus ، فلن يعمل في التخزين البعيد. سيعود لك السلسلة الزمنية الموجودة في قاعدة البيانات المحلية. إذا تم تعطيل قاعدة البيانات المحلية الخاصة بك ، فسوف يعيدك 0. والتي قد تكون غير متوقعة بعض الشيء. الآن يستخدم API هذا ProtoBuf وسيتم تغييره بالتأكيد إلى gRPC في المستقبل. لم يفعلوا ذلك بعد ، لأن gRPC يتطلب HTTP2. وفي الممارسة العملية لديهم مشاكل معه.

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

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

واجهة برمجة تطبيقات القراءة عن بُعد تبدو هكذا. إنه مجرد نطاق زمني من البداية إلى النهاية ومجموعة مطابقة.

المطابقة هي في الأساس مجموعة من أزواج الاسم والقيمة - تسمية عادية ونوع الحالة. في المقارنة ، هناك المساواة أو عدم المساواة أو التعبيرات العادية. هذا هو محدد السلسلة الزمنية المعتاد الذي تراه في PromQL. لا توجد ميزات هنا.

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

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

ما هو تكوين القراءة؟

أولاً ، يوجد مثل هذا التكوين required_matchers. هذا يسمح لك بإرسال طلب تخزين عن بعد يطابق التعبير. لقراءة البيانات المجمعة من "التخزين البعيد" ، يجب عليك استخدام استعلام يحتوي على نقطتين.

هناك خيار يسمح لك بقراءة أو عدم قراءة البيانات الحديثة من وحدة التخزين عن بُعد ، الموجودة في TSDB. عادة في التكوين القياسي ، يوجد TSDB محلي صغير مكتوب على القرص المحلي. انها تخزن هناك لعدة ساعات أو عدة أيام. تتم قراءة البيانات التي تستخدمها الآن ، والتي يتم استخدامها للتنبيهات ، والتي يتم استخدامها لإنشاء لوحة المعلومات ، فقط من TSDB المحلي. إنه سريع ، لكنه لا يسمح لنا بتخزين الكثير من البيانات.

سيتم قراءة البيانات التاريخية القديمة من وحدة التخزين عن بُعد. هذا يجعل من الواضح كيفية اتصال التخزين المحلي والتخزين عن بعد مع بعضهما البعض. لا يوجد إلغاء البيانات المكررة.

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

ومن المثير للاهتمام ، أن القراءة عن بُعد تم تنفيذها من قبل بروميثيوس منذ الإصدار 1.8. هذه هي الطريقة التي تسمح لك بقراءة بيانات Prometheus القديمة عند الترحيل إلى الإصدار 2.x. تنصح الطريقة الرسمية بتوصيله كقراءة عن بعد. سيتم طرح البيانات حسب الحاجة.

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

لماذا clickhouse؟

• لحلنا البحثي ، اخترنا ClickHouse ، لأننا نظرنا فيه لفترة طويلة. لدينا أشخاص يشاركون باستمرار في أداء قاعدة البيانات ، والتحقق باستمرار من قواعد البيانات الجديدة. تعمل شركتنا في قواعد البيانات مفتوحة المصدر.

  
  

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

  
  

• المدمج في النسخ المتماثل ، sharding.

  
  

• GraphiteMergeTree هو محرك خاص لتخزين بيانات الجرافيت. في البداية كان مهتمًا جدًا بنا.

  
  

تم تصميم المحرك من أجل مجموعة بيانات الجرافيت (ترقق وتجميع / حساب).

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

كنت أستعد في بداية الشهر للتقرير. يأتي شخص ما في محادثة برقية ويسأل - "Downsample بيانات GraphiteMergeTree"؟ أنا أكتب بالفعل لا. الوثائق تقول لا. لكن الشخص الآخر في الدردشة يرد "نعم ، تحتاج إلى تحسين الاتصال". تشغيل ، تحقق - نعم الحقيقة. الوثائق هي في الأساس خطأ. ثم قرأت شفرة المصدر ، والتحقق ، اتضح أن هناك الأمثل ، وتحسين النهائي. تم إنشاء Optify final في الأصل خصيصًا لـ GraphiteMergeTree. في الواقع الاختزال يفعل. ولكن يجب أن يطلق عليه بيديه.

يحتوي GraphiteMergeTree على نموذج بيانات مختلف. ليس لديه تسميات. كتابة كل ذلك بفعالية باسم المقاييس لا يعمل بشكل جيد للغاية.

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

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

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

24 بايت هو نسخة مبسطة. في الواقع ، يضغط جيدا. في الواقع يستخدم مساحة أقل. في أحدث اختباراتنا ، تكون نسبة الضغط حوالي 1 إلى 42.

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

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

كيف نفعل الاختزال؟ نخلق جدول مؤقت. انسخ الإدخال في بيانات محددة منه باستخدام الوظائف الصحيحة.

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

سيكون ClickHouse تحديث / حذف. حذف بالفعل حصلت على الإصدار الأول. إذا نجح التحديث / الحذف ، فيمكن تبسيط نظام بيانات الاختزال.

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

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

هناك OpenTSDB والجرافيت ، وهو للكتابة فقط. المحول القياسي من بروميثيوس لا يعمل حقًا.

هناك CrateDB. هناك TimescaleDB الذي شوكة PostgreSQL لقواعد بيانات السلاسل الزمنية. يقولون أن هذا يعمل بشكل جيد ، لكننا نحن أنفسنا لم نجربه.

هناك Cortex ، والذي كان يعرف أيضًا باسم مشروع فرانكشتاين. هذا يصفه جيدا. هذا هو الرجال الذين يحاولون اتخاذ قرار بناءً على اتحاد بروميثيوس. يقومون بتخزين البيانات في S3.

هناك ثانوس.

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

باستخدام نموذج السحب لا يكتب الكثير من البيانات. تحتاج إلى الانتظار لمدة عام كامل لملء البيانات السنوية. نحن نحاول أن نكتبها بطريقة أو بأخرى.

لا توجد كتابة عن بعد في بروميثيوس ، وبالتالي ، لن تعمل كتابة الكثير من البيانات إلى TSDB المحلي.

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

لقد كتبنا مصدرًا مزيفًا يشبه المصدر العادي الذي يمكن لـ بروميثيوس أن يثبته:

• عندما تأتي الخردة ، يذهب إلى مصدر ما في المنبع. يأخذ البيانات منه.
• يولد العديد من الحالات. دعنا نقول 1 هو scrapie ، وحصلنا على 100 في الإخراج.
• يغير البيانات قليلاً: زائد ناقص 10٪ للعداد والقياس.
• لا يغير القيم البسيطة 0 أو 1. لأنه إذا كان هناك مقياس UP يستجيب فإنه يوضح ما إذا كانت الخدمة قيد التشغيل: نعم - 1 أو لا - 0. وليس من الواضح جدًا ماذا يعني 098 UP.
• نحن لا نغير الأعداد الصحيحة إلى الأعداد الصحيحة والعكس صحيح.
• إنه يعطي فقط البيانات بتنسيق expfmt المعتاد.

أداة التحميل التي تقوم بتحميل البيانات. قراءة البيانات:

• يمكن القراءة من الملفات بتنسيقها الخاص
• ربما من القراءة عن بعد
• يمكن أن تقرأ من بعض المصدرين

يكتب في أشكال مختلفة. بما في ذلك / dev / null ، إذا كنا نرغب في اختبار بالضبط كيف تعمل القراءة بسرعة.

الآن هي أداة اختبار التحميل ليس فقط لـ PromHouse ، ولكن أيضًا لأي حل يستخدم القراءة عن بُعد أو Prometheus.

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

نوع من الترشيح على الطاير ، نوع من التعديل على الطاير.

الدعم الأصلي ل TSDB. من أجل العمل مع قاعدة البيانات على القرص ، وليس من خلال API.

التركيز على الدقة للهجرة. أنا مرة واحدة وضعت pmmdemo.percona.com: متصلة ، تلقى جميع المقاييس. إذا قمت بذلك بطريقة أصلية ، فإن Prometheus يفتح TSDB ، ويجمع كل السلاسل الزمنية من القرص ، ويزيد الفهارس ، ثم يزحف إلى ملفات كبيرة ، ويدرك أنه موجود بالفعل. عند هذه النقطة ، كل شيء يمكن أن يستلقي.

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

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

سوف نكتب على مدونة Percona عندما نقوم بإجراء اختبار الحمل.

أستطيع أن أقول النتائج دون الرسوم البيانية. كان التسجيل خطيا. قفزت القراءة ولم تكن سريعة جدا. قراءة البيانات الحالية ليست مهمة للغاية بالنسبة لنا. يمكن تسريعها من خلال تلميحات القراءة. يمكنك تمكين read_recent لتحسين القراءة. وللبيانات القديمة ، وهذا يعمل بشكل جيد.

الناس يريدون تخزين طويل الأجل. هناك مثل هذا الطلب. لقد تحدثنا عن PromHouse في PromCon. كان هناك موضوع ساخن جدا. Thanos تتطور بنشاط.

إنه بالفعل ممكن الآن. هناك حل لهذا. هناك API. هناك بعض التكامل. ولكن كل هذا يحتاج إلى الانتهاء من ملف. لا توجد حلول جاهزة للإنتاج.

روابط أن ننظر فيها. الرابط الأول هو مستودع PromHouse. الرابط الثاني هو المكان الذي من المحتمل أن يتحرك فيه. الآن في مستودع واحد وهناك عدة أشياء مختلفة؟ لا علاقة وثيقة للغاية. لذلك ، سوف تحتاج إلى نقلها.

سوف تحتوي مدونتنا على معلومات حول الأداء وبعض الأخبار.

أسئلة:

سؤال: هل راجعت الشائعات حول InfluxDB؟

الجواب: لم يكن جيدًا. أصبح أفضل بكثير. كل هذه القصص عن حقيقة أن InfluxDB بطيء ، ينهار - إنها تدور حول الإصدار القديم. النسخة الحالية مستقرة. لن أقول؟ أنه يعمل بسرعة. لكنه يعمل بشكل مستقر. إيجابيات InfluxDB في رأيي:

• أولاً ، ليست هناك حاجة للقيام بشيء قريب ، لأن InfluxDB يعمل خارج الصندوق.
• ثانياً ، في ClickHouse ، كما هو الحال في الحلول الأخرى المستندة إلى قاعدة البيانات ، ولكن ليس TSDB ، يمكنك استخدام لغة استعلام مألوفة لك. لغة استعلام InfluxDB تشبه SQL. يمكنك إجراء تحليلات عليه ، وهو أمر صعب القيام به على PromQL. إذا كنت تستخدم TimeScaleDB - هناك SQL الحقيقي.

السؤال: هل محرك GraphiteMergeTree يعمل فقط للتسجيل؟ إذا كنا نريد عرض الرسوم البيانية ، فهل يلزم إعداد Grafana على الجرافيت لإظهار تخزين طويل الأجل؟

الجواب: نعم. التكامل في Prometheus نفسه يعمل فقط للتسجيل. يكتب فقط البيانات. إذن من غرافانا تذهب إلى الجرافيت.

سؤال: ويفقد الملصقات عندما يكتب؟

الإجابة: هناك تكوين يوضح ما يجب القيام به معهم ، وكيفية إدراجه ، ومكان إدراجه.

معلومات من الجمهور: قال أفيتو إنهم يكتبون حلهم للتسجيلات من بروميثيوس إلى الجرافيت.

سؤال: كان هناك استنتاج مفاده أنه مع تسجيل كل شيء على ما يرام على خادم تخزين طويل الأجل.

هناك تدفق مليون المقاييس (5 دقائق أو 15 دقيقة). raid 6 sata ?

: PMM — . downsampling c 14 1 . , . . . .

: IOPS ?

: .

:

: . , . , , .

: InfluxDB, InfluxDB?

: read_recent. , remote storage. InfluxDB . . read_recent , .

: , Prometheus. InfluxDB. Grafana Prometheus. Prometheus PromQL , InfluxDB?

: .

: Prometheus InfluxDB Grafana?

: . Prometheus 2.2 , .

PS : valyala gecube
, .