مؤشرات مراقبة السيرفر التي تهم فعلاً: العتبات ومتى تنبّه

المؤشرات التي تهم فعلاً وعتباتها في سطور

إذا أردت مراقبة سيرفرك بلا ضجيج، راقب خمسة مؤشرات فقط بعتبات رقمية واضحة: استهلاك المعالج CPU، الذاكرة RAM، أداء القرص I/O، زمن الاستجابة، ومعدل الأخطاء. القاعدة العملية: نبّه على متوسط المعالج فوق 85% لمدة تتجاوز خمس دقائق، وعلى الذاكرة المتاحة تحت 10% مع بدء استخدام swap، وعلى زمن انتظار القرص (await) فوق 20 مللي ثانية للأقراص SSD، وعلى زمن الاستجابة p95 فوق ضعف خط الأساس الطبيعي، وعلى معدل أخطاء 5xx فوق 1% من الطلبات. هذه العتبات ليست مقدسة، بل نقطة انطلاق تضبطها على سلوك حملك الحقيقي.

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

استهلاك المعالج CPU: اقرأ الطابور لا النسبة فقط

نسبة استخدام المعالج وحدها مضللة. سيرفر يعمل عند 95% معالج وينهي كل طلباته بسرعة أفضل من سيرفر عند 60% لكن طلباته تنتظر في الطابور. المؤشر الأهم بعد النسبة هو load average مقسوماً على عدد الأنوية. إذا كان لديك 4 vCPU وكان متوسط الحمل 4.0 فأنت عند السعة الكاملة تماماً، وإذا تجاوز 8.0 فالطلبات تنتظر ضعف طاقتها.

راقب أيضاً iowait، وهي نسبة الوقت الذي يقف فيه المعالج عاطلاً بانتظار القرص. ارتفاع iowait فوق 10% يعني أن مشكلتك ليست المعالج بل التخزين، فلا تكبّر السيرفر خطأً، وميّز بين وقت المستخدم user وووقت النظام system، فارتفاع system بشكل غير طبيعي يكشف عادة عن ضغط في الشبكة أو استدعاءات نظام مفرطة من تطبيق سيئ الكتابة.

عتبات المعالج العملية

• تحذير: متوسط المعالج فوق 85% لخمس دقائق متصلة، أو load average يتجاوز عدد الأنوية.
• حرج: متوسط المعالج فوق 95% لعشر دقائق، أو load average يتجاوز ضعف عدد الأنوية.
• تجاهل: قفزات لحظية تحت الدقيقة، فهي طبيعية أثناء بناء أو نسخ احتياطي.

الذاكرة RAM: المتاح لا المستخدَم

أكثر خطأ يرتكبه المبتدئ أنه يفزع حين يرى الذاكرة المستخدمة عند 90%. نظام لينكس يستغل الذاكرة الفارغة كذاكرة تخزين مؤقت للملفات cache، وهذا سلوك صحي يسرّع القراءة. المؤشر الصحيح هو available memory الذي يحسب الذاكرة القابلة للتحرير فوراً، وليس free memory. سيرفر بـ 8 GB قد يظهر 400 MB حرة فقط لكن 3 GB متاحة، وهذا وضع سليم تماماً.

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

عتبات الذاكرة العملية

• تحذير: الذاكرة المتاحة تحت 15% من الإجمالي، أو أي نشاط swap مستمر لأكثر من دقيقتين.
• حرج: الذاكرة المتاحة تحت 5%، أو معدل swap out يتجاوز 10 MB في الثانية.
• تحقيق فوري: ظهور رسائل OOM killer في سجلّ النظام، فهذا يعني أن النظام قتل عملية لتحرير الذاكرة.

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

أداء القرص I/O: الزمن أهم من المساحة

مراقبة المساحة الحرة ضرورية لكنها الأسهل، والامتلاء الكامل يوقف الخدمة فجأة. الأهم والأكثر خفاءً هو زمن انتظار القرص، أي كم تستغرق عملية القراءة أو الكتابة الواحدة. على قرص SSD صحي يجب أن يبقى await تحت 10 مللي ثانية، وارتفاعه فوق 20 مللي ثانية بشكل مستمر يعني أن القرص صار عنق الزجاجة. على القرص الصلب الدوّار HDD تكون الأرقام أعلى بطبيعتها، لكن سيرفرات كلاود تعمل على SSD بنظام RAID 10 فالتوقع منخفض.

راقب أيضاً IOPS، أي عدد عمليات الإدخال والإخراج في الثانية، وعمق الطابور queue depth. طابور يتجاوز الرقم 2 لكل قرص بشكل مستمر يعني تراكم طلبات لا يلحقها التخزين. قاعدة بيانات تحت ضغط قد تولّد آلاف عمليات القراءة العشوائية في الثانية، وهنا يظهر الفرق بين تخزين احترافي وتخزين رخيص.

عتبات القرص العملية

• تحذير: await فوق 20 مللي ثانية لخمس دقائق، أو المساحة الحرة تحت 20%.
• حرج: await فوق 50 مللي ثانية، أو المساحة الحرة تحت 10%، أو استهلاك inode فوق 90%.
• لا تنسَ: امتلاء الـ inode يوقف إنشاء الملفات حتى لو بقيت مساحة، وهو عطل يحيّر كثيرين.

زمن الاستجابة: راقب p95 وp99 لا المتوسط

المتوسط أسوأ مقياس لزمن الاستجابة لأنه يخفي المعاناة. لو كانت 95 طلباً تُخدَم في 50 مللي ثانية و5 طلبات في 5 ثوانٍ، يبقى المتوسط مقبولاً بينما خمسة بالمئة من عملائك يعانون. لهذا نستخدم النسب المئوية: p50 يمثّل التجربة الوسطى، وp95 يمثّل أسوأ تجربة يعيشها واحد من كل عشرين طلباً، وp99 يكشف الحالات الطرفية التي غالباً تسبق العطل الكامل.

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

معدل الأخطاء: النبض الحقيقي للخدمة

معدل الأخطاء هو المؤشر الأقرب لتجربة العميل الفعلية، لأنه يقيس الطلبات الفاشلة مباشرة. راقب نسبة استجابات 5xx إلى إجمالي الطلبات، وميّزها عن أخطاء 4xx التي تعني غالباً خطأ من طرف العميل لا عطلاً في سيرفرك. ارتفاع مفاجئ في نسبة 5xx فوق 1% من الطلبات إشارة إلى مشكلة تستحق التحقيق فوراً، وتجاوز 5% حالة طوارئ.

لا تكتفِ بالنسبة، بل راقب ميزانية الخطأ error budget المشتقة من هدف مستوى الخدمة. إذا كان هدفك توفراً بنسبة 99.9% شهرياً فميزانيتك للخطأ قرابة 43 دقيقة من الفشل في الشهر، فحين تستهلك نصفها في يوم واحد فأنت على مسار خطير. هذا المنطق يحوّل التنبيه من رقم لحظي إلى قرار مبني على اتجاه.

ما وراء 5xx

• معدل نجاح الاتصال بقاعدة البيانات: انخفاضه يسبق عادة موجة أخطاء 5xx بثوانٍ.
• أخطاء انتهاء المهلة timeout: تكشف بطئاً في خدمة خلفية قبل أن يتحول إلى فشل كامل.
• أخطاء شهادة SSL: راقب تاريخ انتهاء الشهادة، فانتهاؤها يوقف كل حركة HTTPS دفعة واحدة.

متى تنبّه فعلاً: قاعدة الأعراض

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

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

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