مانیتورینگ سرور وردپرس و WooCommerce؛ عیب‌یابی فروشگاه

صفحه اصلی فروشگاه وردپرسی سریع باز می‌شود، اما مشتری در مرحله پرداخت با خطای ۵۰۲ روبه‌رو می‌شود. در صفحه وضعیت هاست، CPU ظاهراً عادی است؛ بااین‌حال سفارش‌ها دیر ثبت می‌شوند و موجودی کالا گاهی با تأخیر به‌روزرسانی می‌شود. مانیتورینگ سرور وردپرس و WooCommerce باید چیزی بیشتر از آپتایم دامنه باشد: سلامت PHP-FPM، MySQL یا MariaDB، Redis، صف کارهای پس‌زمینه و مسیر حساس سفارش باید کنار هم بررسی شوند.

این راهنما برای مدیر فروشگاه WooCommerce، توسعه‌دهنده وردپرس و مسئول سرور تهیه شده است. مسیر عیب‌یابی را از نشانه کاربر شروع می‌کنیم، متریک‌های سرور را با اجزای وردپرس مرتبط می‌کنیم و در پایان یک چک‌لیست عملی پایش ارائه می‌دهیم. مقاله‌های قبلی مانند تشخیص گلوگاه دیتابیس و فرمان‌های پایش Ubuntu پایه هستند؛ این صفحه روی رفتار خاص فروشگاه وردپرسی تمرکز دارد.

چرا مانیتور HTTP 200 برای فروشگاه کافی نیست؟

صفحه اصلی فروشگاه معمولاً از Cache بیشتری بهره می‌برد، ولی سبد خرید، تسویه‌حساب و وضعیت سفارش داده پویا دارند. ممکن است صفحه محصول از CDN با HTTP 200 پاسخ دهد و هم‌زمان عملیات پرداخت روی Backend خطا بدهد. پس باید حداقل سه لایه را جدا بسنجید: دسترس‌پذیری عمومی، سلامت اجزای سرور و موفقیت مسیرهای تجاری.

کدام سنجه‌های تجربه کاربر مهم‌ترند؟

برای فروشگاه، زمان پاسخ درخواست Checkout، درصد خطاهای ۴xx/۵xx، نرخ خطای درخواست AJAX یا REST مورد استفاده قالب و وضعیت پردازش سفارش مهم‌اند. نرخ تکمیل خرید یک شاخص تجاری است و لزوماً از متریک‌های سیستم‌عامل استخراج نمی‌شود. اگر در مانیتورینگ مصنوعی سفارش آزمایشی ایجاد می‌کنید، باید درگاه پرداخت و داده تست مجاز داشته باشید؛ اجرای خرید واقعی و ایجاد سفارش ناخواسته روی Production روش مناسبی نیست.

نقشه اجزای WordPress و WooCommerce در یک سرور

لایه	نشانه رایج مشکل	آنچه باید پایش شود
وب‌سرور Nginx/Apache	502/503، اتصال کند	زمان پاسخ، نرخ خطا، وضعیت Upstream
PHP-FPM	کندی هم‌زمان درخواست‌های پویا	Worker فعال/آزاد، صف درخواست و Slow Log
MySQL/MariaDB	کندی صفحه سفارش و جست‌وجوی محصول	Query کند، اتصال، قفل و تأخیر ذخیره‌سازی
Redis Object Cache	افزایش بار دیتابیس پس از خطای Cache	اتصال، حافظه، Eviction و Hit/Miss
WP-Cron و Action Scheduler	ایمیل یا کار پس‌زمینه دیر اجرا می‌شود	تعداد کارهای Pending/Failed و سن قدیمی‌ترین Job
WooCommerce Checkout	سبد سالم ولی پرداخت ناموفق	خطای Endpoint، وضعیت سفارش و Callback درگاه

همه فروشگاه‌ها این اجزا را جداگانه ندارند. در هاست اشتراکی ممکن است به وضعیت PHP-FPM یا Redis دسترسی نداشته باشید؛ در آن صورت باید از داده ارائه‌دهنده هاست، Log برنامه و تست‌های بیرونی استفاده کنید.

گام اول: CPU، RAM و ظرفیت دیسک را روی هاست بررسی کنید

اگر دسترسی SSH مجاز دارید، وضعیت کلی را با فرمان‌های خواندنی ببینید. روی Linux، Load Average بالا لزوماً به معنی اشباع CPU نیست؛ ممکن است انتظار I/O یا قفل دیتابیس در افزایش آن نقش داشته باشد.

