هل ماتت المراقبة؟ - مراقبة طويلة الأمد

منذ عام 2008، تعمل شركتنا بشكل أساسي في إدارة البنية التحتية والدعم الفني على مدار الساعة لمشاريع الويب: لدينا أكثر من 400 عميل، وهو ما يمثل حوالي 15٪ من التجارة الإلكترونية الروسية. وبناء على ذلك، يتم دعم بنية متنوعة للغاية. إذا سقط شيء ما، فنحن ملزمون بإصلاحه في غضون 15 دقيقة. ولكن لفهم وقوع حادث، تحتاج إلى مراقبة المشروع والاستجابة للحوادث. كيف نفعل ذلك؟

أعتقد أن هناك مشكلة في تنظيم نظام مراقبة مناسب. لو لم تكن هناك مشكلة، لكان خطابي يتألف من أطروحة واحدة: "الرجاء تثبيت Prometheus + Grafana والمكونات الإضافية 1، 2، 3". لسوء الحظ، فإنه لا يعمل بهذه الطريقة بعد الآن. والمشكلة الرئيسية هي أن الجميع ما زالوا يؤمنون بشيء كان موجودا في عام 2008، من حيث مكونات البرمجيات.

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

لقد واجهنا جميعًا قصة مثل ما يلي: أحد المطورين، مسؤول معين يعمل، يأتي فريق التطوير إليهم ويقول - "لقد أطلق سراحنا، والآن نراقب". مراقبة ماذا؟ كيف تعمل؟

نعم. نحن نراقب بالطريقة القديمة. وهي تتغير بالفعل، واتضح أنك راقبت الخدمة أ، التي أصبحت الخدمة ب، والتي تتفاعل مع الخدمة ج. لكن فريق التطوير يقول لك: "قم بتثبيت البرنامج، يجب أن يراقب كل شيء!"

إذن ما الذي تغير؟ - كل شئ تغير!

2008 كل شيء على ما يرام

هناك اثنين من المطورين، خادم واحد، خادم قاعدة بيانات واحد. كل شيء يذهب من هنا. لدينا بعض المعلومات، نقوم بتثبيت zabbix، Nagios، cacti. ثم نقوم بتعيين تنبيهات واضحة على وحدة المعالجة المركزية، وعلى تشغيل القرص، وعلى مساحة القرص. نقوم أيضًا بإجراء بعض الفحوصات اليدوية للتأكد من استجابة الموقع ووصول الطلبات إلى قاعدة البيانات. وهذا كل شيء – نحن محميون بشكل أو بآخر.

إذا قارنا حجم العمل الذي قام به المسؤول لتوفير المراقبة، فسنجد أن 98% منه كان تلقائيًا: يجب على الشخص الذي يقوم بالمراقبة أن يفهم كيفية تثبيت Zabbix، وكيفية تكوينه وتكوين التنبيهات. و2% - للفحوصات الخارجية: أن يستجيب الموقع ويقدم طلبًا إلى قاعدة البيانات، وأن الطلبات الجديدة قد وصلت.

2010 الحمل ينمو

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

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

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

ملحوظة: كتبت "مجموعة النصوص" 3 مرات. أي أن الشخص المسؤول عن المراقبة لم يعد هو الذي يقوم ببساطة بتثبيت zabbix. هذا هو الشخص الذي يبدأ البرمجة. لكن لم يتغير شيء في أذهان الفريق حتى الآن.

لكن العالم يتغير، ويصبح أكثر تعقيدا. تمت إضافة طبقة افتراضية والعديد من الأنظمة الجديدة. يبدأون في التفاعل مع بعضهم البعض. من قال "تنبعث منه رائحة الخدمات الصغيرة؟" لكن كل خدمة لا تزال تبدو وكأنها موقع ويب على حدة. يمكننا أن ننتقل إليه ونفهم أنه يوفر المعلومات اللازمة ويعمل من تلقاء نفسه. وإذا كنت مسؤولاً منخرطًا باستمرار في مشروع تم تطويره لمدة 5-7-10 سنوات، فإن هذه المعرفة تتراكم: يظهر مستوى جديد - لقد أدركته، ويظهر مستوى آخر - لقد أدركته...

لكن نادرًا ما يرافق أي شخص مشروعًا لمدة 10 سنوات.

السيرة الذاتية لرجل الرصد

