المراقبة كخدمة: نظام نمطي لهندسة الخدمات المصغرة

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

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

الماضي: المخططات والخطط

كيف وصلنا إلى نظام المراقبة الحالي؟ للإجابة على هذا السؤال ، عليك الذهاب إلى عام 2015. هذا هو الشكل الذي بدت عليه بعد ذلك:

كان لدينا حوالي 24 عقدة كانت مسؤولة عن المراقبة. هناك مجموعة كاملة من crons والنصوص والشياطين المختلفة التي تراقب شيئًا ما في مكان ما ، وترسل الرسائل ، وتؤدي وظائف. كنا نظن أنه كلما زاد الأمر ، كلما قلت قابلية هذا النظام للاستمرار. لا معنى لتطويره: إنه مرهق للغاية.
قررنا اختيار عناصر المراقبة التي سنتركها ونطورها ، والعناصر التي سنتخلى عنها. كان هناك 19 منهم فقط الجرافيت ، المجمعات و Grafana كلوحة القيادة بقيت. لكن كيف سيبدو النظام الجديد؟ مثله:

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

المعيار: المراقبة 2.0

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

• التوافر المستمر
• فاصل التخزين المتري = 10 ثوانٍ ؛
• التخزين المنظم للمقاييس ولوحات المعلومات ؛
• اتفاقية مستوى الخدمة> 99,99٪
• مجموعة من مقاييس الأحداث عبر UDP (!).

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

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

الحاضر: مخطط تفاعل مكونات المراقبة

بادئ ذي بدء ، نحن نراقب التطبيقات: كود PHP الخاص بنا والتطبيقات والخدمات المصغرة - باختصار ، كل ما يكتبه مطورونا. ترسل جميع التطبيقات المقاييس عبر UDP إلى مجمّع Brubeck (statsd ، أعيد كتابته في C). اتضح أنه الأسرع وفقًا لنتائج الاختبارات التركيبية. ويرسل المقاييس المجمعة بالفعل إلى الجرافيت عبر TCP.

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

لدينا أيضًا تجميع للأجهزة والبرامج ومقاييس النظام ونظام مراقبة Munin القديم الخاص بنا (كان يعمل معنا حتى عام 2015). نقوم بجمع كل هذا من خلال C'ish daemon CollectD (يتم حياكة مجموعة كاملة من المكونات الإضافية المختلفة فيه ، ويمكنه الاستعلام عن جميع موارد النظام المضيف الذي تم تثبيته عليه ، فقط حدد في التكوين مكان كتابة البيانات ) وكتابة البيانات من خلالها بالجرافيت. كما أنه يدعم مكونات بايثون الإضافية ونصوص shell ، بحيث يمكنك كتابة الحلول المخصصة الخاصة بك: ستجمع CollectD هذه البيانات من مضيف محلي أو بعيد (بافتراض توفر Curl) وإرسالها إلى Graphite.

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

ثم يرسل Carbon-c-relay المقاييس إلى مجموعة الجرافيت. نحن نستخدم ذاكرة التخزين المؤقت للكربون المعاد كتابتها في Go كمخزن رئيسي للمقاييس. Go-carbon ، نظرًا لتعدد خيوطه ، متفوق كثيرًا في الأداء على ذاكرة التخزين المؤقت للكربون. يأخذ البيانات إلى نفسه ويكتبها على القرص باستخدام حزمة whisper (قياسية ، مكتوبة بلغة python). من أجل قراءة البيانات من مخازننا ، نستخدم واجهة برمجة تطبيقات الجرافيت. إنه يعمل بشكل أسرع بكثير من الجرافيت WEB القياسي. ماذا يحدث للبيانات بعد ذلك؟

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

المضي قدمًا: التنبيه. إنه منظم بنظام قوي - Moira. إنها مستقلة لأن لديها الجرافيت الخاص بها تحت غطاء المحرك. تم تطويره بواسطة شباب من SKB Kontur ، مكتوب بلغة python and Go ، مفتوح المصدر بالكامل. يتلقى Moira نفس التدفق الذي يذهب إلى الجرافيت. إذا ماتت سعة التخزين لديك لسبب ما ، فسيعمل التنبيه الخاص بك.