uptime
free -h
vmstat 1 5
df -hT
df -i
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -n 15

ستون available در خروجی free معمولاً از «used» برای تخمین حافظه در دسترس مفیدتر است. مقدار df -i نیز وضعیت inode را نشان می‌دهد: اگر میلیون‌ها فایل کش یا تصویر کوچک ایجاد شده باشد، ممکن است inode قبل از فضای ذخیره‌سازی تمام شود. تغییر یا حذف فایل در این مرحله ضروری نیست؛ ابتدا علت رشد را ثبت کنید.

چه زمانی CPU بالا واقعاً مشکل WooCommerce است؟

اگر افزایش CPU با درخواست‌های پویا، خطای Checkout و زمان پاسخ بالاتر هم‌زمان است، احتمال فشار روی PHP یا دیتابیس را بررسی کنید. اما یک جهش هنگام تولید تصویر، پردازش Batch یا بروزرسانی قالب لزوماً حادثه نیست. مقایسه زمانی با ترافیک، Cron و انتشار افزونه‌ها ضروری است.

گام دوم: PHP-FPM را از نظر ظرفیت Worker بررسی کنید

در وردپرس، اجرای PHP برای درخواست‌های پویا روی ظرفیت پاسخ‌گویی اثر مستقیم دارد. اگر همه Workerها مشغول شوند، درخواست‌های جدید ممکن است در صف منتظر بمانند و حتی با CPU متوسط، Checkout کند شود. ابزار پایش باید تعداد Workerهای فعال/آزاد، طول صف و تعداد رسیدن به حد Worker را در صورت فعال‌بودن گزارش PHP-FPM بررسی کند.

systemctl list-units --type=service --all 'php*-fpm.service'
ps -eo pid,comm,%cpu,%mem --sort=-%mem | head -n 20
journalctl --since '30 minutes ago' -p warning --no-pager -n 80

برای جزئیات Workerها می‌توان از Status Page خود PHP-FPM استفاده کرد، اما این Endpoint نباید به صورت عمومی و بدون کنترل دسترسی منتشر شود. نام سرویس بسته به نسخه PHP فرق دارد. افزایش بی‌محابای pm.max_children هم راهکار قطعی نیست؛ هر Worker حافظه مصرف می‌کند و اگر دیتابیس گلوگاه باشد، درخواست هم‌زمان بیشتر می‌تواند شرایط را بدتر کند.

Slow Log به چه دردی می‌خورد؟

در صورت پیکربندی مناسب، Slow Log می‌تواند نشان دهد اجرای PHP هنگام کندی در کدام مسیر بوده است. فعال‌سازی باید با محدودیت حجم و دسترسی امن انجام شود؛ Log ممکن است شامل مسیر، شناسه و جزئیات عملیاتی باشد. از آن برای پیدا کردن افزونه یا Hook کند استفاده کنید، نه برای انتشار عمومی داده.

گام سوم: MySQL و MariaDB را هنگام کندی سفارش‌ها ببینید

WooCommerce داده محصول، مشتری و سفارش را در پایگاه‌داده نگه می‌دارد. وضعیت اتصال‌ها، Queryهای کند، Lock Wait و تأخیر دیسک را با زمان کندی Checkout مقایسه کنید. ساختار ذخیره سفارش در WooCommerce ممکن است از High-Performance Order Storage (HPOS) استفاده کند؛ پس فرض نکنید همه سفارش‌ها در یک جدول کلاسیک وردپرس قرار دارند.

-- Run read-only statements with an authorized DB account.
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW VARIABLES LIKE 'slow_query_log';
SHOW FULL PROCESSLIST;

این فرمان‌ها برای مشاهده‌اند، اما SHOW FULL PROCESSLIST ممکن است Query حاوی داده حساس نشان دهد. برای عیب‌یابی Slow Query به ایندکس، قفل تراکنش و مدت انتظار نگاه کنید؛ از تغییر فوری Schema در Production بدون بکاپ و آزمون بپرهیزید. برای مفهوم HPOS از مستندات رسمی ذخیره‌سازی سفارش WooCommerce استفاده کنید.

گام چهارم: Redis Object Cache را با Full-Page Cache اشتباه نگیرید