لنفترض أنك أتيت إلى شركة ناشئة جديدة قامت على الفور بتعيين 20 مطورًا، وكتبت 15 خدمة صغيرة، وقيل لك: "قم ببناء CI/CD. لو سمحت." لقد قمت ببناء CI/CD وفجأة تسمع: "من الصعب علينا العمل مع الإنتاج في "مكعب"، دون فهم كيفية عمل التطبيق فيه. اصنع لنا صندوق رمل في نفس "المكعب".
يمكنك إنشاء صندوق رمل في هذا المكعب. يقولون لك على الفور: "نريد قاعدة بيانات مرحلية يتم تحديثها كل يوم من الإنتاج، حتى نفهم أنها تعمل على قاعدة البيانات، ولكن في نفس الوقت لا تفسد قاعدة بيانات الإنتاج".

أنت تعيش في كل هذا. بقي أسبوعين قبل الإصدار، يقولون لك: "الآن دعونا نراقب كل هذا..." أي. مراقبة البنية التحتية للمجموعة، ومراقبة بنية الخدمات الصغيرة، ومراقبة العمل مع الخدمات الخارجية...

ويخرج زملائي المخطط المعتاد من رؤوسهم ويقولون: "حسنًا، كل شيء واضح هنا! " قم بتثبيت برنامج يراقب كل هذا. نعم، نعم: بروميثيوس + جرافانا + الإضافات.
ويضيفون: "أمامك أسبوعان، للتأكد من أن كل شيء آمن".

في الكثير من المشاريع التي نراها، يتم تخصيص شخص واحد للمراقبة. تخيل أننا نريد تعيين شخص للقيام بالمراقبة لمدة أسبوعين، ونكتب له سيرة ذاتية. ما هي المهارات التي يجب أن يتمتع بها هذا الشخص، في ضوء كل ما قلناه حتى الآن؟

• يجب عليه أن يفهم مراقبة وتفاصيل تشغيل البنية التحتية الحديدية.
• يجب أن يفهم تفاصيل مراقبة Kubernetes (والجميع يريد الذهاب إلى "المكعب"، لأنه يمكنك التجريد من كل شيء، والاختباء، لأن المسؤول سيتعامل مع الباقي) - نفسه، والبنية التحتية الخاصة به، وفهم كيفية مراقبة التطبيقات داخل.
• ويجب عليه أن يفهم أن الخدمات تتواصل مع بعضها البعض بطرق خاصة، وأن يعرف تفاصيل كيفية تفاعل الخدمات مع بعضها البعض. من الممكن تمامًا رؤية مشروع تتواصل فيه بعض الخدمات بشكل متزامن، لأنه لا توجد طريقة أخرى. على سبيل المثال، تنتقل الواجهة الخلفية عبر REST، عبر gRPC إلى خدمة الكتالوج، وتتلقى قائمة بالمنتجات وتعيدها مرة أخرى. لا يمكنك الانتظار هنا. ومع الخدمات الأخرى يعمل بشكل غير متزامن. قم بنقل الطلب إلى خدمة التوصيل، وإرسال خطاب، وما إلى ذلك.
  ربما كنت قد سبحت بالفعل من كل هذا؟ وأصبح المسؤول الذي يحتاج إلى مراقبة ذلك أكثر حيرة.
• يجب أن يكون قادرًا على التخطيط والتخطيط بشكل صحيح - مع تزايد العمل.
• ولذلك يجب عليه إنشاء استراتيجية من الخدمة التي تم إنشاؤها لفهم كيفية مراقبتها على وجه التحديد. يحتاج إلى فهم بنية المشروع وتطوره + فهم التقنيات المستخدمة في التطوير.

دعونا نتذكر حالة عادية تمامًا: بعض الخدمات موجودة في PHP، وبعض الخدمات موجودة في Go، وبعض الخدمات موجودة في JS. إنهم يعملون بطريقة أو بأخرى مع بعضهم البعض. ومن هنا يأتي مصطلح "الخدمة المصغرة": هناك العديد من الأنظمة الفردية التي لا يستطيع المطورون فهم المشروع ككل. يقوم أحد أعضاء الفريق بكتابة خدمات في JS تعمل من تلقاء نفسها ولا تعرف كيف يعمل باقي النظام. الجزء الآخر يكتب الخدمات بلغة بايثون ولا يتدخل في كيفية عمل الخدمات الأخرى، فهي معزولة في منطقتها الخاصة. والثالث هو كتابة الخدمات بلغة PHP أو أي شيء آخر.
كل هؤلاء الأشخاص العشرين مقسمون إلى 20 خدمة، ولا يوجد سوى مسؤول واحد يجب أن يفهم كل هذا. قف! قمنا فقط بتقسيم النظام إلى 15 خدمة صغيرة لأن 15 شخصًا لا يمكنهم فهم النظام بأكمله.

