اسمي أنطون بدرين. أعمل في مركز التكنولوجيا العالية وأقوم بإدارة النظام. قبل شهر، انتهى مؤتمر شركتنا، حيث شاركنا خبرتنا المتراكمة مع مجتمع تكنولوجيا المعلومات في مدينتنا. تحدثت عن مراقبة تطبيقات الويب. كانت المادة مخصصة للمبتدئين أو المستوى المتوسط، الذين لم يبنوا هذه العملية من الصفر.
حجر الزاوية في أي نظام مراقبة هو حل مشاكل العمل. المراقبة من أجل المراقبة لا تهم أحدا. ماذا يريد رجال الأعمال؟ بحيث يعمل كل شيء بسرعة ودون أخطاء. تريد الشركات أن تكون استباقية، حتى نتمكن بأنفسنا من تحديد المشكلات في الخدمة وإصلاحها في أسرع وقت ممكن. هذه، في الواقع، هي المشكلات التي قمت بحلها طوال العام الماضي في مشروع لأحد عملائنا.
نبذة عن المشروع
يعد المشروع أحد أكبر برامج الولاء في البلاد. نحن نساعد سلاسل البيع بالتجزئة على زيادة وتيرة المبيعات من خلال أدوات التسويق المختلفة مثل بطاقات المكافآت. في المجمل، يتضمن المشروع 14 تطبيقًا تعمل على عشرة خوادم.
أثناء عملية المقابلة، لاحظت مرارًا وتكرارًا أن المسؤولين لا يتعاملون دائمًا مع مراقبة تطبيقات الويب بشكل صحيح: لا يزال الكثير منهم يركزون على مقاييس نظام التشغيل ويراقبون الخدمات أحيانًا.
في حالتي، كان نظام مراقبة العميل يعتمد سابقًا على Icinga. لم يحل المشاكل المذكورة أعلاه بأي شكل من الأشكال. في كثير من الأحيان، أبلغنا العميل نفسه عن المشاكل، وفي أغلب الأحيان، لم يكن لدينا ما يكفي من البيانات للوصول إلى السبب.
وبالإضافة إلى ذلك، كان هناك فهم واضح لعدم جدوى مواصلة تطويره. أعتقد أن أولئك الذين يعرفون Icinga سيفهمونني. لذلك، قررنا إعادة تصميم نظام مراقبة تطبيقات الويب للمشروع بالكامل.
محب العمل
لقد اخترنا بروميثيوس بناءً على ثلاثة مؤشرات رئيسية:
- عدد كبير من المقاييس المتاحة. في حالتنا هناك 60 ألف منهم. بالطبع، تجدر الإشارة إلى أننا لا نستخدم الغالبية العظمى منها (ربما حوالي 95٪). ومن ناحية أخرى، فهي كلها رخيصة نسبيا. بالنسبة لنا، هذا هو الطرف الآخر مقارنةً بـ Icinga المستخدم سابقًا. في ذلك، كانت إضافة المقاييس بمثابة ألم خاص: فالمقاييس الموجودة كانت باهظة الثمن (فقط انظر إلى الكود المصدري لأي مكون إضافي). كان أي مكون إضافي عبارة عن برنامج نصي بلغة Bash أو Python، ويكون إطلاقه مكلفًا من حيث الموارد المستهلكة.
- يستهلك هذا النظام كمية صغيرة نسبيًا من الموارد. 600 ميجا بايت من ذاكرة الوصول العشوائي (RAM)، و15% من نواة واحدة وبضع عشرات من عمليات IOPS كافية لجميع مقاييسنا. بالطبع، يتعين عليك تشغيل مصدري المقاييس، ولكنهم جميعًا مكتوبون بلغة Go وهم أيضًا ليسوا متعطشين جدًا للطاقة. لا أعتقد أن هذه مشكلة في الواقع الحديث.
- يوفر القدرة على الهجرة إلى Kubernetes. وبالنظر إلى خطط العميل، فإن الاختيار واضح.
ELK
في السابق، لم نقم بجمع السجلات أو معالجتها. وأوجه القصور واضحة للجميع. لقد اخترنا ELK لأنه لدينا بالفعل خبرة في هذا النظام. نقوم فقط بتخزين سجلات التطبيقات هناك. وكانت معايير الاختيار الرئيسية هي البحث عن النص الكامل وسرعته.
كليكهاوس
في البداية، وقع الاختيار على InfluxDB. لقد أدركنا الحاجة إلى جمع سجلات Nginx والإحصائيات من pg_stat_statements وتخزين بيانات Prometheus التاريخية. لم نحب Influx لأنه بدأ بشكل دوري في استهلاك كمية كبيرة من الذاكرة وتعطل. بالإضافة إلى ذلك، أردت تجميع الاستعلامات عن طريق Remote_addr، ولكن التجميع في نظام إدارة قواعد البيانات هذا يتم فقط عن طريق العلامات. العلامات باهظة الثمن (الذاكرة)، وعددها محدود بشكل مشروط.
لقد بدأنا بحثنا مرة أخرى. ما كان مطلوبًا هو قاعدة بيانات تحليلية مع الحد الأدنى من استهلاك الموارد، ويفضل أن يكون ذلك مع ضغط البيانات على القرص.
Clickhouse يلبي كل هذه المعايير، ولم نندم أبدًا على اختيارنا. نحن لا نكتب أي كميات غير عادية من البيانات فيه (عدد الإدخالات يبلغ حوالي خمسة آلاف فقط في الدقيقة).
NewRelic
لقد كانت NewRelic معنا تاريخيًا لأنها كانت اختيار العميل. نحن نستخدمه باعتباره APM.
Zabbix
نحن نستخدم Zabbix حصريًا لمراقبة الصندوق الأسود لواجهات برمجة التطبيقات المختلفة.
تحديد نهج الرصد
أردنا تحليل المهمة وبالتالي تنظيم نهج المراقبة.
وللقيام بذلك، قمت بتقسيم نظامنا إلى المستويات التالية:
- الأجهزة ونظام إدارة الفيديو؛
- نظام التشغيل؛
- خدمات النظام، ومكدس البرمجيات؛
- طلب؛
- منطق الأعمال.
لماذا هذا النهج مناسب:
- نحن نعرف من هو المسؤول عن عمل كل مستوى، وبناءً على ذلك يمكننا إرسال التنبيهات؛
- يمكننا استخدام البنية عند منع التنبيهات - سيكون من الغريب إرسال تنبيه حول عدم توفر قاعدة البيانات عندما يكون الجهاز الظاهري ككل غير متاح.
وبما أن مهمتنا هي تحديد الانتهاكات في تشغيل النظام، فيجب علينا في كل مستوى تسليط الضوء على مجموعة معينة من المقاييس التي تستحق الاهتمام بها عند كتابة قواعد التنبيه. بعد ذلك، دعنا ننتقل إلى مستويات "VMS" و"نظام التشغيل" و"خدمات النظام، حزمة البرامج".
الأجهزة الظاهرية
الاستضافة تخصص لنا المعالج والقرص والذاكرة والشبكة. وكان لدينا مشاكل مع الأولين. إذن المقاييس:
الوقت المسروق لوحدة المعالجة المركزية - عندما تشتري جهازًا افتراضيًا على Amazon (t2.micro، على سبيل المثال)، يجب أن تفهم أنه لا يتم تخصيص نواة معالج كاملة لك، ولكن حصة من وقته فقط. وعندما تستنفده، سيتم أخذ المعالج منك.
يتيح لك هذا المقياس تتبع مثل هذه اللحظات واتخاذ القرارات. على سبيل المثال، هل من الضروري اتخاذ تعريفة أكبر أو توزيع معالجة مهام الخلفية وطلبات واجهة برمجة التطبيقات (API) على خوادم مختلفة؟
IOPS + CPU في انتظار الوقت - لسبب ما، تخطئ العديد من الاستضافة السحابية من خلال عدم توفير ما يكفي من IOPS. علاوة على ذلك، فإن الجدول الزمني ذو IOPS المنخفض ليس حجة لهم. لذلك، فإن الأمر يستحق جمع وحدة المعالجة المركزية iwait. باستخدام هذا الزوج من الرسوم البيانية - مع انخفاض عمليات IOPS وانتظار الإدخال/الإخراج العالي - يمكنك بالفعل التحدث إلى الاستضافة وحل المشكلة.
نظام التشغيل
مقاييس نظام التشغيل:
- مقدار الذاكرة المتاحة في٪؛
- نشاط استخدام المبادلة: مبادلة vmstat، المبادلة؛
- عدد inodes المتاحة والمساحة الحرة على نظام الملفات في٪
- متوسط الحمل
- عدد الاتصالات في حالتين؛
- كونتراكت امتلاء الجدول.
- يمكن مراقبة جودة الشبكة باستخدام الأداة المساعدة ss، وحزمة iproute2 - احصل على مؤشر اتصالات RTT من مخرجاتها وقم بتجميعها حسب المنفذ الوجهة.
أيضًا على مستوى نظام التشغيل لدينا كيان مثل العمليات. من المهم أن نحدد في النظام مجموعة من العمليات التي تلعب دورًا مهمًا في تشغيله. على سبيل المثال، إذا كان لديك العديد من مجموعات pgpools، فأنت بحاجة إلى جمع المعلومات لكل منها.
مجموعة المقاييس هي كما يلي:
- وحدة المعالجة المركزية؛
- الذاكرة مقيمة في المقام الأول؛
- 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، وما إلى ذلك، كما فعلنا. يجب أن تكون قريبًا من التطبيق قدر الإمكان.
تعد مقاييس نظام التشغيل مهمة بالطبع، لكن الشركات ليست مهتمة بها، ولا ندفع لنا مقابلها.
المصدر: www.habr.com