Redis Object Cache نتایج برخی عملیات و اشیای برنامه را در حافظه نگه می‌دارد تا مراجعه مکرر به دیتابیس کمتر شود. اما Cache صفحه کامل که خروجی HTML را ذخیره می‌کند، رفتار دیگری دارد. برای WooCommerce، کش‌کردن بی‌ملاحظه سبد خرید، Checkout و صفحه حساب کاربر می‌تواند اطلاعات قدیمی یا حتی داده کاربر دیگر را نشان دهد؛ قوانین Cache باید با نسخه WooCommerce و افزونه‌های نصب‌شده سازگار باشند.

برای Redis، فقط وضعیت اجرای سرویس کافی نیست. استفاده از حافظه، Eviction، تعداد اتصال‌ها و روند Cache Hit/Miss را نیز در صورت دسترسی ببینید. روی سروری که Redis دارای احراز هویت است، رمز را در خط فرمان عمومی نگذارید. افت Hit Rate همراه با افزایش Query دیتابیس می‌تواند نشانه تغییر تنظیم Cache باشد؛ اما اثبات نمی‌کند علت اصلی کندی حتماً Redis است.

آیا پاک‌کردن Cache همیشه سرعت فروشگاه را بهتر می‌کند؟

خیر. تخلیه بی‌برنامه Cache ممکن است بار ناگهانی به PHP و MySQL وارد کند. ابتدا ببینید آیا داده کهنه ناشی از Cache صفحه، Object Cache یا منطق افزونه است. بعد از تغییر قوانین، مسیرهای حساس را در محیط آزمایش و با چند کاربر مستقل بسنجید.

گام پنجم: WP-Cron و Action Scheduler را جدا پایش کنید

وردپرس با WP-Cron رویدادهای زمان‌بندی‌شده را مدیریت می‌کند. در پیکربندی‌های رایج، اجرای آن به ترافیک یا فراخوانی زمان‌بندی‌شده وابسته است؛ بنابراین در فروشگاه کم‌ترافیک ممکن است کارها با تأخیر اجرا شوند. در WooCommerce، Action Scheduler اجرای بسیاری از فعالیت‌های پس‌زمینه افزونه‌ها را مدیریت می‌کند و خودش وضعیت‌های Pending، Running، Complete و Failed دارد.

برای بررسی بدون تغییر داده، از Tools > Scheduled Actions در مسیرهای مدیریتی WooCommerce، یا در صورت فعال‌بودن WP-CLI، از فرمان‌های خواندنی استفاده کنید. مسیر دقیق منو با نسخه WooCommerce تغییر می‌کند. در مستندات Action Scheduler و راهنمای رسمی WP-Cron نحوه زمان‌بندی شرح داده شده است.

# Read-only WP-CLI examples, run as the authorized site user:
wp core version
wp cron event list --fields=hook,next_run_relative,recurrence
wp plugin list --status=active

اگر wp نصب نشده، فرمان‌ها اجرا نمی‌شوند و نیازی نیست صرفاً برای خواندن این مقاله چیزی نصب کنید. اجرای wp cron event run --due-now از نوع مشاهده‌ای نیست و می‌تواند عملیات واقعی ارسال ایمیل یا تغییر سفارش را آغاز کند؛ بدون برنامه و مجوز آن را روی Production اجرا نکنید.

در صف Action Scheduler کدام شاخص مهم‌تر است؟

تعداد کل Pendingها مفید است، ولی سن قدیمی‌ترین کار مهم و روند افزایش خطای Failed ممکن است هشدار دقیق‌تری بدهند. برای مثال، اگر اجرای Action مربوط به انقضای رزرو یا همگام‌سازی موجودی عقب افتاده است، باید بررسی کنید علت، کمبود ظرفیت PHP است یا خطای افزونه یا وابستگی بیرونی. هر Pending لزوماً مشکل نیست؛ بعضی کارها برای ساعت آینده برنامه‌ریزی شده‌اند.

گام ششم: Checkout و Callback درگاه پرداخت را مستقل بررسی کنید

سبد خرید می‌تواند سالم باشد و در همان زمان Callback درگاه پرداخت خطای ۴۰۳ یا ۵۰۰ بدهد. مانیتورینگ نباید پرداخت ناموفق را فقط به قطعی دامنه نسبت دهد. زمان پاسخ Endpoint پرداخت، خطاهای PHP، حالت سفارش قبل و بعد از Callback و شناسه تراکنش در حد مجاز باید قابل پیگیری باشند. هر پرداخت واقعی را فقط از روی پاسخ HTTP 200، موفق اعلام نکنید؛ صحت نتیجه به فرایند اعتبارسنجی تراکنش و قرارداد درگاه بستگی دارد.

