جمعة سعيدة للجميع! أيها الأصدقاء، اليوم نواصل سلسلة المنشورات المخصصة للدورة لأن الدروس في المجموعة الجديدة للدورة ستبدأ نهاية الأسبوع القادم. لذلك، دعونا نبدأ!
المراقبة هي فقط. هذا أمر معروف. أظهر Nagios، وقم بتشغيل NRPE على النظام البعيد، وقم بتكوين Nagios على منفذ NRPE TCP رقم 5666 وستصبح لديك مراقبة.
إنه أمر سهل للغاية وليس مثيرًا للاهتمام. الآن لديك المقاييس الأساسية لوقت وحدة المعالجة المركزية والنظام الفرعي للقرص وذاكرة الوصول العشوائي، والتي يتم توفيرها افتراضيًا إلى Nagios وNRPE. لكن هذا ليس في الواقع "رصدًا" في حد ذاته. هذه ليست سوى البداية.
(عادةً ما يقومون بتثبيت PNP4Nagios وRRDtool وThruk، وإعداد الإشعارات في Slack والانتقال مباشرة إلى nagiosexchange، ولكن دعونا نترك ذلك في الوقت الحالي).
مراقبة جيدة هو في الواقع معقد للغاية، فأنت تحتاج حقًا إلى معرفة الأجزاء الداخلية للتطبيق الذي تراقبه.
هل المراقبة صعبة؟
أي خادم، سواء كان Linux أو Windows، سيخدم بحكم تعريفه غرضًا ما. Apache، وSamba، وTomcat، وتخزين الملفات، وLDAP - كل هذه الخدمات فريدة إلى حد ما من جانب واحد أو أكثر. لكل منها وظيفتها الخاصة، وخصائصها الخاصة. هناك طرق مختلفة للحصول على المقاييس ومؤشرات الأداء الرئيسية (KPIs) التي تهمك عندما يكون الخادم تحت التحميل.
مؤلف الصورة في
(أتمنى لو كانت لوحات العدادات الخاصة بي باللون الأزرق النيون - تنهد حالمًا -... حسنًا ...)
يجب أن يكون لدى أي برنامج يقدم خدمات آلية لجمع المقاييس. أباتشي لديه وحدة نمطية mod-status، عرض صفحة حالة الخادم. إنجينكس لديه - stub_status. يحتوي Tomcat على JMX أو تطبيقات الويب المخصصة التي تعرض المقاييس الأساسية. يحتوي MySQL على أمر "إظهار الحالة العامة" وما إلى ذلك.
فلماذا لا يبني المطورون آليات مماثلة في التطبيقات التي يقومون بإنشائها؟
هل المطورين فقط هم من يفعلون هذا؟
لا يقتصر مستوى معين من اللامبالاة تجاه تضمين المقاييس على المطورين. لقد عملت في شركات حيث قاموا بتطوير التطبيقات باستخدام Tomcat ولم يقدموا أيًا من المقاييس الخاصة بهم، ولا سجلات لأنشطة الخدمة، باستثناء سجلات أخطاء Tomcat العامة. يقوم بعض المطورين بإنشاء الكثير من السجلات التي لا تعني شيئًا لمسؤول النظام الذي لم يحالفه الحظ لقراءتها في الساعة 3:15 صباحًا.
مؤلف الصورة في
يجب أيضًا على مهندسي النظام الذين يقومون بتمكين إصدار هذه المنتجات أن يتحملوا بعض المسؤولية عن الموقف. قليل من مهندسي الأنظمة لديهم الوقت أو الاهتمام لمحاولة استخراج مقاييس ذات معنى من السجلات، دون سياق تلك المقاييس والقدرة على تفسيرها في ضوء نشاط التطبيق. البعض لا يفهم كيف يمكنهم الاستفادة منه، بخلاف مؤشرات "هناك خطأ حاليًا (أو سيكون قريبًا)".
إن التغيير في التفكير فيما يتعلق بالحاجة إلى المقاييس يجب أن يحدث ليس فقط بين المطورين، ولكن أيضًا بين مهندسي الأنظمة.
بالنسبة لأي مهندس أنظمة لا يحتاج إلى الاستجابة للأحداث المهمة فحسب، بل يجب عليه أيضًا التأكد من عدم حدوثها، فإن الافتقار إلى المقاييس عادة ما يكون عائقًا أمام القيام بذلك.
ومع ذلك، لا يتلاعب مهندسو الأنظمة عادةً بالأكواد البرمجية لكسب المال لشركتهم. إنهم بحاجة إلى مطورين رئيسيين يدركون أهمية مسؤولية مهندس الأنظمة في تحديد المشكلات وزيادة الوعي بقضايا الأداء وما شابه.
هذا شيء يبتكر
تصف عقلية المطورين التآزر بين تفكير التطوير (dev) والعمليات (ops). يجب على أي شركة تدعي "القيام بأعمال التطوير" أن تقوم بما يلي:
- قول أشياء ربما لا يفعلونها (في إشارة إلى ميم The Princess Bride - "لا أعتقد أن هذا يعني ما تعتقد أنه يعنيه!")
- تشجيع موقف التحسين المستمر للمنتج.
لا يمكنك تحسين منتج ما وتعرف أنه قد تم تحسينه إذا كنت لا تعرف كيفية عمله حاليًا. لا يمكنك معرفة كيفية عمل المنتج إذا كنت لا تفهم كيفية عمل مكوناته والخدمات التي يعتمد عليها ونقاط الضعف الرئيسية والاختناقات.
إذا لم تراقب الاختناقات المحتملة، فلن تتمكن من اتباع تقنية اللماذات الخمس عند كتابة تقرير ما بعد الوفاة. لن تتمكن من وضع كل شيء على شاشة واحدة لترى كيف يعمل المنتج أو تعرف كيف يبدو "طبيعيًا وسعيدًا".
تحول لليسار، لليسار، قلت لي--
بالنسبة لي، أحد المبادئ الأساسية لـ Devops هو "التحول إلى اليسار". التحول إلى اليسار في هذا السياق يعني تحويل الاحتمال (لا تتحمل أية مسؤولية، ولكن القدرات فقط) للقيام بالأشياء التي يهتم بها عادةً مهندسو الأنظمة، مثل إنشاء مقاييس الأداء، واستخدام السجلات بشكل أكثر كفاءة، وما إلى ذلك، على اليسار في دورة حياة تسليم البرامج.
مؤلف الصورة في
يجب أن يكون مطورو البرامج قادرين على استخدام ومعرفة أدوات المراقبة التي تستخدمها الشركة من أجل تنفيذ المراقبة بجميع أشكالها ومقاييسها وتسجيلها وواجهات المراقبة، والأهم من ذلك، شاهد كيف يعمل منتجهم في الإنتاج. لا يمكنك جعل المطورين يستثمرون الجهد والوقت في المراقبة حتى يتمكنوا من رؤية المقاييس والتأثير على شكلها، وكيف يقدمها مالك المنتج إلى CTO في الإحاطة التالية، وما إلى ذلك.
باختصار
- قيادة الحصان الخاص بك إلى الماء. أظهر للمطورين مقدار المشاكل التي يمكنهم تجنبها لأنفسهم، وساعدهم على تحديد مؤشرات الأداء الرئيسية والمقاييس المناسبة لتطبيقاتهم بحيث يكون هناك صراخ أقل من مالك المنتج الذي يصرخ عليه مدير التكنولوجيا التنفيذي. أدخلهم إلى النور بلطف وهدوء. إذا لم ينجح ذلك، فقم برشوتهم وتهديدهم وإقناعهم أو مالك المنتج بتنفيذ الحصول على هذه المقاييس من التطبيقات في أسرع وقت ممكن، ثم ارسم المخططات. سيكون هذا أمرًا صعبًا لأنه لن يُنظر إليه على أنه أولوية وستتضمن خارطة طريق المنتج العديد من المشاريع المدرة للدخل المعلقة. ولذلك، ستحتاج إلى دراسة جدوى لتبرير الوقت والنفقات التي يتم إنفاقها في تنفيذ المراقبة في المنتج.
- ساعد مهندسي النظام في الحصول على ليلة نوم جيدة. أظهر لهم أن استخدام قائمة التحقق "دعونا نصدر" لأي منتج يتم إصداره هو أمر جيد. والتأكد من تغطية جميع التطبيقات قيد الإنتاج بالمقاييس سيساعدك على النوم بشكل أفضل في الليل من خلال السماح للمطورين بمعرفة الأخطاء التي تحدث وأين. ومع ذلك، فإن الطريقة الصحيحة لإثارة وإحباط أي مطور أو مالك منتج أو مدير تكنولوجيا تنفيذي هي المثابرة والمقاومة. سيؤثر هذا السلوك على تاريخ إصدار أي منتج إذا انتظرت حتى اللحظة الأخيرة مرة أخرى، لذا انتقل إلى اليسار مرة أخرى وقم بإدراج هذه المشكلات في خطة مشروعك في أقرب وقت ممكن. إذا لزم الأمر، توجه إلى اجتماعات المنتج. ارتدي شاربًا وشعرًا مزيفًا أو شيء من هذا القبيل، فلن يفشل أبدًا. قم بتوصيل مخاوفك، وإظهار الفوائد الواضحة، والتبشير.
- تأكد من أن كلاً من التطوير (dev) والعمليات (ops) يفهمان معنى وعواقب مقاييس المنتج التي تنتقل إلى المنطقة الحمراء. لا تترك Ops كالوصي الوحيد على صحة المنتج، وتأكد من مشاركة المطورين أيضًا (#productsquads).
- تعد السجلات أمرًا رائعًا، وكذلك المقاييس. اجمعها ولا تدع سجلاتك تصبح قمامة في كرة مشتعلة ضخمة من عدم الفائدة. اشرح للمطورين وأظهر لهم سبب عدم فهم أي شخص آخر لسجلاتهم، وأظهر لهم كيف يبدو الأمر عند النظر إلى السجلات غير المفيدة في الساعة 3:15 صباحًا.
مؤلف الصورة في
هذا كل شئ. سيتم إصدار مواد جديدة الأسبوع المقبل. إذا كنت ترغب في معرفة المزيد عن الدورة، فنحن ندعوك لذلك ، والتي ستقام يوم الاثنين. والآن نحن تقليديا ننتظر تعليقاتك.
المصدر: www.habr.com