لقد نشرنا Moira في Kubernetes ، وهو يستخدم مجموعة من خوادم Redis كقاعدة بيانات رئيسية. والنتيجة هي نظام متسامح مع الخطأ. يقارن تدفق المقاييس بقائمة المشغلات: إذا لم يكن هناك أي إشارة فيه ، فإنه يسقط المقياس. لذا فهي قادرة على هضم وحدات غيغابايت من المقاييس في الدقيقة.

لقد أضفنا أيضًا LDAP للشركة ، وبمساعدة كل مستخدم لنظام الشركة يمكنه إنشاء إشعارات لنفسه بشأن المشغلات الحالية (أو التي تم إنشاؤها حديثًا). نظرًا لأن Moira يحتوي على الجرافيت ، فإنه يدعم جميع ميزاته. لذا عليك أولاً أن تأخذ السطر وتنسخه إلى جرافانا. انظر كيف يتم عرض البيانات على الرسوم البيانية. ثم تأخذ نفس السطر وتنسخه إلى Moira. علقها بحدود واحصل على تنبيه عند الإخراج. للقيام بكل هذا ، لا تحتاج إلى أي معرفة محددة. يمكن لـ Moira التنبيه عبر الرسائل القصيرة والبريد الإلكتروني و Jira و Slack ... كما أنه يدعم البرامج النصية المخصصة. عندما يكون لديها مشغل ، واشتركت في برنامج نصي مخصص أو ثنائي ، تقوم بتشغيله وإرسال ملف JSON الثنائي هذا إلى stdin. وفقًا لذلك ، يجب أن يقوم برنامجك بتحليلها. ما ستفعله باستخدام JSON هذا متروك لك. إذا أردت ، أرسلها إلى Telegram ، إذا أردت ، افتح المهام في Jira ، افعل ما تريد.

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

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

مكونات المراقبة

فيما يلي قائمة بالروابط إلى المكونات التي استخدمناها لهذه المهمة. كلهم مفتوح المصدر.

الجرافيت:

• اذهب الكربون: github.com/lomik/go-carbon
• همسة: github.com/graphite-project/whisper
• الجرافيت API: github.com/brutasse/graphite-api

مرحل الكربون ج:

github.com/grobian/carbon-c-relay

بروبيك:

github.com/github/brubeck

تم جمعها:

Collectd.org

مويرا:

github.com/moira-alert

جرافانا:

grafana.com

هبستر:

github.com/kubernetes/heapster

إحصائيات

وإليك بعض الأرقام حول كيفية عمل النظام بالنسبة لنا.

مجمع (بروبيك)

عدد المقاييس: 300 / ثانية
الفاصل الزمني لإرسال مقاييس الجرافيت: 30 ثانية
استخدام موارد الخادم: ~ 6٪ وحدة المعالجة المركزية (نحن نتحدث عن خوادم كاملة) ؛ ~ 1 جيجا بايت رام ؛ ~ 3 ميغابت في الثانية LAN

الجرافيت (go-carbon)

عدد المقاييس: ~ 1،600،000 / دقيقة
الفاصل الزمني لتحديث المقاييس: 30 ثانية
مخطط تخزين المقاييس: 30 ثانية و 35 يومًا ، و 5 دقائق و 90 يومًا ، و 10 دقائق و 365 يومًا (يعطي فهمًا لما يحدث للخدمة على مدار فترة زمنية طويلة)
استخدام موارد الخادم: ~ 10٪ CPU ؛ ~ 20 جيجا بايت من ذاكرة الوصول العشوائي ؛ ~ 30 ميغابت في الثانية LAN

مرونة

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

هنا مثال لمشكلة حقيقية. المقياس في الجرافيت هو ملف. لها اسم. اسم الملف = اسم المقياس. وهناك طريقة للوصول إلى هناك. أسماء الملفات في Linux محددة بـ 255 حرفًا. ولدينا (بصفتنا "عملاء داخليين") رجال من قسم قاعدة البيانات. يقولون لنا: "نريد مراقبة استعلامات SQL الخاصة بنا. وهي ليست 255 حرفًا ، بل 8 ميغا بايت لكل منها. نريد عرضها في Grafana ، ونرى معلمات هذا الطلب ، والأفضل من ذلك ، نريد أن نرى الجزء العلوي من هذه الطلبات. سيكون رائعًا إذا تم عرضه في الوقت الفعلي. وسيكون من الرائع حقًا دفعهم في حالة تأهب ".