برای تست وضعیت Checkout از محیط آزمایشی درگاه یا مسیر Test مجاز استفاده کنید. ایجاد خرید یا شارژ واقعی از یک Probe مانیتورینگ می‌تواند عملیات مالی ناخواسته ایجاد کند. بعضی افزونه‌های پرداخت در صورت اختلال شبکه Retry می‌کنند؛ باید جلوگیری از ثبت دوباره پرداخت و وضعیت Order بررسی شود.

گام هفتم: مشکل WooCommerce را از روی هم‌بستگی زمان پیدا کنید

نمونه فرضی: ساعت ۱۲:۱۰ خطاهای ۵۰۲ افزایش یافته‌اند، Workerهای PHP-FPM پر شده‌اند، و Action Scheduler چند کار سنگین هم‌زمان شروع کرده است. در همان بازه، اتصال‌های MariaDB به سقف نزدیک شده‌اند. برای تصمیم، این نشانه‌ها را در یک Timeline قرار دهید و تغییرات افزونه یا Deploy همان روز را کنارشان ببینید. افزایش ناگهانی CPU یا یک خطای Log به‌تنهایی علت اصلی نیست؛ لازم است شواهد چند لایه با هم سازگار باشند.

علامت فروشگاه	اولین بررسی	مسیر عیب‌یابی بعدی
صفحه محصول سریع، Checkout کند	Cache صفحه و زمان درخواست پویا	PHP-FPM، DB و افزونه پرداخت
درخواست ۵۰۲ هنگام اوج فروش	Upstream و Workerهای PHP	Timeout، صف، Slow Log و DB
ایمیل سفارش دیر می‌رسد	Action Scheduler و صف ارسال	WP-Cron، سرویس ایمیل و خطاها
موجودی با تأخیر به‌روز می‌شود	کارهای پس‌زمینه و Log افزونه	قفل دیتابیس و اتصال سیستم انبار
اطلاعات سبد اشتباه نمایش داده می‌شود	قوانین Full-Page Cache	Session، Object Cache و افزونه‌ها

آستانه هشدار را بر اساس اثر تجاری تعیین کنید

برای WooCommerce، دو دقیقه عدم پاسخ‌گویی Checkout در ساعت فروش ویژه ممکن است از چند ساعت افزایش ملایم CPU مهم‌تر باشد. هشدارها را از روی نرخ خطای درخواست‌های حساس، تأخیر p95، سن کارهای حیاتی صف، فضای آزاد دیسک و وضعیت سرویس‌ها تعریف کنید. برای کاهش پیام‌های تکراری، راهنمای طراحی هشدار هوشمند سرور به تفکیک Severity و Recovery می‌پردازد.

در کنار هشدار، مشخص کنید کدام فرد مسئول پاسخ و اقدام امن است. راهکار پیشگیرانه ممکن است محدودکردن کارهای غیرضروری هنگام اوج فروش باشد؛ اما توقف Cron یا افزونه پرداخت بدون شناخت وابستگی‌ها می‌تواند سفارش‌های بیشتری را مختل کند.

چک‌لیست عملی پایش فروشگاه وردپرسی

• آدرس عمومی و Endpointهای غیرمخرب کلیدی به‌صورت بیرونی پایش می‌شوند.
• مصرف CPU، RAM، دیسک، inode و روند منابع Host ثبت می‌شود.
• PHP-FPM و وب‌سرور از نظر Worker، خطا و زمان پاسخ بررسی می‌شوند.
• MariaDB یا MySQL از نظر Query کند، قفل و اتصال‌ها تحت نظر است.
• وضعیت Redis و تفاوت Object Cache با Cache صفحه در تیم مشخص است.
• Action Scheduler و WP-Cron از نظر تأخیر واقعی کارهای مهم بررسی می‌شوند.
• تست Checkout از داده و درگاه آزمایشی استفاده می‌کند و پرداخت واقعی ناخواسته ایجاد نمی‌کند.
• لاگ‌ها فاقد Token، Session و اطلاعات کارت پرداخت‌اند و دسترسی به آن‌ها محدود است.
• روش بازیابی بکاپ و Rollback افزونه‌ها پیش از حادثه آزمایش شده است.

