إدارة أنظمة لينكس

مراقبة موارد النظام

18 دقيقة الدرس 4 من 28

مراقبة موارد النظام

على نطاق الشركات الكبرى، الخادم الذي يصمت هو خادم يتعطل. يقضي مهندسو الإنتاج جزءًا كبيرًا من يومهم في قراءة مقاييس الموارد — استخدام المعالج، وضغط الذاكرة، ومعدل نقل إدخال/إخراج القرص وزمن الاستجابة — وربط هذه الأرقام بالإشارات الأربع الجوهرية: الاستخدام والتشبع والأخطاء والطلبات (منهجية USE التي صاغها Brendan Gregg). إتقان سلسلة أدوات المراقبة القياسية في Linux هو الشرط الأساسي لكل شيء آخر في هذه الوحدة التعليمية: لا يمكنك تأمين أو ضبط أو أتمتة نظام لا ترى ما يجري فيه.

منهجية USE

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

  • الاستخدام (Utilisation) — ما النسبة المئوية من طاقة المورد التي يُستخدم؟ (مثل: المعالج عند 80%)
  • التشبع (Saturation) — هل تتراكم المهام في قائمة الانتظار لأن المورد ممتلئ؟ (مثل: طول قائمة التشغيل أكبر من صفر، أو استخدام مساحة التبديل)
  • الأخطاء (Errors) — هل تفشل الطلبات الموجهة إلى المورد؟ (مثل: أخطاء I/O على القرص، أو إسقاط حزم على واجهة الشبكة)

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

المعالج: top و htop

top متوفر على كل نظام Linux ويعرض جدولًا حيًا مرتبًا للعمليات. الصفوف العلوية هي الأهم:

# شغّل top ثم اضغط المفاتيح: # P — فرز حسب CPU% M — فرز حسب MEM% 1 — تبديل عرض كل معالج منطقي # k — إنهاء عملية r — تغيير أولوية q — خروج top # لقطة واحدة غير تفاعلية (دفعي، تكرار 1): top -b -n 1 | head -30 # مثال على ترويسة الإخراج: # %Cpu(s): 3.2 us, 0.4 sy, 0.0 ni, 95.9 id, 0.3 wa, 0.0 hi, 0.2 si, 0.0 st # ^^^^ ^^^^ ^^^^ # فضاء المستخدم خامل انتظار قرص

الحقول التي يجب التركيز عليها: us (عمل فضاء المستخدم)، sy (عمل النواة)، wa (انتظار القرص — المعالج خامل ينتظر القرص)، si (المقاطعات البرمجية — شائع على المضيفين الشبكيين)، وst (الوقت المسروق من المشرف الافتراضي؛ قيمة غير صفرية على آلة افتراضية في بيئة مزدحمة).

htop يضيف الألوان ودعم الماوس والتمرير الأفقي وعرض شجرة العمليات (F5). ثبّته بـdnf install htop أو apt install htop. في الإنتاج، htop -d 5 (تحديث كل 0.5 ثانية) مفيد أثناء الحوادث؛ للفحوصات المبرمجة، استخدم top -b -n 1.

نصيحة إنتاجية: الـ%iowait المرتفع لا يعني بالضرورة أن القرص هو عنق الزجاجة — فهو يعني أن المعالجات خاملة بينما عملية واحدة على الأقل تنتظر I/O. تحقق بالتقاطع مع iostat لمعرفة ما إذا كان القرص مشبعًا فعلًا.

المعالج: vmstat — اللقطة التي تروي القصة كاملة

vmstat (إحصائيات الذاكرة الافتراضية) يُبلّغ عن المعالج والذاكرة والتبديل والإدخال/الإخراج والجدولة في سطر واحد مضغوط. شغّله بفاصل زمني لمتابعة الاتجاهات:

