خوادم الويب والوكلاء العكسيون

الضبط والاستكشاف وإصلاح الأعطال

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

الضبط والاستكشاف وإصلاح الأعطال

يقدّم Nginx المُثبَّت بصورة صحيحة الطلبات. أما Nginx المُضبَّط بصورة صحيحة فيقدّم عشرة أضعاف ذلك دون عناء — وحين يحدث خطأ، تخبرك سجلاته بالسبب الحرفي في ثوانٍ. يتناول هذا الدرس ثلاثة موضوعات مترابطة يجب أن يتقنها كل مهندس إنتاج: حدود العمليات والاتصالات، ومساحة واصفات الملفات، والتحليل المنهجي للسجلات.

عمليات العمال واتصالاتهم

يعتمد Nginx بنية رئيسي + عمال. تمتلك العملية الرئيسية مقابس الاستماع وتُعيد تحميل الإعدادات؛ أما عمليات العمال فتتولى عمليات الإدخال/الإخراج الفعلية — قراءة الطلبات، واستدعاء الخوادم الأمامية، وإرسال الاستجابات. العمال أحادية الخيوط وقائمة على الأحداث، وبذلك يمكنها التعامل مع آلاف الاتصالات المتزامنة دون خيوط أو أقفال.

التوجيهان اللذان يحددان الطاقة القصوى لخادمك يقعان في nginx.conf على المستوى الأعلى وفي كتلة events:

# /etc/nginx/nginx.conf

# عامل واحد لكل نواة معالج منطقية — هذا هو الأساس المعتمد.
# تكتشف 'auto' عدد النوى تلقائيًا عند بدء التشغيل.
worker_processes auto;

events {
    # الحد الأقصى للاتصالات المتزامنة لكل عامل.
    # الطاقة النظرية الإجمالية = worker_processes * worker_connections.
    # على جهاز رباعي النوى مع worker_connections 1024: حتى 4,096 اتصالاً.
    worker_connections 1024;

    # استخدام epoll على Linux (واجهة أحداث الإدخال/الإخراج القابلة للتوسع).
    # يختارها Nginx تلقائيًا، لكن التوضيح الصريح يوثّق النية.
    use epoll;

    # السماح لكل عامل بقبول جميع الاتصالات المعلقة في استدعاء نظام واحد.
    # يُقلل تبديل السياق في حركة المرور المتدفقة.
    multi_accept on;
}

ما الحجم الملائم لـ worker_connections؟ يستهلك كل اتصال مفتوح واصف ملف واحدًا تقريبًا وقدرًا صغيرًا من الذاكرة (8–16 كيلوبايت). الحد الآمن هو: worker_connections = (واصفات_الملفات_المتاحة / worker_processes) * 0.9. على خادم بـ 65 535 واصفًا و4 عمال يعطيك ذلك نحو 14 700 لكل عامل — أعلى بكثير من القيمة الافتراضية 1024. ارفعها إلى 4096 أو 8192 للواجهات الأمامية كثيفة الحركة.

واصفات الملفات: الاختناق الخفي

كل مقبس أو ملف أو أنبوب مفتوح يُحتسب ضمن حد واصفات الملفات (FD) لنظام التشغيل. تحت الحمل الثقيل، يُسجّل الخادم غير المُهيَّأ الخطأ too many open files ويبدأ في رفض الاتصالات — وهو فشل حاد يبدو للمستخدمين على هيئة مهل عشوائية.

ثمة حدّان يجب رفعهما معًا:

على مستوى نظام التشغيل (عموم النظام): /proc/sys/fs/file-max — السقف المطلق لجميع العمليات على الجهاز.
على مستوى العملية: ulimit -n لعملية عامل Nginx، يُتحكم فيه عبر worker_rlimit_nofile في nginx.conf.

# 1. رفع الحد على مستوى النظام بصفة دائمة في /etc/sysctl.conf
fs.file-max = 200000

# تطبيق فوري دون إعادة تشغيل
sysctl -p

# 2. رفع الحد على مستوى العملية داخل nginx.conf (السياق الرئيسي)
worker_rlimit_nofile 65535;

# بعد تغيير nginx.conf، أعد التحميل دون توقف:
nginx -t && systemctl reload nginx

# 3. التحقق مما تستخدمه عمال Nginx فعليًا
cat /proc/$(pgrep -f 'nginx: worker')/limits | grep 'open files'

قد يُلغي systemd إعداداتك بصمت. إذا كنت تدير Nginx عبر systemd (معيار على Ubuntu 20+ وCentOS 8+)، فهو يُطبّق LimitNOFILE الخاص به. تحقق بـ systemctl show nginx | grep LimitNOFILE. لرفعه، أنشئ ملف تعديل: systemctl edit nginx، أضف [Service] / LimitNOFILE=65535، ثم systemctl daemon-reload && systemctl reload nginx. يجب ضبط كل من حد systemd وworker_rlimit_nofile — فهما مفتاحان مستقلان.

