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

مراقبة السيرفرات دون إغراق الفريق بالإنذارات

لوحة المراقبة مفيدة فقط إذا ساعدت شخصًا في اتخاذ إجراء. رسوم CPU وحدها لا تثبت قدرة العميل على تسجيل الدخول وإتمام معاملة.

Read in English
رسم توضيحي لموضوع البنية التحتية التقنية
محتويات هذا الدليل

راقب نتيجة العمل قبل حالة الجهاز

قد يعمل الخادم بينما يفشل التطبيق في تسجيل طلب، وقد ترتفع نسبة المعالج لحظيًا دون تأثير يلاحظه المستخدم. تربط المراقبة الجيدة بين مؤشرات البنية التحتية ونتيجة الخدمة، ويميز التنبيه بين عطل يحتاج تصرفًا الآن ومعلومة تصلح للمراجعة لاحقًا.

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

افصل الأعراض عن أدوات التشخيص

يعرض مرجع Google SRE زمن الاستجابة والحركة والأخطاء والتشبع كمؤشرات مفيدة للخدمات. طبقها على طبيعة النظام؛ فقد يكون عمر العمل المتراكم أهم من عدد طلبات HTTP في مهمة خلفية. افصل زمن الطلب الناجح عن الفاشل، وراقب المورد الذي يحد الأداء فعليًا.

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

صمم التصرف المطلوب

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

اختر العتبات وفق احتياج الخدمة وقياس سلوكها. النافذة القصيرة قد تلتقط تغيرًا عابرًا، والطويلة قد تؤخر اكتشاف عطل مستمر. راجع عدد العمليات أيضًا؛ نسبة خطأ مبنية على طلبين تختلف عن النسبة نفسها في آلاف الطلبات، وقد تختفي معاملة حرجة قليلة التكرار داخل المتوسط العام.

مثال افتراضي واختبار عملي

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

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

قلل الضوضاء مع الحفاظ على الرؤية

  • اجمع التنبيهات المرتبطة بحادث واحد بدل إشعار مستقل لكل جهاز.
  • اجعل كتم الصيانة محدد النطاق والمسؤول ووقت الانتهاء.
  • وجه توقعات السعة والعمل الروتيني إلى قائمة متابعة عند عدم الحاجة لتدخل فوري.
  • راجع التنبيهات التي تنتهي دائمًا دون إجراء.

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

احسب تكلفة الرؤية وتشغيلها

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

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

المراجع والسياق

Google SRE Book, Chapter 6: Monitoring Distributed Systems

Prometheus documentation: Alerting best practices

مراجع أساسية وتوسع في القراءة

الخطوة التالية

اربط الفكرة باحتياج شركتك.

وضح أهدافك والأنظمة الحالية والقيود المهمة قبل اختيار الحل.

خدمات تقنية المعلومات
واصل الاستكشاف

السحابة أم البنية المحلية؟ ابدأ باحتياجات النظام