تم أخذ مثال استعلام SQL كمثال من موقع postgrespro.ru

نرفع خادم Redis وإضافات Collectd التي تنتقل إلى Postgres وتأخذ جميع البيانات من هناك ، وترسل المقاييس إلى Graphite. لكننا نستبدل اسم المقياس بعلامات تجزئة. يتم إرسال نفس التجزئة في نفس الوقت إلى Redis كمفتاح ، واستعلام SQL بالكامل كقيمة. يبقى لنا أن نجعل Grafana قادرًا على الذهاب إلى Redis وأخذ هذه المعلومات. نحن نفتح واجهة برمجة تطبيقات الجرافيت لأن هذه هي الواجهة الرئيسية لتفاعل جميع مكونات المراقبة مع الجرافيت ، ونحن ندخل وظيفة جديدة تسمى aliasByHash () هناك - نحصل على اسم المقياس من Grafana ، ونستخدمه في طلب Redis كمفتاح ، في استجابة نحصل على قيمة المفتاح ، وهو "استعلام SQL" الخاص بنا. وهكذا ، قدمنا ​​إلى Grafana عرض استعلام SQL ، والذي ، من الناحية النظرية ، لا يمكن عرضه هناك ، إلى جانب الإحصاءات المتعلقة به (المكالمات ، الصفوف ، total_time ، ...).

نتائج

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

الموثوقية. جميع المكونات تتسامح مع الأخطاء وتتعامل مع أعباء العمل لدينا بشكل جيد.

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

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

ما الذي نسعى إليه؟

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

1. كاشف الشذوذ. نريد إنشاء خدمة تذهب إلى مخازن الجرافيت الخاصة بنا والتحقق من كل مقياس باستخدام خوارزميات مختلفة. هناك بالفعل خوارزميات نريد عرضها ، وهناك بيانات ، ونعرف كيفية التعامل معها.
2. البيانات الوصفية. لدينا العديد من الخدمات ، تتغير بمرور الوقت ، وكذلك الأشخاص الذين يعملون معهم. الاحتفاظ بالسجلات يدويًا ليس خيارًا. لذلك ، أصبحت البيانات الوصفية مضمنة الآن في خدماتنا المصغرة. فهي تنص على من طورها ، واللغات التي تتفاعل معها ، ومتطلبات اتفاقية مستوى الخدمة (SLA) ، وأين وإلى من ترسل الإشعارات. عند نشر خدمة ، يتم إنشاء جميع بيانات الكيان بشكل مستقل. نتيجة لذلك ، تحصل على رابطين - أحدهما للمشغلات والآخر للوحات المعلومات في Grafana.
3. المراقبة في كل بيت. نعتقد أنه يجب على جميع المطورين استخدام مثل هذا النظام. في هذه الحالة ، تفهم دائمًا مكان وجود حركة المرور الخاصة بك ، وماذا يحدث لها ، وأين تقع ، وأين توجد نقاط ضعف فيها. على سبيل المثال ، إذا حدث شيء ما وأدى إلى تعطل خدمتك ، فستكتشف ذلك ليس أثناء مكالمة من المدير ، ولكن من خلال تنبيه ، ويمكنك على الفور فتح سجلات جديدة ومعرفة ما حدث هناك.
4. أداء عالي. ينمو مشروعنا باستمرار ، واليوم يعالج حوالي 2،000،000 قيمة مترية في الدقيقة. قبل عام ، كان هذا الرقم 500. ويستمر النمو ، وهذا يعني أنه بعد مرور بعض الوقت سيبدأ الجرافيت (الهمس) في تحميل النظام الفرعي للقرص بكثافة كبيرة. كما قلت ، فإن نظام المراقبة هذا متعدد الاستخدامات نظرًا لإمكانية تبادل المكونات. شخص ما على وجه التحديد للجرافيت يحافظ على بنيته التحتية ويوسعها باستمرار ، لكننا قررنا أن نسير في الاتجاه الآخر: الاستخدام كليكهاوس كمستودع لمقاييسنا. لقد أوشك هذا الانتقال على الانتهاء ، وسأخبرك قريبًا بمزيد من التفصيل كيف تم ذلك: ما هي الصعوبات وكيف تم التغلب عليها ، وكيف سارت عملية الترحيل ، وسأصف المكونات المحددة على أنها ملزمة وتكويناتها.

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

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