أهلاً بكم! في المادة الاخيرة لقد كتبت عن تنظيم نظام مراقبة معياري لبنية الخدمات المصغرة. لا شيء يقف ساكنًا ، مشروعنا ينمو باستمرار ، وكذلك عدد المقاييس المخزنة. كيف قمنا بتنظيم الانتقال من Graphite + Whisper إلى Graphite + ClickHouse في ظل ظروف تحميل عالية ، واقرأ عن التوقعات منه ونتائج الترحيل تحت القطع.

قبل أن أخبرك كيف قمنا بتنظيم الانتقال من تخزين المقاييس في Graphite + Whisper إلى Graphite + ClickHouse ، أود تقديم معلومات حول أسباب اتخاذ مثل هذا القرار وعيوب Whisper التي عشناها لفترة طويلة.

مشاكل الجرافيت + الهمس

1. ارتفاع الحمل على النظام الفرعي للقرص

في وقت الانتقال ، تم إرسال ما يقرب من 1.5 مليون مقياس في الدقيقة إلينا. مع هذا التدفق ، كان استخدام القرص على الخوادم حوالي 30٪. بشكل عام ، كان مقبولًا تمامًا - كل شيء يعمل بثبات ، وكُتب بسرعة ، وقراءة بسرعة ... حتى طرح أحد فرق التطوير ميزة جديدة وبدأ في إرسال 10 ملايين مقياس في الدقيقة إلينا. عندها تم تشديد النظام الفرعي للقرص ، وشهدنا استخدامًا بنسبة 100 ٪. تم حل المشكلة بسرعة ، لكن الرواسب بقيت.

2. عدم التكرار والاتساق

على الأرجح ، مثل أي شخص يستخدم / يستخدم الجرافيت + الهمس ، قمنا بسكب نفس دفق المقاييس على العديد من خوادم الجرافيت في وقت واحد من أجل إنشاء التسامح مع الخطأ. ولم تكن هناك مشاكل خاصة مع هذا - حتى اللحظة التي لم يسقط فيها أحد الخوادم لسبب ما. في بعض الأحيان ، تمكنا من إحضار الخادم المتساقط بسرعة كافية ، وتمكنت Carbon-c-relay من ملئه بمقاييس من ذاكرة التخزين المؤقت الخاصة به ، وأحيانًا لا. ثم كان هناك فجوة في المقاييس ، والتي غطيناها بـ rsync. كان الإجراء طويلًا جدًا. تم الحفظ فقط من خلال حقيقة أن هذا حدث نادرًا جدًا. كما أخذنا بشكل دوري مجموعة عشوائية من المقاييس وقارناها بمقاييس أخرى مماثلة في العقد المجاورة للمجموعة. في حوالي 5٪ من الحالات ، اختلفت عدة قيم ، الأمر الذي لم يجعلنا سعداء للغاية.

3. شغل مساحة كبيرة

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

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

بعد كل ما سبق (مع مراعاة السابق مقالات) ، بالإضافة إلى الزيادة المستمرة في عدد المقاييس المستلمة ، والرغبة في نقل جميع المقاييس إلى فترة تخزين تبلغ 30 ثانية. (حتى 10 ثوانٍ إذا لزم الأمر) ، قررنا تجربة Graphite + ClickHouse كبديل واعد لـ Whisper.

الجرافيت + ClickHouse. التوقعات

بعد أن زرت العديد من لقاءات الرجال من Yandex ، بعد أن قرأت مقالتان عن حبري، بعد الاطلاع على الوثائق والعثور على مكونات عاقلة لربط ClickHouse تحت الجرافيت ، قررنا العمل!

هل ترغب في الحصول على ما يلي:

تقليل استخدام النظام الفرعي للقرص من 30٪ إلى 5٪ ؛
تقليل المساحة المشغولة من 1 تيرابايت إلى 100 جيجابايت ؛
أن تكون قادرًا على تلقي 100 مليون مقياس في الدقيقة إلى الخادم ؛
نسخ البيانات والتسامح مع الخطأ خارج الصندوق ؛
لا تجلس في هذا المشروع لمدة عام وتجري الانتقال لفترة معقولة ؛
التبديل دون توقف.

طموح جدا ، أليس كذلك؟

الجرافيت + ClickHouse. عناصر

لتلقي البيانات عبر بروتوكول الجرافيت ثم كتابتها إلى ClickHouse ، اخترت بيت النقر فوق الكربون (جولانج).

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

تم تحديد لقراءة البيانات من ClickHouse الجرافيت-clickhouse (جولانج). كواجهة برمجة تطبيقات للجرافيت - كاربونابي (جولانج). لتنظيم النسخ المتماثل بين الجداول ، تم استخدام ClickHouse حارس حديقة الحيوان. لمقاييس التوجيه ، تركنا أحبائنا مرحل الكربون (C) (انظر المقال السابق).

الجرافيت + ClickHouse. هيكل الجدول

"الجرافيت" هي قاعدة بيانات أنشأناها لمراقبة الجداول.

"Graphite.metrics" هو جدول به محرك ReplicatedReplacingMergeTree (منسوخ استبدال MergeTree). يخزن هذا الجدول أسماء المقاييس والمسارات إليها.

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

"Graphite.data" هو جدول يحتوي على محرك ReplicatedGraphiteMergeTree (منسوخ الجرافيت). يخزن هذا الجدول القيم المترية.

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

"Graphite.date_metrics" عبارة عن جدول معبأ بشروط مع محرك ReplicatedReplacingMergeTree. يحتوي هذا الجدول على أسماء جميع المقاييس التي تمت مواجهتها خلال اليوم. تم وصف أسباب الخلق في القسم "مشاكل" في نهاية هذه المقالة.

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