# vmstat <الفاصل> <العدد> # السطر الأول متوسطات منذ الإقلاع؛ الأسطر التالية فروق كل فترة vmstat 2 10 # مثال على الإخراج: # procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- # r b swpd free buff cache si so bi bo in cs us sy id wa st # 2 0 0 512000 128000 2048000 0 0 0 40 850 1200 5 2 91 2 0 # ^ ^ ^^ ^^ ^^ ^^ # | محجوبة دخول/خروج I/O الكتلي (كيلوبايت/ث) # قائمة التشغيل # المعيار: r (قائمة التشغيل) > عدد المعالجات × 2 يعني تشبع المعالج # b > 0 يعني عمليات محجوبة بنوم غير قابل للمقاطعة (قرص/شبكة) # si/so > 0 يعني تبديل نشط — إنذار خطر كبير

قائمة التشغيل (r) هي إشارة التشبع للمعالج. إذا تجاوزت باستمرار ضعف عدد المعالجات المنطقية، فأنت أمام تشبع في المعالج — العمليات تنتظر دورها.

الذاكرة: free

free -h يطبع استخدام الذاكرة ومساحة التبديل بصيغة مقروءة. نوى Linux الحديثة تستخدم الذاكرة الخاملة بقوة كذاكرة تخزين مؤقت للصفحات، لذا قد يبدو عمود "الاستخدام" مرتفعًا بشكل مقلق على خادم سليم:

free -h # total used free shared buff/cache available # Mem: 15Gi 3.2Gi 1.1Gi 512Mi 11Gi 11Gi # ^^^^^^^^ ^^^^^^^^^ # (ذاكرة تخزين صفحات النواة) (متاحة فعلًا للتطبيقات) # العمود "available" هو ما يهم — وليس "free". # available = free + ذاكرة التخزين المؤقت القابلة للاسترداد # متابعة ضغط الذاكرة بمرور الوقت: vmstat -s | grep -E 'memory|swap|pages'
خطأ إنتاجي شائع: لا تنبّه على عمود free وحده. خادم Linux به 200 ميغابايت "free" و10 غيغابايت "available" في وضع صحي تمامًا — النواة تستخدم الذاكرة كذاكرة تخزين مؤقت للقرص، وستعيدها فورًا عند حاجة التطبيق. انبّه فقط عندما ينخفض available دون عتبة آمنة (عادةً 10-15% من إجمالي الذاكرة) أو عند استخدام مساحة التبديل.

إدخال/إخراج القرص: iostat

iostat (جزء من حزمة sysstat) هو الأداة الرئيسية لتحليل الأجهزة الكتلية. يتوافق مباشرة مع USE: الاستخدام (%util)، التشبع (aqu-sz، متوسط عمق قائمة الانتظار)، والأخطاء (من dmesg أو smartctl):

# تثبيت sysstat إذا لزم: dnf install sysstat # RHEL/CentOS/Rocky apt install sysstat # Debian/Ubuntu # iostat مع إحصائيات موسعة، مقروءة، فاصل 2 ثانية، 5 تكرارات: iostat -xh 2 5 # الأعمدة الرئيسية (الموسعة -x): # r/s w/s — عمليات قراءة وكتابة في الثانية (IOPS) # rkB/s wkB/s — معدل نقل القراءة/الكتابة بكيلوبايت/ثانية # await — متوسط زمن استجابة I/O (مللي ثانية) شاملًا وقت قائمة الانتظار # r_await w_await — زمن استجابة القراءة والكتابة منفصلًا # aqu-sz — متوسط حجم قائمة الطلبات (إشارة التشبع) # %util — نسبة الوقت الذي كان الجهاز مشغولًا (الاستخدام) # مثال: SSD سليم مقابل قرص دوّار مشبع # Device r/s w/s rkB/s wkB/s await aqu-sz %util # nvme0n1 120.0 80.0 2048.0 1024.0 0.8 0.1 12.0 <-- SSD سليم # sda 5.0 40.0 64.0 512.0 80.0 15.0 98.0 <-- قرص دوّار مشبع!

قيمة %util قرب 100% على قرص دوّار تعني أن القرص يمثل عنق زجاجة. على أقراص NVMe الحديثة، قد يرتفع التشبع دون أن يبلغ %util 100% بسبب التوازي الداخلي — اعتمد على aqu-sz وawait بدلًا من ذلك. أي زمن استجابة يتجاوز 20 مللي ثانية للقرص الدوّار أو 1 مللي ثانية لـ NVMe تحت الحمل الطبيعي يستحق التحقيق.

