اسمي انطون باديرين. أنا أعمل في مركز التقنيات المتقدمة وأشارك في إدارة النظام. قبل شهر ، انتهى مؤتمرنا التجاري ، حيث تبادلنا تجربتنا مع مجتمع تكنولوجيا المعلومات في مدينتنا. تحدثت عن مراقبة تطبيقات الويب. كانت المادة مخصصة للمستوى المبتدئ أو المتوسط ، والتي لم تبني هذه العملية من نقطة الصفر.
حجر الزاوية في أي نظام مراقبة هو الحل لمشاكل العمل. المراقبة من أجل المراقبة لا تهم أي أحد. ماذا تريد الشركة؟ بحيث يعمل كل شيء بسرعة ودون أخطاء. يريد العمل استباقية ، حتى نتمكن من تحديد المشكلات في الخدمة والقضاء عليها في أسرع وقت ممكن. هذه ، في الواقع ، هي المهام التي قمت بحلها طوال العام الماضي في مشروع أحد عملائنا.
عن المشروع
المشروع هو واحد من أكبر برامج الولاء في البلاد. نحن نساعد تجار التجزئة على زيادة وتيرة مبيعاتهم من خلال أدوات التسويق المختلفة مثل بطاقات المكافآت. في المجموع ، يتضمن المشروع 14 تطبيقًا تعمل على عشرة خوادم.
أثناء إجراء المقابلات ، لاحظت مرارًا وتكرارًا أن المشرفين لا يراقبون دائمًا تطبيقات الويب بشكل صحيح: حتى الآن ، توقف الكثيرون عن مقاييس نظام التشغيل ومراقبة الخدمات أحيانًا.
في حالتي ، كانت Icinga هي أساس نظام مراقبة العملاء من قبل. انها لم تحل المشاكل المذكورة أعلاه. غالبًا ما أبلغنا العميل نفسه بالمشاكل ، وعلى الأقل لم يكن لدينا ببساطة بيانات كافية للوصول إلى أسفل السبب.
بالإضافة إلى ذلك ، كان هناك فهم واضح لعقم تطويرها. أعتقد أن أولئك الذين هم على دراية بـ Icinga سوف يفهموني. لذلك ، قررنا إعادة تصميم نظام مراقبة تطبيقات الويب على المشروع بالكامل.
بروميثيوس
لقد اخترنا بروميثيوس بناءً على ثلاثة مؤشرات رئيسية:
- وهناك عدد كبير من المقاييس المتاحة. في حالتنا ، هناك 60 ألف منهم. بالطبع ، تجدر الإشارة إلى أن الغالبية العظمى منهم لا نستخدمها (ربما حوالي 95 ٪). من ناحية أخرى ، كلها رخيصة نسبيا. بالنسبة لنا ، هذا متطرف آخر بالمقارنة مع Icinga المستخدمة سابقًا. في ذلك ، كانت إضافة المقاييس بمثابة ألم معين: كانت المقاييس المتوفرة باهظة الثمن (انظر فقط الكود المصدري لأي ملحق إضافي). أي مكون إضافي كان نصًا Bash أو Python ، والذي لم يكن إطلاقه رخيصًا من حيث الموارد المستهلكة.
- يستهلك هذا النظام كمية صغيرة نسبيًا من الموارد. تحتوي جميع مقاييسنا على 600 ميغابايت من ذاكرة الوصول العشوائي و 15٪ من مجموعة واحدة واثنين من IOPS. بالطبع ، يجب عليك تشغيل مصدري المقاييس ، لكنهم جميعا مكتوبون في Go ولا يختلفون أيضًا في الشراهة. لا أعتقد أن هذه مشكلة في الواقع الحديث.
- يجعل من الممكن التبديل إلى Kubernetes. بالنظر إلى خطط العميل ، فإن الاختيار واضح.
ELK
في السابق ، لم نجمع السجلات أو نعالجها. العيوب واضحة للجميع. لقد اخترنا ELK ، نظرًا لأن لدينا بالفعل خبرة في هذا النظام. نحن تخزين سجلات التطبيق فقط هناك. كانت معايير الاختيار الرئيسية هي البحث عن النص الكامل وسرعته.
Slickhouse
في البداية ، وقع الاختيار على InfluxDB. لقد أدركنا الحاجة إلى جمع سجلات Nginx ، والإحصائيات من pg_stat_statements ، وتخزين بيانات Prometheus التاريخية. لم نكن نحب Influx ، حيث بدأ بشكل دوري في استهلاك كمية كبيرة من الذاكرة وتحطمت. بالإضافة إلى ذلك ، أردت تجميع الطلبات بواسطة remote_addr ، والتجميع في قواعد البيانات هذه فقط بالعلامات. علامات الطريق (الذاكرة) ، عددهم محدود مشروط.
بدأنا البحث مرة أخرى. كنا بحاجة إلى قاعدة تحليلية بأقل استهلاك للموارد ، ويفضل أن يكون ذلك مع ضغط البيانات على القرص.
تفي Clickhouse بجميع هذه المعايير ، ولم نأسف أبدًا لهذا الاختيار. لا نكتب أي كميات مستحقة من البيانات فيه (عدد الإدخالات هو فقط حوالي خمسة آلاف في الدقيقة).
NewRelic
تاريخيا كان NewRelic معنا لأنه كان اختيار العميل. نستخدمها باعتبارها APM.
Zabbix
نستخدم Zabbix حصريًا لمراقبة الصندوق الأسود للعديد من واجهات برمجة التطبيقات.
تحديد نهج الرصد
أردنا أن نحلل المهمة ، وبالتالي تنظيم منهج الرصد.
للقيام بذلك ، قسمت نظامنا إلى المستويات التالية:
- الأجهزة و VMS.
- نظام التشغيل
- خدمات النظام ، كومة البرمجيات ؛
- التطبيق؛
- منطق العمل.
ما الذي يجعل هذا النهج مناسبًا:
- نحن نعرف من المسؤول عن عمل كل مستوى من المستويات ، وبناءً على ذلك ، يمكننا إرسال تنبيهات ؛
- يمكننا استخدام البنية عند منع التنبيهات - سيكون من الغريب إرسال تنبيه حول عدم إمكانية الوصول إلى قاعدة البيانات عندما يكون الجهاز الظاهري ككل غير متوفر.
نظرًا لأن مهمتنا هي اكتشاف المخالفات في النظام ، يجب علينا في كل مستوى تحديد مجموعة معينة من المقاييس التي يجب الانتباه إليها عند كتابة قواعد التنبيه. بعد ذلك ، سنتطرق إلى مستويات "VMS" و "نظام التشغيل" و "خدمات النظام ، حزمة البرامج".
آلات افتراضية
الاستضافة تعطينا معالج ، قرص ، ذاكرة وشبكة. ومع أول اثنين لدينا مشاكل. لذلك المقاييس:
وقت وحدة المعالجة المركزية المسروقة - عند شراء جهاز افتراضي على Amazon (t2.micro ، على سبيل المثال) ، يجب أن تفهم أنه لم يتم تخصيص مجموعة أساسية كاملة من المعالج ، ولكن فقط حصة من وقتها. وعند استنفادها ، سيتم أخذ المعالج منك.
يسمح لك هذا المقياس بتتبع مثل هذه اللحظات واتخاذ القرارات. على سبيل المثال ، هل من الضروري أخذ تعريفة بدنية أو توزيع معالجة مهام وطلبات الخلفية في واجهة برمجة التطبيقات على خوادم مختلفة.
IOPS + CPU iowait time - لسبب ما ، العديد من شركات الاستضافة السحابية تخطئ بعدم تسليم IOPS. علاوة على ذلك ، فإن الجدول الزمني مع انخفاض IOPS ليس حجة لهم. لذلك ، يجدر جمع وحدة المعالجة المركزية iowait. مع هذا الزوج من الرسوم البيانية - مع انخفاض IOPS وتوقعات I / O عالية - يمكنك بالفعل التحدث إلى الاستضافة وحل المشكلة.
نظام التشغيل
مقاييس نظام التشغيل:
- مقدار الذاكرة المتاحة في ٪ ؛
- النشاط باستخدام المبادلة: vmstat swapin ، المبادلة.
- عدد inodes المتاحة والمساحة الحرة على نظام الملفات في ٪
- متوسط الحمل
- عدد الاتصالات في ولاية tw.
- كونتراك الجدول الامتلاء.
- يمكن مراقبة جودة الشبكة باستخدام الأداة المساعدة ss ، حزمة iproute2 - احصل من مؤشرها على مؤشر لاتصالات RTT ومجموعة بتفريغها.
أيضًا على مستوى نظام التشغيل ، لدينا كيان مثل العمليات. من المهم تسليط الضوء في النظام على مجموعة من العمليات التي تلعب دورًا مهمًا في عملها. على سبيل المثال ، إذا كان لديك العديد من pgpool ، فأنت بحاجة إلى جمع المعلومات لكل منهم.
مجموعة المقاييس هي كما يلي:
- وحدة المعالجة المركزية.
- الذاكرة هي في المقام الأول المقيم.
- IO - يفضل في IOPS ؛
- FileFd - فتح والحد.
- حالات فشل كبيرة للصفحات - حتى تتمكن من فهم العملية التي يتم تبادلها.
يتم نشر كل المراقبة في Docker ، ونحن نستخدم advisor لجمع البيانات المترية. على الأجهزة الأخرى ، نستخدم عملية المصدر.
خدمات النظام ، كومة البرمجيات
لكل تطبيق تفاصيله الخاصة ، ومن الصعب التمييز بين مجموعة من المقاييس.
مجموعة عالمية هي:
- معدل الطلب
- عدد الاخطاء
- الكمون.
- التشبع.
وأبرز الأمثلة على المراقبة على هذا المستوى هي Nginx و PostgreSQL.
الخدمة الأكثر تحميلًا في نظامنا هي قاعدة البيانات. اعتدنا أن لدينا مشاكل في كثير من الأحيان لمعرفة ما تفعله قاعدة البيانات.
لقد رأينا حمولة عالية على الأقراص ، لكن الشعارات لم تظهر أي شيء حقًا. لقد حللنا هذه المشكلة مع pg_stat_statements ، طريقة عرض تجمع إحصائيات حول الطلبات.
هذا هو كل احتياجات المشرف.
نرسم نشاط طلبات القراءة والكتابة:
كل شيء بسيط وواضح ، لكل طلب لونه الخاص.
مثال ملفتة للنظر هو سجلات Nginx. ليس من المستغرب أن القليل منهم يوزعهم أو يذكرهم في قائمة تلك المطلوبة. التنسيق القياسي ليس غني بالمعلومات ويحتاج إلى توسيع.
شخصيا ، أضفت request_time ، upstream_response_time ، body_bytes_sent ، request_length ، request_id ، نحن نرسم وقت الاستجابة وعدد الأخطاء:
نرسم وقت الاستجابة وعدد الأخطاء. هل تتذكر؟ هل تحدثت عن أهداف العمل؟ بسرعة ودون أخطاء؟ لقد أغلقنا بالفعل هذه المشكلات باستخدام مخططين. وعلىهم يمكنك بالفعل استدعاء المسؤولين واجب.
ولكن ظلت مشكلة أخرى - لضمان القضاء السريع على أسباب الحادث.
إدارة الحوادث
يمكن تقسيم العملية برمتها من تحديد المشكلة إلى حلها إلى عدد من الخطوات:
- تحديد المشكلة
- إخطار المسؤول في الخدمة ؛
- رد الفعل على الحادث ؛
- القضاء على الأسباب.
من المهم أن نفعل هذا في أسرع وقت ممكن. وإذا لم نتمكن من كسب الكثير من الوقت في مراحل تحديد المشكلة وإرسال إشعار - فسوف يغادرون لمدة دقيقتين في أي حال ، ثم التالية هي مجرد حقل لم يمس التحسين.
دعونا فقط نتخيل أن الهاتف رن في الخدمة. ماذا سيفعل؟ ابحث عن إجابات للأسئلة - ما الذي تم كسره ، وأين يتم كسره ، وكيفية الرد؟ إليك كيفية الإجابة على هذه الأسئلة:
نقوم ببساطة بتضمين كل هذه المعلومات في نص الإشعار ، ونمنحه رابطًا إلى صفحة wiki تصف كيفية الاستجابة لهذه المشكلة ، وكيفية حلها وتصعيدها.
ما زلت لم أقل أي شيء عن طبقة التطبيق ومنطق العمل. لسوء الحظ ، لم يتم تطبيق مجموعة المقاييس بعد في طلباتنا. المصدر الوحيد لبعض المعلومات على الأقل من هذه المستويات هو السجلات.
بضع نقاط.
أولاً ، اكتب السجلات المنظمة. لا حاجة لتضمين السياق في نص الرسالة. هذا يجعل من الصعب تجميعها وتحليلها. يستغرق Logstash وقتًا طويلاً لتطبيع كل هذا.
ثانيا ، استخدم مستويات الخطورة بشكل صحيح. كل لغة لها معيارها الخاص. أنا شخصياً أميز بين أربعة مستويات:
- لا خطأ
- خطأ جانب العميل
- خطأ في صالحنا ، نحن لا نخسر المال ، نحن لا نتحمل المخاطر ؛
- الخطأ في صالحنا ، نحن نخسر المال.
أنا ألخص. من الضروري محاولة إنشاء المراقبة بدقة من منطق العمل. حاول مراقبة التطبيق نفسه والعمل باستخدام مقاييس مثل عدد المبيعات وعدد تسجيلات المستخدمين الجدد وعدد المستخدمين النشطين حاليًا وما إلى ذلك.
إذا كان عملك بالكامل عبارة عن زر واحد في متصفحك ، فأنت بحاجة إلى مراقبة ما إذا كان يتم الضغط عليه ويعمل بشكل صحيح. كل شيء آخر غير مهم.
إذا لم يكن لديك هذا ، يمكنك محاولة اللحاق به في سجلات التطبيق وسجلات Nginx وما إلى ذلك ، كما فعلنا. يجب أن تكون أقرب ما يكون إلى التطبيق.
تعد مقاييس نظام التشغيل مهمة بالطبع ، لكنها ليست مثيرة للاهتمام بالنسبة للأعمال التجارية ، ولا ندفع مقابلها.