من رسالة الخطأ إلى الإصلاح: كيف يقرأ الذكاء الاصطناعي سجلات الخادم؟

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

لماذا لا تكفي رسالة الخطأ التي يراها الزائر؟

لأن الصفحة التي يراها الزائر نتيجة، لا سبب. عبارة «502 Bad Gateway» تقول إن خادم الويب لم يحصل على رد صالح من الخدمة التي خلفه، لكنها لا تقول لماذا. وعبارة WordPress «حدث خطأ فادح في هذا الموقع» قد تعني نفاد الذاكرة، أو إضافة معطوبة، أو ملفًا لا يمكن قراءته.

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

أين تجد السجلات التي تحتاجها؟

المسارات تختلف بين التوزيعات وإعدادات اللوحة، لكن الأنواع ثابتة:

ماذا تعني أخطاء 500 و502 و503 و504؟

رمز الحالة يضيّق البحث قبل أن تفتح أي سجل:

الفرق بين 502 و504 مهم: الأول غالبًا يعني أن PHP-FPM غير متاح أصلًا أو توقف أثناء الطلب، والثاني يعني أنه متاح لكنه بطيء جدًا.

كيف يقرأ الذكاء الاصطناعي أخطاء PHP Fatal؟

نفاد الذاكرة المسموحة

[25-Oct-2026 10:14:52 UTC] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /home/shop/public_html/wp-content/plugins/report-export/export.php on line 212

الشرح الذي يقدمه المساعد: الحد المسموح لكل طلب PHP هو 256 MB (الرقم في السطر بالبايت)، وهذا الطلب تجاوزه داخل إضافة تصدير التقارير في السطر 212. الكمية التي حاول حجزها صغيرة، فالمشكلة ليست في هذا الحجز نفسه، بل في ما تراكم قبله.

ثم يفرّق بين احتمالين: هل يظهر الخطأ في طلب واحد بعينه (تصدير تقرير كبير مثلًا)، أم في كل الصفحات؟ إن كان في طلب واحد، فرفع memory_limit لهذا الموقع قد يكون حلًا مؤقتًا معقولًا، والحل الدائم تصدير البيانات على دفعات. وإن كان في كل الصفحات، فرفع الحد يخفي المشكلة؛ الأرجح إضافة تحمّل بيانات كثيرة في كل طلب. تفاصيل الإعداد في توثيق memory_limit على php.net.

تجاوز وقت التنفيذ

[25-Oct-2026 10:31:07 UTC] PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /home/shop/public_html/wp-includes/class-wp-http-requests-response.php on line 61

الملف هنا من النواة، لكن هذا لا يعني أن WordPress هو السبب. هذا الملف يتعامل مع طلبات HTTP الخارجية، فالأرجح أن إضافة تتصل بخدمة خارجية بطيئة أو متوقفة، والطلب انتظرها حتى انتهت المهلة. يطلب المساعد من الأدوات قائمة الطلبات البطيئة في الفترة نفسها، ويبحث عن الإضافة التي أطلقت الاتصال، بدل أن يقترح رفع max_execution_time مباشرة.

ماذا يعني «Permission denied»؟

2026/10/25 11:02:19 [crit] 2213#2213: *8812 open() "/home/shop/public_html/index.php" failed (13: Permission denied), client: 198.51.100.24, server: example.com, request: "GET / HTTP/1.1"

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

namei -l /home/shop/public_html/index.php
stat -c '%U:%G %a %n' /home/shop/public_html/index.php

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

كيف تُفهم أخطاء upstream في Nginx؟

كلمة upstream في سجل Nginx تعني الخدمة التي يمرر إليها الطلب، وهي PHP-FPM في أغلب مواقع PHP. ثلاث رسائل تتكرر كثيرًا:

connect() to unix:/run/php/php8.3-fpm-shop.sock failed (2: No such file or directory) while connecting to upstream
connect() to unix:/run/php/php8.3-fpm-shop.sock failed (11: Resource temporarily unavailable) while connecting to upstream
upstream timed out (110: Connection timed out) while reading response header from upstream