Avaztek Monitoring برای زیرساخت WooCommerce چه کاربردی دارد؟

Avaztek Monitoring طبق معرفی فعلی محصول، برای پایش CPU، RAM، Disk، شبکه، سرویس‌ها و Logهای جمع‌آوری‌شده از سرورهای لینوکسی ابزار دارد. قابلیت‌هایی مانند Log Explorer، هشدار، Recovery و بررسی شبکه و SSL کمک می‌کنند هنگام کندی فروشگاه، وضعیت میزبان و خطاهای سیستم را در یک Timeline بررسی کنید.

این ابزار به‌خودی‌خود نشان نمی‌دهد کدام افزونه WooCommerce خطا داشته یا چند سفارش واقعاً موفق پرداخت شده‌اند؛ برای این داده‌ها باید Log برنامه، ابزار WordPress و اتصال متناسب داشته باشید. اگر هدف پایش سرور فروشگاهی است، قابلیت‌های جاری و پلن مناسب را در صفحه امکانات مانیتورینگ آوازتک بررسی کنید و برای آغاز از ثبت‌نام سامانه استفاده کنید. بهتر است ابتدا یک میزبان غیرحیاتی را متصل و داده را با خروجی مستقیم سیستم‌عامل تطبیق دهید.

پرسش‌های متداول مانیتورینگ وردپرس و ووکامرس

چرا صفحه اصلی وردپرس سالم است اما پرداخت WooCommerce خطا دارد؟

صفحه اصلی ممکن است کش شود، ولی Checkout مسیر پویا با PHP، دیتابیس، نشست و درگاه پرداخت است. بنابراین باید زمان پاسخ و خطای همان مسیر را همراه با PHP-FPM و وضعیت سفارش بررسی کنید.

آیا مصرف بالای RAM سرور وردپرس همیشه مشکل است؟

خیر. Linux از RAM برای Cache نیز استفاده می‌کند. مقدار حافظه قابل دسترس، نرخ Swap، تعداد Workerهای PHP و زمان پاسخ فروشگاه از درصد Used به‌تنهایی مهم‌ترند.

Redis برای WooCommerce چه چیزی را سریع‌تر می‌کند؟

در صورت پیکربندی درست، Object Cache می‌تواند مراجعه مکرر به پایگاه‌داده را کاهش دهد. اما Cache کردن HTML اختصاصی Checkout یا سبد بدون سیاست صحیح ممکن است داده کهنه یا نامناسب نشان دهد.

WP-Cron و Action Scheduler چه تفاوتی دارند؟

WP-Cron سامانه زمان‌بندی رویدادهای وردپرس است؛ Action Scheduler صف و برنامه‌ریز اجرای کارهای پس‌زمینه است که WooCommerce و افزونه‌ها از آن استفاده می‌کنند. باید به‌ویژه وضعیت کارهای دیرشده و Failed را بررسی کرد.

آیا مانیتورینگ CPU برای فروشگاه WooCommerce کافی است؟

خیر. مشکل پرداخت یا سفارش ممکن است با CPU عادی رخ دهد. PHP-FPM، DB، Redis، صف‌ها، مسیر Callback پرداخت و خطاهای HTTP باید در کنار منابع سخت‌افزار بررسی شوند.

آیا Avaztek Monitoring افزونه خراب وردپرس را خودکار اصلاح می‌کند؟

بر اساس قابلیت‌های معرفی‌شده، سامانه برای پایش منابع، سرویس‌ها و لاگ‌ها است؛ رفع خودکار خطای افزونه یا تضمین موفقیت پرداخت جزء ادعاهای این راهنما نیست. تحلیل دقیق افزونه به داده برنامه و بررسی توسعه‌دهنده نیاز دارد.

جمع‌بندی: سلامت WooCommerce را از مسیر سفارش بسنجید

مانیتورینگ سرور وردپرس و WooCommerce یعنی بدانید آیا PHP، دیتابیس، Cache و صف‌ها در همان زمانی که مشتری سفارش ثبت می‌کند سالم‌اند یا نه. با پایش منابع سرور شروع کنید، سپس سنجه‌های اختصاصی Checkout و کارهای پس‌زمینه را اضافه کنید. برای مشاهده پیوسته سلامت زیرساخت لینوکسی، Avaztek Monitoring را در کنار ابزارهای داخلی WooCommerce ارزیابی کنید.