قراءة سجلات الوصول في Nginx

سجل الوصول هو نافذتك الفورية على حركة الإنتاج. يظهر هنا كل طلب عالجه Nginx. يلتقط تنسيق combined الافتراضي عنوان IP والطابع الزمني وأسلوب HTTP وعنوان URI ورمز الحالة والبايتات المُرسلة والمرجع ووكيل المستخدم — وهو كافٍ لإعادة بناء ما حدث بالضبط.

# متابعة سجل الوصول مباشرةً — ضرورة أثناء الحوادث
tail -f /var/log/nginx/access.log

# عدّ أخطاء HTTP 5xx في الدقيقة الأخيرة
awk -v d="$(date +'%d/%b/%Y:%H:%M')" '$4 ~ d && $9 ~ /^5/' /var/log/nginx/access.log | wc -l

# أبطأ 10 مسارات URI (يتطلب $request_time في تنسيق السجل)
sort -t'"' -k6 -rn /var/log/nginx/access.log | head -10

# اكتشاف عنوان IP الذي يقصف الخادم الآن
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

أضف $request_time و$upstream_response_time إلى تنسيق سجلك. لا يتضمنهما التنسيق الافتراضي. بدونهما لا يمكنك التمييز بين "كان Nginx بطيئًا" (ارتفاع $request_time، انخفاض $upstream_response_time) و"كانت الخلفية بطيئة" (ارتفاع كليهما). أضف تنسيق سجل مخصصًا في nginx.conf واستخدمه في جميع كتل server للإنتاج:

log_format timed_combined '$remote_addr - $remote_user [$time_local] '
    '"$request" $status $body_bytes_sent '
    '"$http_referer" "$http_user_agent" '
    'rt=$request_time urt=$upstream_response_time';

قراءة سجلات الأخطاء في Nginx

تلتقط سجلات الأخطاء كل ما عجز Nginx عن التعامل معه بسلاسة: مهل الخادم الأمامي، وتعطل العمال، وأخطاء الصلاحيات، وأخطاء الإعدادات المكتشفة وقت التشغيل، واستنزاف الموارد. المستوى الافتراضي هو error؛ يمكنك خفضه مؤقتًا إلى warn أو info للتشخيص، لكن لا تُبقِ على debug في الإنتاج أبدًا — إذ يكتب سطرًا لكل بايت ويُشبع القرص.

# مراقبة الأخطاء في الوقت الفعلي
tail -f /var/log/nginx/error.log

# أنماط شائعة للبحث عنها أثناء الحادثة:
grep 'connect() failed'   /var/log/nginx/error.log   # الخادم الأمامي معطل
grep 'too many open files' /var/log/nginx/error.log  # تجاوز حد FD
grep 'worker_connections'  /var/log/nginx/error.log  # تجاوز حد الاتصالات
grep 'upstream timed out'  /var/log/nginx/error.log  # ارتفاع زمن الاستجابة في الخلفية
grep 'no live upstreams'   /var/log/nginx/error.log  # فشل جميع خوادم الخلفية

# رفع مستوى تفصيل السجل مؤقتًا لخادم افتراضي واحد:
# اضبط 'error_log /var/log/nginx/debug.log debug;' داخل كتلة server{}،
# ثم أعد التحميل. ارجع إلى الوضع الطبيعي فور الانتهاء من التتبع.

تجميع الصورة الكاملة: قائمة ضبط للإنتاج

عند تجهيز خادم للإنتاج أو تشخيص انتكاسة في الأداء، اتبع هذه الخطوات بالترتيب:

شغّل nproc وتأكد من ضبط worker_processes auto; — أو حدده صراحةً.
تحقق من worker_connections: لوكيل عكسي أمامي يخدم أكثر من 10 آلاف مستخدم متزامن، 4096–8192 نقطة انطلاق جيدة.
تأكد أن worker_rlimit_nofile يساوي أو يتجاوز worker_connections * 2 (اتصال للعميل + اتصال للخادم الأمامي).
تحقق من توافق LimitNOFILE في systemd.
أضف $request_time و$upstream_response_time إلى تنسيق السجل قبل الإطلاق — إضافتهما بعد وقوع الحادثة متأخر جدًا.
اضبط تدوير السجلات مع logrotate لمنع سجلات الوصول من استنزاف مساحة القرص على مدار أسابيع.

استخدم nginx -T (T كبيرة) لتفريغ الإعداد الكامل المُحلَّل. هذه هي الطريقة الأكثر فاعلية للتحقق من أن include أو كتلة server أو توجيهًا ما نشطٌ فعلًا. يُؤكد الناتج أيضًا آخر عملية فحص بناء جملة بـ nginx -t بعرض ما حمّله Nginx فعلًا في الذاكرة.