لكن يجب مراقبته بطريقة أو بأخرى..

ما هي النتيجة؟ ونتيجة لذلك، هناك شخص واحد يأتي بكل ما لا يستطيع فريق المطورين بأكمله فهمه، وفي الوقت نفسه يجب عليه أيضًا أن يعرف ويكون قادرًا على القيام بما أشرنا إليه أعلاه - البنية التحتية للأجهزة، والبنية التحتية لـ Kubernetes، وما إلى ذلك.

ماذا يمكنني أن أقول... هيوستن، لدينا مشاكل.

إن مراقبة مشروع برمجي حديث هو مشروع برمجي في حد ذاته

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

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

وإذا أعطيت هذا أيضًا للمسؤول والمطورين في المرحلة التي يتبقى فيها وقت قصير قبل الإصدار، فسيحتاج الشخص إلى فهم هذا البروتوكول بالكامل. أولئك. يستغرق مشروع بهذا الحجم قدرًا كبيرًا من الوقت، ويجب أن يؤخذ ذلك في الاعتبار عند تطوير النظام.
لكن في كثير من الأحيان، وخاصة في الشركات الناشئة، نرى كيف يتم تأجيل المراقبة إلى وقت لاحق. "الآن سنقوم بعمل إثبات للمفهوم، وسننطلق به، ونتركه يسقط - ونحن على استعداد للتضحية. ومن ثم سنراقب كل شيء”. عندما (أو إذا) بدأ المشروع في جني الأموال، تريد الشركة إضافة المزيد من الميزات - لأنه بدأ العمل، لذلك يجب طرحه بشكل أكبر! وأنت في النقطة التي تحتاج فيها أولاً إلى مراقبة كل ما سبق، الأمر الذي لا يستغرق 1% من الوقت، بل أكثر من ذلك بكثير. وبالمناسبة، ستكون هناك حاجة للمطورين للمراقبة، ومن الأسهل السماح لهم بالعمل على الميزات الجديدة. ونتيجة لذلك، تتم كتابة ميزات جديدة، ويصبح كل شيء سيء، وأنت في طريق مسدود لا نهاية له.

فكيف تراقب مشروعًا بدءًا من البداية، وماذا تفعل إذا حصلت على مشروع يحتاج إلى مراقبة، لكنك لا تعرف من أين تبدأ؟

أولا، تحتاج إلى التخطيط.

الاستطراد الغنائي: غالبًا ما يبدأون بمراقبة البنية التحتية. على سبيل المثال، لدينا Kubernetes. لنبدأ بتثبيت Prometheus مع Grafana، وتثبيت المكونات الإضافية لمراقبة "المكعب". ليس فقط المطورين، ولكن أيضًا المسؤولين لديهم ممارسة مؤسفة تتمثل في: "سنقوم بتثبيت هذا المكون الإضافي، ولكن من المحتمل أن يعرف المكون الإضافي كيفية القيام بذلك". يحب الناس أن يبدأوا بالأشياء البسيطة والمباشرة، بدلاً من البدء بالأفعال المهمة. ومراقبة البنية التحتية سهلة.

أولاً، حدد ماذا وكيف تريد مراقبته، ثم حدد الأداة، لأن الآخرين لا يستطيعون التفكير نيابةً عنك. وهل يجب عليهم ذلك؟ فكر أشخاص آخرون في أنفسهم حول نظام عالمي - أو لم يفكروا على الإطلاق عند كتابة هذا البرنامج المساعد. وحقيقة أن هذا البرنامج المساعد لديه 5 آلاف مستخدم لا يعني أنه ذو فائدة على الإطلاق. ربما ستصبح رقم 5001 لمجرد أنه كان هناك بالفعل 5000 شخص من قبل.

إذا بدأت في مراقبة البنية التحتية وتوقفت الواجهة الخلفية لتطبيقك عن الاستجابة، فسيفقد جميع المستخدمين الاتصال بتطبيق الهاتف المحمول. سوف يظهر خطأ. سوف يأتون إليك ويقولون "التطبيق لا يعمل، ماذا تفعل هنا؟" - "نحن نراقب". — “كيف تراقب إذا كنت لا ترى أن التطبيق لا يعمل؟!”