"Graphite.data_stat" هو جدول شرطي مع محرك ReplicatedAggregatingMergeTree (منسوخ AggregatingMergeTree). يسجل هذا الجدول عدد المقاييس الواردة ، مقسمة إلى 4 مستويات متداخلة.

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

الجرافيت + ClickHouse. مخطط تفاعل المكونات

الجرافيت + ClickHouse. ترحيل البيانات

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

تمت إضافة قاعدة إلى مرحل الكربون ج لإرسال تدفق إضافي من المقاييس إلى غرفة النقر فوق الكربون لأحد الخوادم المشاركة في نسخ جداول ClickHouse.
لقد كتبنا نصًا برمجيًا صغيرًا بلغة python ، باستخدام مكتبة whisper-dump ، قرأنا جميع ملفات .wsp من وحدة التخزين الخاصة بنا وأرسلنا هذه البيانات إلى غرفة النقر بالكربون الموصوفة أعلاه في 24 موضوعًا. وصل عدد القيم المترية المقبولة في غرفة النقر فوق الكربون إلى 125 مليون / دقيقة ، ولم يتعرق ClickHouse حتى.
أنشأنا مصدر بيانات منفصل في Grafana من أجل تصحيح الوظائف المستخدمة في لوحات المعلومات الحالية. كشف قائمة بالميزات التي استخدمناها ، لكن لم يتم تنفيذها في كاربونابي. لقد انتهينا من هذه الوظائف ، وأرسلنا العلاقات العامة إلى مؤلفي carbonapi (شكر خاص لهم).
لتبديل حمل القراءة في إعدادات الموازن ، قمنا بتغيير نقاط النهاية من واجهة برمجة تطبيقات الجرافيت (واجهة API لـ Graphite + Whisper) إلى carbonapi.

الجرافيت + ClickHouse. نتائج

خفض استخدام نظام القرص الفرعي من 30٪ إلى 1٪ ؛
تقليل مساحة المساحة المشغولة من 1 تيرابايت إلى 300 جيجابايت ؛
لدينا القدرة على تلقي 125 مليون مقياس في الدقيقة لكل خادم (فترات الذروة في وقت الترحيل) ؛
نقل جميع المقاييس إلى فترة تخزين تبلغ ثلاثين ثانية ؛
تلقي تكرار البيانات والتسامح مع الخطأ ؛
تحول دون توقف
استغرق الأمر حوالي 7 أسابيع لكل شيء.

الجرافيت + ClickHouse. مشاكل

في حالتنا ، كانت هناك بعض المزالق. هذا ما واجهناه بعد الانتقال.

لا يقوم ClickHouse دائمًا بإعادة قراءة التكوينات أثناء التنقل ، وأحيانًا يحتاج إلى إعادة تحميله. على سبيل المثال ، في حالة وصف مجموعة zookeeper في تكوين ClickHouse ، لم يتم تطبيقه حتى يتم إعادة تشغيل خادم clickhouse.
لم تكن هناك طلبات ClickHouse كبيرة ، لذلك في منزل النقر على الجرافيت الخاص بنا ، تبدو سلسلة اتصال ClickHouse كما يلي:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
تُصدر ClickHouse غالبًا إصدارات جديدة من الإصدارات المستقرة ، وقد تحتوي على مفاجآت: كن حذرًا.
ترسل الحاويات التي تم إنشاؤها ديناميكيًا في kubernetes عددًا كبيرًا من المقاييس ذات العمر الافتراضي القصير والعشوائي. لا توجد نقاط كثيرة حسب هذه المقاييس ، ولا توجد مشاكل بالمكان. ولكن عند إنشاء الاستعلامات ، تثير ClickHouse عددًا كبيرًا من هذه المقاييس نفسها من جدول "المقاييس". في 90٪ من الحالات لا توجد بيانات لهم خارج النافذة (24 ساعة). لكن الوقت الذي يتم قضاؤه في البحث عن هذه البيانات في جدول "البيانات" يُهدر ، ويستقر في النهاية على مهلة. لحل هذه المشكلة ، بدأنا في الحفاظ على عرض منفصل بمعلومات عن المقاييس التي تمت مواجهتها خلال اليوم. وبالتالي ، عند إنشاء تقارير (رسوم بيانية) للحاويات التي تم إنشاؤها ديناميكيًا ، فإننا نقوم باستقصاء المقاييس التي تمت مواجهتها في النافذة المحددة فقط ، وليس طوال الوقت ، مما أدى إلى تسريع إنشاء التقارير عنها بشكل كبير. للحل أعلاه تم جمعها انقر فوق الجرافيت (شوكة)، والذي يتضمن تنفيذ العمل مع الجدول date_metrics.

الجرافيت + ClickHouse. العلامات

منذ الإصدار 1.1.0 أصبح الجرافيت رسميًا علامات الدعم. ونحن نفكر بنشاط في ما يجب القيام به وكيفية القيام به لدعم هذه المبادرة في مكدس الجرافيت + clickhouse.

الجرافيت + ClickHouse. كاشف الشذوذ

استنادًا إلى البنية التحتية الموضحة أعلاه ، قمنا بتنفيذ نموذج أولي للكشف عن الشذوذ ، وهو يعمل! لكن عنه - في المقال التالي.

اشترك ، اضغط على السهم لأعلى وكن سعيدًا!

المصدر: www.habr.com

التخزين المتري: كيف انتقلنا من الجرافيت + الهمس إلى الجرافيت + ClickHouse