• No such file or directory: ملف الاتصال (socket) غير موجود. الـ pool متوقف، أو إعداد Nginx يشير إلى إصدار PHP آخر بعد تغيير الإصدار.
• Resource temporarily unavailable: الـ pool يعمل لكن طابوره ممتلئ. ابحث في سجل PHP-FPM عن server reached pm.max_children.
• upstream timed out: PHP-FPM استلم الطلب ولم يرد خلال المهلة. هذا يعطي 504، والسبب غالبًا استعلام بطيء أو طلب خارجي معلّق.

معنى كل مهلة موضح في توثيق وحدة fastcgi في Nginx. ورفع المهلة نادرًا ما يكون الحل، فهو يجعل الزائر ينتظر أكثر فقط. للجانب المتعلق بالأداء راجع دليل تسريع WordPress.

ماذا تفعل مع «Too many connections» في MariaDB؟

يرى الزائر في WordPress عبارة «Error establishing a database connection»، وفي سجل PHP يظهر:

PHP Warning:  mysqli_real_connect(): (HY000/1040): Too many connections in /home/shop/public_html/wp-includes/class-wpdb.php on line 1982

الخادم وصل إلى الحد الأقصى للاتصالات المتزامنة. يقرأ المساعد الأرقام قبل أن يقترح شيئًا:

mariadb -e "SHOW VARIABLES LIKE 'max_connections';
            SHOW GLOBAL STATUS LIKE 'Max_used_connections';
            SHOW FULL PROCESSLIST;"

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

كيف يربط الذكاء الاصطناعي السجلات بالوقت والتغييرات الأخيرة؟

السطر الواحد يقول ماذا حدث. الترتيب الزمني يقول لماذا. لنفترض أن متجرًا على example.sa بدأ يعرض أخطاء 502 صباحًا. يجمع المساعد الأحداث من عدة مصادر في جدول واحد:

09:58:40  audit     plugin updated: product-filters 3.1.0 -> 3.2.0 (account: shop)
10:01:12  access    first 502 on /shop/?filter=color
10:01:13  php-fpm   [pool shop] child 4123 exited on signal 11 (SIGSEGV)
10:01:13  nginx     recv() failed (104: Connection reset by peer) while reading response header from upstream
10:01:40  access    502 rate rises, only on URLs with ?filter=
10:05:00  metrics   CPU and memory normal

ما يستنتجه ويكتبه بوضوح:

1. ما رآه في البيانات: الأخطاء بدأت بعد تحديث إضافة التصفية بنحو دقيقتين، وتظهر فقط على الروابط التي تستخدمها، وعمليات PHP تتوقف أثناء هذه الطلبات.
2. ما يستنتجه: الإصدار الجديد من الإضافة يسبب توقف عملية PHP في هذا المسار.
3. ما استبعده: نقص الموارد، لأن المقاييس طبيعية.
4. الاقتراح: إرجاع الإضافة إلى الإصدار السابق، أو تعطيلها مؤقتًا، مع خطوة التراجع.

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

كيف تسأل الذكاء الاصطناعي سؤالًا جيدًا؟

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

ثلاث نصائح عملية:

• اذكر الوقت ومنطقته. «منذ ساعة» أقل فائدة من «من 10:00 بتوقيت الرياض».
• اذكر ما تغيّر، حتى لو بدا لك غير مهم: تحديث، أو نقل، أو تغيير في DNS.
• اطلب الدليل. إذا قدّم المساعد سببًا دون أسطر تثبته، اسأله: «أين رأيت هذا في السجلات؟».

وقبل لصق أي سجل في أداة خارجية، احذف منه كلمات المرور ومفاتيح API ورموز الجلسات.

كيف يساعدك bPanel؟

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

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

الخلاصة

• رمز الحالة يضيّق البحث: 500 في التطبيق، و502 و504 بين خادم الويب وPHP-FPM، و503 خدمة غير متاحة مؤقتًا.
• السطر الواحد يقول ماذا حدث، والترتيب الزمني مع التغييرات الأخيرة يقول لماذا.
• رفع الحدود والمهل يخفي المشكلة غالبًا، والإصلاح الصحيح يبدأ من السبب.
• اسأل بوقت محدد وموقع محدد، واطلب الدليل مع كل استنتاج.