تعد قاعدة بيانات السلاسل الزمنية (TSDB) في بروميثيوس 2 مثالًا رائعًا على الحل الهندسي الذي يقدم تحسينات كبيرة على التخزين بروميثيوس 2 الإصدار 1 من حيث جمع البيانات وسرعة تنفيذ الاستعلام ، وكفاءة الموارد. كنا ننفذ Prometheus 2 في Percona Monitoring and Management (PMM) وأتيحت لي الفرصة لفهم أداء Prometheus 2 TSDB. في هذا المقال سأتحدث عن نتائج هذه الملاحظات.
متوسط عبء العمل بروميثيوس
بالنسبة لأولئك الذين اعتادوا التعامل مع قواعد بيانات الأغراض العامة ، فإن عبء عمل بروميثيوس النموذجي مثير جدًا للاهتمام. يميل معدل تراكم البيانات إلى الاستقرار: عادةً ما ترسل الخدمات التي تراقبها نفس القدر من المقاييس ، وتتغير البنية التحتية ببطء نسبيًا.
قد تأتي طلبات المعلومات من مصادر مختلفة. يهدف بعضها ، مثل التنبيهات ، أيضًا إلى الحصول على قيمة ثابتة ومتوقعة. قد يتسبب البعض الآخر ، مثل طلبات المستخدم ، في حدوث طفرات ، على الرغم من أن هذا ليس هو الحال بالنسبة لمعظم عبء العمل.
اختبار الحمل
أثناء الاختبار ، ركزت على القدرة على تجميع البيانات. لقد قمت بنشر Prometheus 2.3.2 المترجمة مع Go 1.10.1 (كجزء من PMM 1.14) على خدمة Linode باستخدام هذا البرنامج النصي: . لتوليد الحمل الأكثر واقعية ، مع هذا قمت بتشغيل عدة عقد MySQL بحمل حقيقي (اختبار Sysbench TPC-C) ، كل منها تحاكي 10 عقد Linux / MySQL.
تم إجراء جميع الاختبارات التالية على خادم Linode مع ثمانية vCores و 32 جيجابايت من الذاكرة ، وتشغيل 20 محاكاة تحميل لمراقبة 800 حالة MySQL. أو ، من حيث بروميثيوس ، 440 هدف (أهداف) ، 380 رسومًا (كشط) في الثانية ، 1,7 ألف سجل (عينة) في الثانية و XNUMX مليون سلسلة زمنية نشطة.
تصميم
نهج قاعدة البيانات التقليدية المعتاد ، بما في ذلك تلك المستخدمة من قبل بروميثيوس 1.x ، هو . إذا لم يكن ذلك كافيًا للتعامل مع الحمل ، فستواجه وقت استجابة مرتفعًا ولن يتم تلبية بعض الطلبات. استخدام الذاكرة في بروميثيوس 2 قابل للتكوين عبر مفتاح storage.tsdb.min-block-duration، والذي يحدد المدة التي سيتم الاحتفاظ فيها بالسجلات في الذاكرة قبل شطفها على القرص (الافتراضي هو ساعتان). سيعتمد مقدار الذاكرة المطلوبة على عدد السلاسل الزمنية والتسميات والخدوش ، بالإضافة إلى صافي الإدخال. من حيث مساحة القرص ، يهدف بروميثيوس إلى استخدام 2 بايت لكل كتابة (عينة). من ناحية أخرى ، فإن متطلبات الذاكرة أعلى من ذلك بكثير.
في حين أنه من الممكن تكوين حجم الكتلة ، لا يوصى بتعيينه يدويًا ، لذلك تترك مهمة إعطاء Prometheus أكبر قدر من الذاكرة التي يحتاجها لأعباء عملك.
إذا لم تكن هناك ذاكرة كافية لدعم التدفق الوارد من المقاييس ، فسوف يسقط بروميثيوس من الذاكرة أو يتم القبض عليه من قبل قاتل OOM.
إن إضافة المبادلة لتأخير الانهيار عند نفاد ذاكرة بروميثيوس لا يساعد حقًا ، لأن استخدام هذه الميزة يسبب انفجار الذاكرة. أعتقد أن الأمر يتعلق بـ Go ، جامع القمامة ، وكيف يعمل مع المبادلة.
طريقة أخرى مثيرة للاهتمام هي ضبط كتلة الرأس ليتم شطفها على القرص في وقت معين ، بدلاً من عدها من وقت بدء العملية.
كما ترى من الرسم البياني ، تحدث عمليات المسح على القرص كل ساعتين. إذا قمت بتغيير معلمة min-block-duration إلى ساعة واحدة ، فستحدث عمليات إعادة التعيين هذه كل ساعة ، بدءًا من نصف ساعة.
إذا كنت تريد استخدام هذا والرسوم البيانية الأخرى في تثبيت بروميثيوس الخاص بك ، فيمكنك استخدام هذا . تم تصميمه من أجل PMM ، ولكن مع بعض التعديلات ، يتناسب مع أي تثبيت من Prometheus.
لدينا كتلة نشطة ، تسمى كتلة الرأس ، يتم تخزينها في الذاكرة ؛ الكتل التي تحتوي على بيانات قديمة متاحة عبر mmap(). يؤدي هذا إلى إزالة الحاجة إلى تكوين ذاكرة التخزين المؤقت بشكل منفصل ، ولكنه يعني أيضًا أنك بحاجة إلى ترك مساحة كافية لذاكرة التخزين المؤقت لنظام التشغيل إذا كنت تريد الاستعلام عن بيانات أقدم من كتلة الرأس.
هذا يعني أيضًا أن استهلاك الذاكرة الافتراضية من بروميثيوس سيبدو مرتفعًا جدًا ، ولا داعي للقلق.
نقطة تصميم أخرى مثيرة للاهتمام هي استخدام WAL (اكتب السجل المسبق). كما ترى من وثائق المستودع ، يستخدم Prometheus WAL لتجنب الأعطال. آليات محددة لضمان بقاء البيانات ، للأسف ، ليست موثقة بشكل جيد. يقوم Prometheus 2.3.2 بمسح WAL على القرص كل 10 ثوانٍ وهذا الإعداد غير قابل للتكوين بواسطة المستخدم.
الأختام
تم تصميم Prometheus TSDB في صورة تخزين LSM (دمج منظم السجل - شجرة دمج منظم السجل): يتم مسح كتلة الرأس بشكل دوري على القرص ، بينما تدمج آلية الضغط عدة كتل معًا لتجنب مسح العديد من الكتل عند الطلبات. هنا يمكنك رؤية عدد الكتل التي لاحظتها في نظام الاختبار بعد يوم من التحميل.
إذا كنت تريد معرفة المزيد حول التخزين ، فيمكنك التحقق من ملف meta.json ، الذي يحتوي على معلومات حول الكتل المتاحة وكيفية ظهورها.
{
"ulid": "01CPZDPD1D9R019JS87TPV5MPE",
"minTime": 1536472800000,
"maxTime": 1536494400000,
"stats": {
"numSamples": 8292128378,
"numSeries": 1673622,
"numChunks": 69528220
},
"compaction": {
"level": 2,
"sources": [
"01CPYRY9MS465Y5ETM3SXFBV7X",
"01CPYZT0WRJ1JB1P0DP80VY5KJ",
"01CPZ6NR4Q3PDP3E57HEH760XS"
],
"parents": [
{
"ulid": "01CPYRY9MS465Y5ETM3SXFBV7X",
"minTime": 1536472800000,
"maxTime": 1536480000000
},
{
"ulid": "01CPYZT0WRJ1JB1P0DP80VY5KJ",
"minTime": 1536480000000,
"maxTime": 1536487200000
},
{
"ulid": "01CPZ6NR4Q3PDP3E57HEH760XS",
"minTime": 1536487200000,
"maxTime": 1536494400000
}
]
},
"version": 1
}ترتبط الأختام الموجودة في بروميثيوس بالوقت الذي يتم فيه مسح كتلة الرأس بالقرص. في هذه المرحلة ، يمكن تنفيذ العديد من هذه العمليات.
يبدو أن عمليات الضغط غير محدودة بأي شكل من الأشكال ويمكن أن تتسبب في حدوث ارتفاعات كبيرة في عمليات الإدخال / الإخراج على القرص أثناء التنفيذ.
ارتفاعات تحميل وحدة المعالجة المركزية
بالطبع ، هذا له تأثير سلبي إلى حد ما على سرعة النظام ، كما أنه يمثل تحديًا خطيرًا لمخازن LSM: كيف يتم إجراء عمليات ضغط لدعم سرعات الاستعلام العالية دون التسبب في الكثير من النفقات العامة؟
يبدو أيضًا استخدام الذاكرة في عملية الضغط أمرًا مثيرًا للفضول.
يمكننا أن نرى كيف ، بعد الضغط ، تتغير حالة معظم الذاكرة من Cached إلى Free: هذا يعني أنه تمت إزالة المعلومات القيمة المحتملة من هناك. من الغريب إذا تم استخدامه هنا fadvice() أو بعض تقنيات التصغير الأخرى ، أم أنه بسبب إفراغ ذاكرة التخزين المؤقت من الكتل التي تم إتلافها عن طريق الضغط؟
استرداد الفشل
يستغرق التعافي من الكوارث وقتًا ، ولسبب وجيه. للحصول على دفق وارد يصل إلى مليون سجل في الثانية ، كان علي الانتظار حوالي 25 دقيقة بينما كان الاسترداد يأخذ في الاعتبار محرك SSD.
level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Starting Prometheus" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
level=info ts=2018-09-13T13:38:14.096599879Z caller=main.go:223 build_context="(go=go1.10.1, user=Jenkins, date=20180725-08:58:13OURCE)"
level=info ts=2018-09-13T13:38:14.096624109Z caller=main.go:224 host_details="(Linux 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 1bee9e9b78cf (none))"
level=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Start listening for connections" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Starting TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="router prefix" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL corruption detected; truncating" err="unexpected CRC32 checksum d0465484, want 0" file=/opt/prometheus/data/.prom2-data/wal/007357 pos=15504363
level=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Loading configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Completed loading of configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server is ready to receive web requests."المشكلة الرئيسية في عملية الاسترداد هي الاستهلاك العالي للذاكرة. على الرغم من أن الخادم يمكن أن يعمل بثبات بنفس القدر من الذاكرة في الوضع الطبيعي ، إذا تعطل ، فقد لا يرتفع بسبب OOM. الحل الوحيد الذي وجدته هو إيقاف جمع البيانات ، وإحضار الخادم ، والسماح له بالاسترداد ، وإعادة التشغيل مع تمكين التجميع.
الاحماء
هناك سلوك آخر يجب أخذه في الاعتبار أثناء الإحماء وهو نسبة الأداء المنخفض إلى استهلاك الموارد المرتفع بعد بدء التشغيل مباشرة. أثناء بعض عمليات البدء ، ولكن ليس كلها ، لاحظت عبئًا خطيرًا على وحدة المعالجة المركزية والذاكرة.
تشير الانخفاضات في استخدام الذاكرة إلى أن Prometheus لا يمكنه تكوين جميع الرسوم من البداية ، ويتم فقد بعض المعلومات.
لم أجد الأسباب الدقيقة لارتفاع استخدام وحدة المعالجة المركزية والذاكرة. أظن أن هذا يرجع إلى إنشاء سلسلة زمنية جديدة في كتلة الرأس ذات التردد العالي.
طفرات وحدة المعالجة المركزية
بالإضافة إلى التكثيف ، الذي يؤدي إلى تحميل إدخال / إخراج مرتفع إلى حد ما ، فقد لاحظت ارتفاعات خطيرة في تحميل وحدة المعالجة المركزية كل دقيقتين. تكون الاندفاعات أطول مع حركة واردة عالية وتبدو وكأنها ناتجة عن جامع القمامة Go ، على الأقل بعض النوى محملة بالكامل.
هذه القفزات ليست تافهة. يبدو أنه عند حدوثها ، تصبح نقطة الدخول الداخلية ومقاييس بروميثيوس غير متوفرة ، مما يتسبب في انخفاض البيانات في الفترات الزمنية نفسها.
قد تلاحظ أيضًا أن مُصدِّر بروميثيوس يتوقف عن العمل لمدة ثانية واحدة.
يمكننا أن نرى الارتباطات مع جمع القمامة (GC).
اختتام
TSDB في Prometheus 2 سريع ، وقادر على التعامل مع ملايين السلاسل الزمنية وفي نفس الوقت الآلاف من عمليات الكتابة في الثانية باستخدام أجهزة متواضعة إلى حد ما. استخدام وحدة المعالجة المركزية والقرص I / O مثير للإعجاب أيضًا. أظهر مثالي ما يصل إلى 200 مقياس في الثانية لكل نواة مستخدمة.
للتخطيط للتوسع ، عليك أن تتذكر أن هناك ذاكرة كافية ، ويجب أن تكون ذاكرة حقيقية. كانت كمية الذاكرة المستخدمة ، والتي لاحظتها ، حوالي 5 غيغابايت لكل 100 سجل في الثانية من التدفق الوارد ، والتي ، في المجموع مع ذاكرة التخزين المؤقت لنظام التشغيل ، أعطت حوالي 000 غيغابايت من الذاكرة المشغولة.
بالطبع ، لا يزال هناك الكثير من العمل الذي يتعين القيام به لترويض ارتفاعات وحدة المعالجة المركزية والقرص I / O ، وهذا ليس مفاجئًا ، نظرًا لمقارنة TSDB Prometheus 2 الشاب بـ InnoDB ، و TokuDB ، و RocksDB ، و WiredTiger ، لكنهم جميعًا كان لديهم مشاكل مماثلة في بداية دورة حياتهم.
المصدر: www.habr.com