سجلات وصول الخادم — قصة كل طلب استلمه تطبيقك

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

إليك سطرًا واحدًا من خادم يعمل بتنسيق السجل المدمج:

203.0.113.42 - jsmith [09/May/2026:14:32:11 +0000] "GET /api/users/profile HTTP/1.1" 200 1843 "https://example.com/dashboard" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"

ثمانية حقول. كل حقل يمثل دليلًا على ما حدث. دعونا نبدأ من اليسار إلى اليمين.

الحقول، واحدة تلو الأخرى

1. عنوان IP للعميل — 203.0.113.42

عنوان IP الذي فتح الاتصال عبر بروتوكول TCP مع خادمك. هذا هو لا بالضرورة عنوان IP المستخدم. إذا كنت وراء مُوزع عبء أو مُوزع محتوى (مثل Nginx أمام تطبيق Node)، فسيكون هذا عنوان IP للمُوزع. وعنوان IP الحقيقي للعميل موجود في X-Forwarded-For أو X-Real-IP الرؤوس — وعليك تكوين تنسيق السجل بشكل صريح لاستلامه.

في Nginx، يتطلب ذلك إضافة $http_x_forwarded_for إلى log_format التعليمات. %{X-Forwarded-For}iفي Apache، استخدم

2. الهوية — -

إلى الأبد سلطة تُستخدم. كان هذا الحقل مخصصًا لنتائج استعلام identd — بروتوكول قديم (RFC 1413) يسمح للخوادم بالسؤال عن نظام التشغيل الخاص بالعميل من حيث مالك العملية التي تُنشأ الاتصال. لا يُستخدم أي بروتوكول identd الآن. يُحتفظ بهذا الحقل لأن تنسيق السجل الشائع تم توحيدُه عندما كان identd يُستخدم. اتجه إلى تجاهل هذا الحقل.

3. اسم المستخدم المُصادق عليه — jsmith

الاسم المُعبّر عنه عند استخدام مصادقة HTTP الأساسية أو مصادقة Digest. بالنسبة لمعظم التطبيقات الحديثة — مثل مصادقة الرمز أو ملفات الجلسة أو JWTs — سيكون هذا سلطة. إذا حمايت مساحة إدارية باستخدام htpasswd، فإن محاولات الدخول الفاشلة تظهر كـ - إلى حالة 401؛ والنجاحات تظهر باسم المستخدم.

4. وقت الطلب — [09/May/2026:14:32:11 +0000]

الوقت الذي أكمل فيه الخادم معالجة الطلب (وليس وقت البدء). الشكل هو . يهم التوقيت المُضاف أكثر مما يعتقد الناس — إذا كان خادم تطبيقك يعمل في توقيت UTC ولكن أداة مراقبة الأداء أو أداة الإشعارات تعمل في توقيت محلي، فإن التوقيت المُضاف يُستخدم في كل مرة لربط ارتفاع في السجلات مع حدث محدد. اجعل كل شيء يعمل في UTC. day/Mon/year:HH:MM:SS timezone5. سطر الطلب —

الحقل الأكثر كثافة معلوماتيًا. يتكون من ثلاث أجزاء: طريقة HTTP، المسار مع سلسلة الاستعلام، ونوع البروتوكول. "GET /api/users/profile HTTP/1.1"

— GET، POST، PUT، DELETE، PATCH، HEAD، OPTIONS. الطرق غير المتوقعة على نقطة نهاية تستحق الانتباه.

• طريقة المسار + سلسلة الاستعلام
• — يخبرك بالضبط ما طُلب. يمكن أن تحتوي سلسلة الاستعلام على كلمات بحث، أرقام معرف، وفي بعض الأنظمة المُصممة بشكل سيئ، أذونات التحقق من الهوية. احتفظ بالسجلات بشكل مناسب. — في عام 2026، أي طلبات HTTP/1.0 في سجلاتك هي إما تكاملات قديمة أو شيء يُحاكي كمُستخدم قديم. إذا دعم خادمك HTTP/2 أو HTTP/3، فإنها تُسجل كنوعها.
• البروتوكول 6. رمز الحالة —

الحالة HTTP التي أرسلها الخادم. هذا هو الحقل المُقرّر. 200

— النجاح. تم معالجة الطلب.

• 2xx — إعادة التوجيه. يحتاج العميل إلى الانتقال إلى مكان آخر.
• 3xx — خطأ من جانب العميل. طلب غير صحيح، غياب التحقق من الهوية، غير موجود. يمكن أن يكون استخدامًا قانونيًا أو استكشافًا.
• 4xx — خطأ من جانب الخادم. توقفت تطبيقك، أو تجاوزت المدة، أو أرسلت محتوى غير صالح. يجب التحقق من هذه الحالات دائمًا.
• 5xx عند تقييم حدث، ابدأ بتصفية