الجمع بين الأدوات: نمط التحقيق في الحوادث

USE Method triage flow: from symptom to root resource USE Method Triage Flow Symptom / Alert high latency / OOM / timeout 1. Check CPU top / vmstat r column 2. Check Memory free -h → available; vmstat si/so 3. Check Disk I/O iostat -xh → await, %util, aqu-sz Identify saturated resource → act U: %us+%sy > 80%? S: run-queue r > 2×cores? U: used / total RAM? S: swap si/so > 0? U: %util near 100%? S: aqu-sz > 1? await > 20ms?
تدفق فرز منهجية USE: التحقق من المعالج ثم الذاكرة ثم قرص الإدخال/الإخراج بالتسلسل باستخدام الأداة المناسبة لكل طبقة.

قائمة التحقق السريعة للأوامر أثناء المناوبة

يُنفَّذ التسلسل التالي في أقل من 60 ثانية ويغطي كل مورد رئيسي. احفظه كمقتطف في كتيب التشغيل:

# 1. المعالج — الاستخدام وقائمة التشغيل vmstat 1 5 # 2. المعالج — أعلى العمليات استهلاكًا (دفعي، غير تفاعلي) top -b -n 1 -o %CPU | head -20 # 3. الذاكرة — الذاكرة المتاحة وضغط التبديل free -h vmstat -s | grep -i swap # 4. I/O القرص — إحصائيات موسعة لكل جهاز iostat -xh 2 3 # 5. أي العمليات تسبب I/O القرص؟ iotop -bo -n 3 # يتطلب: dnf install iotop # 6. ضغط مقابض الملفات والمقابس على مستوى النظام cat /proc/sys/fs/file-nr # المستخدم / الحر / الحد الأقصى ss -s # ملخص المقابس
رؤية أساسية: الهدف من جميع هذه الأدوات واحد — الإجابة على أسئلة USE لكل مورد. بمجرد تحديد المورد المشبع (قائمة التشغيل للمعالج، أو انخفاض "available" مع نشاط التبديل للذاكرة، أو await/aqu-sz للقرص)، ستعرف أين تحفر أعمق. الأدوات أعلاه هي الطبقة الأولى؛ أدوات أعمق مثل perf وbpftrace وsar تأتي بعد تحديد عنق الزجاجة.

الاحتفاظ بالمقاييس التاريخية مع sar

sar (مُبلِّغ نشاط النظام، من حزمة sysstat) هو iostat وvmstat مدمجَين مع التسجيل التاريخي. على معظم التوزيعات، يُفعّل sysstat تلقائيًا كتابة عيّنة كل 10 دقائق إلى /var/log/sa/. هذا لا يقدّر بثمن للتحليل بعد الحوادث ("ما كان معدل I/O في 03:47 الخميس الماضي؟"):

# تفعيل جمع sysstat (يُشغّل sadc كل 10 دقائق): systemctl enable --now sysstat # عرض تاريخ المعالج لليوم: sar -u # عرض تاريخ الذاكرة: sar -r # عرض تاريخ I/O القرص لجهاز محدد: sar -d -p # -p يستخدم أسماء الأجهزة المقروءة # عرض بيانات تاريخية من ملف محفوظ: sar -u -f /var/log/sa/sa10 # اليوم العاشر من الشهر

في الشركات التي تُشغّل آلاف الخوادم، يُجمع بيانات sar في مخازن سلاسل زمنية مركزية (Prometheus + node_exporter، أو Datadog، أو CloudWatch) وتحل لوحات القيادة محل العمل اليدوي بسطر الأوامر خلال العمليات العادية. لكن أدوات CLI تبقى ضرورية أثناء الحوادث التي تعتمد SSH فقط، وعند تهيئة مضيفين جدد، وتشخيص المشكلات التي تسبق منظومة المراقبة.