1. أعتقد أنك بحاجة إلى البدء في المراقبة من نقطة دخول المستخدم تمامًا. إذا لم يرى المستخدم أن التطبيق يعمل، فهذا كل شيء، إنه فشل. ويجب على نظام المراقبة التحذير من هذا أولاً.
2. وعندها فقط يمكننا مراقبة البنية التحتية. أو القيام بذلك بالتوازي. الأمر أسهل مع البنية التحتية - هنا يمكننا أخيرًا تثبيت zabbix.
3. والآن عليك أن تذهب إلى جذور التطبيق لفهم أين لا تعمل الأمور.

فكرتي الرئيسية هي أن المراقبة يجب أن تتم بالتوازي مع عملية التطوير. إذا قمت بتشتيت فريق المراقبة للقيام بمهام أخرى (إنشاء CI/CD، وضع الحماية، إعادة تنظيم البنية التحتية)، ستبدأ المراقبة في التباطؤ وقد لا تتمكن أبدًا من اللحاق بالتطور (أو سيتعين عليك إيقافه عاجلاً أم آجلاً).

كل شيء حسب المستويات

هذه هي الطريقة التي أرى بها تنظيم نظام المراقبة.

1) مستوى التطبيق:

• مراقبة منطق عمل التطبيق؛
• ومراقبة المقاييس الصحية للخدمات؛
• مراقبة التكامل.

2) مستوى البنية التحتية:

• مراقبة مستوى التنسيق؛
• مراقبة برامج النظام؛
• مراقبة مستوى الحديد.

3) مرة أخرى مستوى التطبيق - ولكن كمنتج هندسي:

• جمع ومراقبة سجلات التطبيق؛
• إيه بي إم؛
• اقتفاء أثر.

4) التنبيه:

• تنظيم نظام الإنذار.
• تنظيم نظام الواجب؛
• تنظيم "قاعدة معرفية" وسير العمل لمعالجة الحوادث.

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

طبقة التطبيق - مراقبة منطق الأعمال

نحن هنا نتحدث عن التحقق من حقيقة أن التطبيق يعمل لصالح المستخدم.

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

عندما يُطلب من المبرمجين في كثير من الأحيان مراقبة الصفحة الرئيسية للتأكد من عمل الموقع، فإنهم يقدمون مقبضًا يمكن سحبه في كل مرة يحتاجون فيها للتأكد من عمل واجهة برمجة التطبيقات (API). ولا يزال المبرمجون في هذه اللحظة يأخذون ويكتبون /api/test/helloworld
الطريقة الوحيدة للتأكد من أن كل شيء يعمل؟ - لا!

• إن إنشاء مثل هذه الاختبارات هو في الأساس مهمة المطورين. يجب كتابة اختبارات الوحدة بواسطة المبرمجين الذين يكتبون الكود. لأنه إذا قمت بتسريبها إلى المشرف، "يا صديقي، إليك قائمة ببروتوكولات API لجميع الوظائف الـ 25، يرجى مراقبة كل شيء!" - لن ينجح شيء.
• إذا قمت بطباعة "hello World"، فلن يعرف أحد أبدًا أن واجهة برمجة التطبيقات (API) يجب أن تعمل وتعمل بالفعل. يجب أن يؤدي كل تغيير في واجهة برمجة التطبيقات (API) إلى تغيير في عمليات التحقق.
• إذا كان لديك بالفعل مثل هذه المشكلة، فقم بإيقاف الميزات وتخصيص المطورين الذين سيكتبون هذه الشيكات، أو يقبلون الخسائر، ويقبلون أنه لم يتم التحقق من أي شيء وسوف يفشل.

نصائح فنية:

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

طبقة التطبيق - مراقبة المقاييس الصحية

نحن الآن نتحدث عن المقاييس الصحية الخارجية للخدمات.

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

كيفية تنفيذ ذلك بشكل صحيح من الناحية الفنية: تعرض كل خدمة نقطة نهاية حول أدائها الحالي، وفي الرسوم البيانية لـ Grafana (أو أي تطبيق آخر) نرى حالة جميع الخدمات.