أولًا. ثم ابحث عن وقت البداية للـ 500 — هذا هو الوقت الذي بدأ فيه الفشل. كل شيء قبل ذلك هو التمهيد؛ وكل شيء بعد ذلك هو نطاق التأثير. 5xx 7. حجم البيانات المرسلة —

حجم جسم الاستجابة بالبايتات، دون تضمين الرؤوس. سلطة تعني صفر بايتس (مثلاً في 1843

الاستجابات — حيث يمتلك العميل المحتوى بالفعل). القيم الكبيرة غير المتوقعة على نقاط نهاية تُفترض أن تُرجع بسياق بسيط من 200 بايت هي علامة خطر. إذا كان مستخدم مُصادق يُطلب من خلال نقطة "الحصول على ملف الملف الشخصي" ويحصل على 40 ميغا بايت، فهذا إما خطأ في البرنامج أو شخص يُستخدم تطبيق استخراج البيانات. 304 Not Modified 8. المُرجع —

من أين جاء العميل قبل تقديم هذا الطلب — الرابط في رأس "https://example.com/dashboard"

المتصفح. (أصبحت الأداة في معيار HTTP عام 1996 ونبقى معه). تأتي الاتصالات المباشرة، المراجعات، والطلبات من تطبيقات مُدمجة مع سلطة فارغة. هذا الحقل موجود فقط في تنسيق السجل المدمج؛ ينتهي السجل الشائع عند حجم البيانات المرسلة. Referer الإساءة في المُراجع — رؤوس مُراجع مزيفة في طلبات كثيرة تسعى إلى الظهور في تحليلاتك — كانت أكثر شيوعًا في الماضي ولكن أصبحت الآن مُتَحَدِّثة. لا يزال من المهم تصفية هذه القيم من بيانات التجميع.

9. مُعرف العميل —

مُعرف العميل الذي يُعرف به. يمكن تزوير مُعرف العميل بسهولة، لذا اعتبر هذا كدليل وليس كحقيقة. تُعرف المُراقبات المُوثوقة بشكل صريح: "Mozilla/5.0 (Windows NT 10.0; Win64; x64)…"

. تُرسل المُراقبات المُحاكاة بروتوكول المتصفح الكامل Mozilla/5.0 Chrome. يرسل Curl Googlebot/2.1 (+http://www.google.com/bot.html), Bingbot/2.0إلا إذا تم تغييره بـ curl/8.x الأنماط التي يجب مراقبتها: سلطة متماثلة تصل إلى نفس النقطة بسرعة آليّة، أو مُعرف عميل يدّعي أنّه Safari على iOS ولكن يُظهر طلبات لا يمكن أن تُنتجها متصفح بشري (لا صور، لا أسلوب، تصفح مُتسلسل للصفحات). -A.

الأنماط التي تظهر في كل سجل

المسح الأمني

مُستخدم واحد أو مجموعة صغيرة من المُستخدمين يُسجّل على مسارات متعددة بسرعة:

. كلها تُرجع 404. هذا هو مُسح مُتسلسل يُجري قائمة، وليس هجومًا موجهًا. يُسجّل على كل عنوان IP علني بشكل مستمر. /.env, /wp-login.php, /phpmyadmin, /admin/config.yml, /.git/configالسؤال الصحيح ليس "لماذا يسجّلون فيي" — بل "هل كانت أي من هذه المسارات تُرجع 200". إذا

تُرجع 200 على خادمك، فإن ذلك هو المشكلة الحقيقية. /.env المحاولة المُكررة لاستخراج البيانات

# Check if any sensitive paths actually returned 200
grep -E '"(GET|POST) /(wp-login\.php|\.env|\.git/config|phpmyadmin|admin)' access.log | awk '$9 == 200'

طلبات POST كثيرة إلى نقطة الدخول الخاصة بك، تُرجع تقريبًا 401، من مجموعة من المُستخدمين الموزعين. الإشارة هي النمط: نفس النقطة، حجم الاستجابة المتسق (صفحة الخطأ)، مجموعات مختلفة من مصادر IP تُشارك في شبكة مُحددة. تكون أوقات الاستجابة متسقة أيضًا — لأن المحاولات التلقائية تُجرى بسرعة لتجنب التقييد.

الارتفاع المفاجئ لـ 404 بعد التحديث

# Count POST /login attempts with 401 status by source IP
awk '$6 == "\"POST" && $7 == "/api/login" && $9 == "401" {print $1}' access.log \
  | sort | uniq -c | sort -rn | head -20

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

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

(ميكروثانية) إلى

; في Nginx، أضف %D مُتسلسل. بمجرد إضافته: LogFormatإذا تجمع الطلبات البطيئة حول فترة زمنية محددة، فإن ذلك يشير إلى تعارض — مثل مهمة تُجرى في وقت محدد، أو عملية مجمعة، أو نسخة احتياطية تضغط على قاعدة البيانات. إذا كانت مسار معين بطيئة بشكل دائم بغض النظر عن الوقت، فإن ذلك هو استجابة بطيئة أو مكالمة تُؤثر على الأداء التي تحتاج إلى تحليل. $request_time إلى log_format الاستجابة من خلال السجلات

# Nginx: show requests slower than 3 seconds (request_time in last field)
awk '{if ($NF+0 > 3) print $0}' /var/log/nginx/access.log | head -20

السجلات هي سلسلة زمنية. عندما يُبلغ المستخدم "أصبح شيء مُعطلًا حوالي الساعة 3 مساء"، فإنك:

تصفية إلى الفترة من 14:50 إلى 15:10

ابحث عن أول 5xx — هذا هو الوقت الذي بدأ فيه الفشل

• تحقق مما تغير في الأسابيع السابقة: هل كان هناك تطوير؟ تغيير في التكوين؟ تجديد للشهادة؟
• تحقق من المسارات التي تُظهر 5xx — هل هي كل شيء أم نقطة واحدة فقط؟
• تحقق من حجم البيانات المرسلة في الاستجابات الناجحة قبل وبعد — هل بدأ شيء يُرجع استجابات مُقطعة؟
• أمثلة على علامات الفشل التي يجب معرفتها:
• ارتفاع مفاجئ في 502

— توقف المُصدر (انهيار خادم التطبيق، استهلاك مجموعات الاتصال، انخفاض قاعدة البيانات). يبدأ الـ 502 في وقت دقيق.

• الحلقة المُعادية — 301/302 من نفس عنوان IP إلى نفس المسار بشكل متكرر. عادةً ما يكون ذلك خطأ في تكوين التوجيه عبر HTTPS أو إعداد SSL في Cloudflare يُعارض منطق التوجيه الخاص بتطبيقك.
• 200 مع صفر بايتس — حالة 200 ولكن حجم البيانات المرسلة هو 0 أو
• . قبّل التطبيق الطلب، وانهار استثناء، وعاد بجسم فارغ. حالة خطأ غير مُعالج. ارتفاع مفاجئ في 413 -— يرسل العملاء جسم طلب يتجاوز الحد المحدد. إما أن الحد منخفض جدًا بالنسبة للحالة أو أن شخصًا ما يُستكشف لوجود ثغرات في التحميل.
• إذا كنت تتعامل مع سجلات في تنسيقات متعددة — مثل تنسيق Apache Common، تنسيق Apache Combined، تنسيق Nginx الافتراضي، أو تنسيقات مخصصة — مُعالج السجلات المُدخلة

يمكنه تحليل الحقول وتوثيقها بحيث لا تُفكر في تعيين مواقع الحقول كل مرة تنتقل بين الخوادم. إدارة السجلات التي سترجعها على عدم تثبيتها تُدار تلقائيًا لتُعاد تدويرها يوميًا، وتُضغط، وتُحتفظ لمدة 14 إلى 30 يومًا. بدون ذلك،

تُزداد حتى يُملأ القرص. يحدث هذا في البيئة الإنتاجية.

• التسجيل المركزي — logrotate — بمجرد أن تمتلك أكثر من خادم، لا يمكن تصفح ملفات السجلات الفردية. ارسلها إلى Loki + Grafana، أو Elasticsearch، أو خدمة مُدارة. تنسيق السجلات المُهيكلة (JSON) يجعل الاستعلام أسهل من تحليل CLF باستخدام awk. access.log التحكم في الوصول إلى السجلات الخام
• — يمكن أن تحتوي ملفات السجلات على معلمات استعلام تحتوي على أذونات، بيانات مُخصصة للعميل، ومسارات داخلية. لا تجعلها قابلة للقراءة من قبل الجميع. اجعل مدة الاحتفاظ بالسجلات مُدروسة إذا كنت تحت قوانين مثل GDPR. لا تُسجل معلمات مُحسّسة
• — إذا كان تطبيقك يقبل أذونات أو كلمات مرور كمعلمات في عنوان URL (لا ينبغي أن يكون، لكن بعض الأنظمة القديمة تفعل ذلك)، فقم بتصفية هذه المعلمات على مستوى السجل قبل أن تصل إلى القرص. سجلات وصول الخادم — قصة كل طلب تلقّاه تطبيقك 2
• سجلات وصول الخادم — قصة كل طلب تلقّاه تطبيقك 1 كل طلب HTTP يتعامل معه خادمك يترك سطرًا في سجل الوصول. إليك كيفية قراءته — حقلًا حقلًا — وما هي الأنماط التي يجب مراقبتها.

قد يعجبك أيضاً