• يجب أن يؤدي كل تغيير في واجهة برمجة التطبيقات (API) إلى تغيير في عمليات التحقق.
• قم بإنشاء خدمة جديدة على الفور باستخدام المقاييس الصحية.
• يمكن للمسؤول أن يأتي إلى المطورين ويطلب منهم "أضف لي بعض الميزات حتى أفهم كل شيء وأضيف معلومات حول هذا إلى نظام المراقبة الخاص بي". لكن المطورين عادة ما يجيبون: "لن نضيف أي شيء قبل أسبوعين من الإصدار".
  دع مديري التطوير يعرفون أنه ستكون هناك مثل هذه الخسائر، دع إدارة مديري التطوير تعلم أيضًا. لأنه عندما يسقط كل شيء، سيظل هناك من يتصل ويطالب بمراقبة «الخدمة المتساقطة باستمرار» (ج)
• بالمناسبة، قم بتخصيص المطورين لكتابة المكونات الإضافية لـ Grafana - وستكون هذه مساعدة جيدة للمسؤولين.

طبقة التطبيق - مراقبة التكامل

تركز مراقبة التكامل على مراقبة الاتصالات بين الأنظمة المهمة للأعمال.

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

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

ما أنصح بفعله:

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

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

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

طبقة البنية التحتية

تعتبر مراقبة البنية التحتية أمرًا يُنظر إليه منذ فترة طويلة على أنه مراقبة بحد ذاته.

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

مستوى التطبيق كوحدة أعمال

النقاط الرئيسية:

• الأيائل. هذا هو معيار الصناعة. إذا كنت لا تقوم بتجميع السجلات لسبب ما، فابدأ في القيام بذلك على الفور.
• APM. APMs الخارجية كوسيلة لإغلاق مراقبة التطبيقات بسرعة (NewRelic، BlackFire، Datadog). يمكنك تثبيت هذا الشيء مؤقتًا لفهم ما يحدث معك بطريقة أو بأخرى.
• اقتفاء أثر. في العشرات من الخدمات الصغيرة، عليك تتبع كل شيء، لأن الطلب لم يعد يعيش من تلقاء نفسه. من الصعب جدًا الإضافة لاحقًا، لذلك من الأفضل جدولة التتبع على الفور أثناء التطوير - وهذا هو عمل المطورين وفائدتهم. إذا لم تقم بتنفيذها بعد، قم بتنفيذها! انظر جايجر/زيبكين

تنبيه

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

كومة التكنولوجيا

لنتخيل أن مجموعتنا هي كما يلي:

• جمع البيانات - بروميثيوس + جرافانا؛
• تحليل السجل - ELK؛
• لـ APM أو التتبع - Jaeger (Zipkin).

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

بعض النقاط الفنية التي أراها في كل مكان مؤخرًا:

يتم دفع بروميثيوس داخل Kubernetes - من جاء بهذا؟! إذا تعطلت مجموعتك، ماذا ستفعل؟ إذا كان لديك مجموعة معقدة بالداخل، فيجب أن يكون هناك نوع من نظام المراقبة داخل المجموعة، وبعضها خارجها، والذي سيجمع البيانات من داخل المجموعة.

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

النتائج

• مراقبة التطوير لا تعني تثبيت الأدوات المساعدة، بل تطوير منتج برمجي. 98% من المراقبة اليوم عبارة عن ترميز. الترميز في الخدمات، وترميز الشيكات الخارجية، والتحقق من الخدمات الخارجية، وهذا كل شيء.
• لا تضيع وقت المطورين في المراقبة: يمكن أن يستغرق الأمر ما يصل إلى 30% من عملهم، لكن الأمر يستحق ذلك.
• أيها المطورون، لا تقلقوا من عدم قدرتكم على مراقبة شيء ما، لأن بعض الأشياء لها طريقة تفكير مختلفة تمامًا. لم تكن مبرمجًا، ومراقبة العمل هي بالضبط وظيفتهم.
• إذا كان المشروع قيد التشغيل بالفعل ولا تتم مراقبته (وأنت مدير)، فقم بتخصيص الموارد للمراقبة.
• إذا كان المنتج قيد الإنتاج بالفعل، وكنت أحد المطورين الذين طُلب منهم "إعداد المراقبة" - فحاول أن تشرح للإدارة ما كتبت عنه كل هذا.

هذه نسخة موسعة من التقرير المقدم في مؤتمر Saint Highload++.

إذا كنت مهتمًا بأفكاري وأفكاري حول هذا الموضوع والمواضيع ذات الصلة، فهنا يمكنك ذلك قراءة القناة ؟؟؟؟

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