آموزش مانیتورینگ وردپرس و بررسی لاگ‌ها؛ Uptime، خطاهای PHP و گزارش‌های ووکامرس

ارسال توسط Dev Source

24 مهر 1405

منتشرشده در 6 مرداد 1405

🗓 آخرین به‌روزرسانی: 24 مهر 1405

📚 این آموزش بخشی از آموزش جامع وردپرس از صفر تا حرفه‌ای است؛ مسیر کامل یادگیری را آنجا ببینید.

مانیتورینگ وردپرس یعنی پیش از آنکه مشتری، موتور جست‌وجو یا شرکت درگاه خرابی سایت را گزارش کند، خودتان از قطعی، کندی، خطای PHP، شکست Cron، ایمیل ارسال‌نشده، پرداخت ناموفق، تغییر امنیتی و پرشدن منابع سرور مطلع شوید. سایت ممکن است از بیرون باز شود، اما Checkout کار نکند؛ ممکن است صفحه محصول سریع باشد، اما Jobهای پس‌زمینه چند روز اجرا نشده باشند؛ یا ممکن است سفارش ثبت شود، اما ایمیل و لینک دانلود به مشتری نرسد. یک مانیتور ساده که فقط HTTP 200 صفحه اصلی را می‌بیند، این مشکلات را تشخیص نمی‌دهد.

مانیتورینگ حرفه‌ای سه نوع داده را کنار هم قرار می‌دهد: Metric برای عددهایی مانند زمان پاسخ و مصرف CPU، Log برای رویدادها و خطاها، و Trace یا Correlation برای دنبال‌کردن یک درخواست از مرورگر تا PHP، WooCommerce، درگاه و ایمیل. هدف جمع‌کردن بی‌پایان داده نیست؛ هدف این است که هر هشدار به یک اقدام روشن منتهی شود.

در این راهنما، Uptime Monitoring خارجی، Site Health، System Status، PHP Error Log، Access Log، LiteSpeed، Activity Log، گزارش‌های WooCommerce، WP-Cron، Action Scheduler، درگاه، ایمیل، دانلود، شاخص‌های عملکرد و طراحی هشدار بدون Alert Fatigue را مرحله‌به‌مرحله بررسی می‌کنیم.

وضعیت فعلی سایت: dev-source.ir روی WordPress 7.0.2، WooCommerce 10.9.4 و LiteSpeed Cache 7.8.1 اجرا می‌شود و منطقه زمانی وردپرس روی Asia/Tehran قرار دارد. یک آمارگیر سفارشی سبک فعال است، اما افزونه اختصاصی Uptime، Activity Log یا Error Monitoring در فهرست افزونه‌های فعال مشاهده نشد. وجود مانیتور خارجی در هاست یا CDN از داخل وردپرس قابل تأیید نیست. این مقاله هیچ تنظیم عملیاتی مانیتورینگ یا Debug را روی سایت زنده تغییر نمی‌دهد.

مانیتورینگ وردپرس باید چه سؤال‌هایی را پاسخ دهد؟

آیا سایت از چند نقطه اینترنت قابل دسترسی است؟
آیا صفحه محصول، Cart و Checkout واقعاً کار می‌کنند؟
زمان پاسخ سرور و TTFB در محدوده عادی است؟
خطاهای ۵۰۰، ۴۰۳، ۴۲۹ و JavaScript افزایش یافته‌اند؟
WP-Cron و Action Scheduler وظایف را سر وقت اجرا می‌کنند؟
پرداخت‌های Failed یا Pending غیرعادی شده‌اند؟
ایمیل‌های سفارش و بازیابی رمز تحویل می‌شوند؟
موجودی، دانلود و سفارش‌ها رفتار غیرعادی ندارند؟
کاربر مدیر، افزونه یا تنظیم حساس بدون مجوز تغییر نکرده است؟
فضای دیسک، Memory، PHP Worker و دیتابیس به مرز خطر نزدیک نشده‌اند؟

هر ابزار فقط بخشی از این سؤال‌ها را پاسخ می‌دهد. Uptime Monitor خطای PHP را توضیح نمی‌دهد و Activity Log نیز مصرف RAM سرور را نشان نمی‌دهد؛ بنابراین معماری چندلایه لازم است.

تفاوت Monitoring، Logging و Analytics

Monitoring

وضعیت سیستم را به‌صورت مستمر بررسی و هنگام عبور از شرط مشخص هشدار می‌دهد؛ مانند قطعی دو دقیقه‌ای یا افزایش خطای ۵۰۰.

Logging

جزئیات رویداد را ذخیره می‌کند؛ مانند نام Hook شکست‌خورده، مسیر فایل خطادار یا پاسخ درگاه.

Analytics

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

افزونه آمارگیر یا WooCommerce Analytics جایگزین Uptime و Error Monitoring نیست. راهنمای تحلیل فروش در مقاله آموزش گزارش‌های ووکامرس قرار دارد.

لایه اول: Uptime Monitoring خارجی

مانیتور Uptime باید خارج از همان هاست اجرا شود. اگر ابزار داخل WordPress یا همان سرور باشد، هنگام خاموش‌شدن سرور خودش نیز از کار می‌افتد و نمی‌تواند هشدار بدهد.

چه URLهایی را بررسی کنیم؟

صفحه اصلی
یک صفحه نوشته عمومی
یک محصول منتشرشده
صفحه Cart
Checkout بدون اجرای پرداخت
REST API یا Endpoint سلامت محدود
صفحه ورود یا My Account با نرخ کنترل‌شده

برای Cart و Checkout فقط در دسترس‌بودن و وجود عناصر مشخص را بررسی کنید. مانیتور نباید هر چند دقیقه سفارش رهاشده یا تراکنش واقعی بسازد.

چرا HTTP 200 کافی نیست؟

گاهی CDN یک صفحه خطای سفارشی را با کد ۲۰۰ نمایش می‌دهد یا صفحه اصلی باز است ولی محتوای اصلی به‌دلیل خطای دیتابیس خالی شده است. بررسی بهتر شامل این موارد است:

Status Code مورد انتظار
وجود یک عبارت یا عنصر ثابت در پاسخ
نبود عبارت‌هایی مانند Critical Error یا Database Error
زمان پاسخ
اعتبار گواهی SSL
تعداد Redirectها
اندازه تقریبی پاسخ

در مانیتورهای حرفه‌ای می‌توان Hash بخشی از صفحه یا Selector مشخص را بررسی کرد؛ اما تغییر محتوای عادی نباید هشدار کاذب ایجاد کند.

فاصله مناسب بررسی Uptime

بازه ثابت برای همه سایت‌ها وجود ندارد. نمونه محافظه‌کارانه:

صفحه اصلی: هر ۱ تا ۵ دقیقه
محصول و Checkout: هر ۵ دقیقه
SSL Expiration: روزانه
DNS و دامنه: روزانه

قبل از اعلان قطعی، دو یا سه تلاش از Location متفاوت انجام شود تا اختلال موقت شبکه یک هشدار بحرانی تولید نکند.

Uptime با Availability یکسان نیست

سایت ممکن است آنلاین باشد، اما عملاً قابل خرید نباشد. برای فروشگاه باید Synthetic Checkهای امن طراحی شود:

بازکردن محصول
بررسی امکان افزودن به سبد
بازکردن Cart
رسیدن به Checkout
بررسی بارگذاری روش پرداخت یا پیام مورد انتظار

این سناریو روی Staging و سپس با کاربر و محصول آزمایشی کنترل شود. اجرای خودکار پرداخت واقعی در Production بدون طراحی دقیق توصیه نمی‌شود.

مانیتور SSL، DNS و دامنه

تاریخ انقضای گواهی SSL
تغییر Issuer یا Hostname
زنجیره Certificate
تغییر Nameserver
تغییر رکورد A یا CNAME
انقضای دامنه

هشدار SSL باید پیش از انقضا ارسال شود؛ مثلاً در آستانه‌های ۳۰، ۱۴ و ۷ روز. این عددها نمونه عملیاتی‌اند و می‌توانند با فرایند تمدید شما تغییر کنند.

طراحی هشدار بدون Alert Fatigue

اگر هر خطای کوچک اعلان فوری تولید کند، تیم پس از مدتی هشدارها را نادیده می‌گیرد. Alert باید Severity و اقدام مشخص داشته باشد.

Critical

سایت از چند Location قطع است.
Checkout یا درگاه از کار افتاده است.
خطای ۵۰۰ گسترده وجود دارد.
فضای دیسک در آستانه توقف سرویس است.
پرداخت به مقصد ناشناس تغییر کرده است.

Warning

TTFB از محدوده عادی بیشتر شده است.
تعداد Actionهای Pending رو به افزایش است.
چند خطای PHP تکراری دیده می‌شود.
SSL کمتر از چند هفته اعتبار دارد.

Info

آپدیت برنامه‌ریزی‌شده انجام شده است.
Backup موفق بوده است.
Job نگهداری کامل شده است.

برای Maintenance Window اعلان قطعی را موقتاً Silence کنید، اما ثبت Event را متوقف نکنید.

لایه دوم: Site Health وردپرس

مسیر Tools → Site Health دو تب اصلی دارد:

Status: مشکلات Critical، Recommended و تست‌های Passed
Info: نسخه وردپرس، افزونه‌ها، قالب، Server، Database، Constants، Permissionها و اندازه پوشه‌ها

Site Health برای تشخیص اولیه بسیار مفید است، اما امتیاز آن تضمین امنیت یا سلامت کامل نیست. ممکن است همه تست‌ها سبز باشند ولی درگاه یا افزونه سفارشی خطا داشته باشد.

اطلاعات Exportشده Site Health شامل جزئیات فنی سرور و افزونه‌هاست. آن را فقط در تیکت خصوصی پشتیبانی ارسال کنید و در انجمن عمومی همراه اطلاعات حساس منتشر نکنید.

Site Health را چه زمانی بررسی کنیم؟

بعد از آپدیت WordPress، قالب یا افزونه
پس از تغییر PHP یا هاست
هنگام شکست Cron یا REST API
قبل از درخواست پشتیبانی
پس از مهاجرت یا Restore

برای آپدیت کنترل‌شده، مقاله آموزش به‌روزرسانی امن وردپرس را مطالعه کنید.

لایه سوم: WooCommerce System Status

از WooCommerce → Status می‌توانید اطلاعات محیط فروشگاه را ببینید:

نسخه WooCommerce و WordPress
Memory Limit
WP-Cron
Log Directory
صفحات ضروری WooCommerce
Theme و Template Overrideها
ویژگی‌هایی مانند HPOS
Database Version و جدول‌ها
Scheduled Actions

قبل از ارسال تیکت، System Status Report را Download یا Copy کنید. این گزارش برای یافتن ناسازگاری نسخه، Template قدیمی و محدودیت سرور مفید است.

Template Override قدیمی

WoodMart و Child Theme ممکن است فایل‌های WooCommerce را Override کنند. اگر نسخه Template از نسخه هسته عقب مانده باشد، بخشی از Checkout، ایمیل یا My Account می‌تواند ناسازگار شود.

هشدار Outdated Template را فقط با کپی‌کردن فایل جدید روی سفارشی‌سازی قبلی رفع نکنید. تفاوت‌ها را مقایسه و تغییرهای لازم را Merge کنید.

لایه چهارم: PHP Error Log

خطاهای PHP می‌توانند علت صفحه سفید، Critical Error، درخواست ۵۰۰، Job شکست‌خورده و کندی غیرعادی باشند. بهترین منبع در Production معمولاً Error Log وب‌سرور یا PHP-FPM است.

منابع رایج

پنل هاست و بخش Errors
PHP-FPM Error Log
LiteSpeed یا Apache Error Log
WooCommerce fatal-errors Log
WordPress debug.log در عیب‌یابی موقت

فعال‌سازی موقت WP_DEBUG_LOG

در محیط کنترل‌شده می‌توان این تنظیم‌ها را پیش از خط «That’s all, stop editing» در wp-config.php قرار داد:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

در حالت پیش‌فرض، Log در wp-content/debug.log نوشته می‌شود. WordPress همچنین اجازه می‌دهد یک مسیر کامل برای WP_DEBUG_LOG تعیین کنید:

define( 'WP_DEBUG_LOG', '/secure-path/wp-errors.log' );

برای Production بهتر است Log خارج از Web Root و با Permission محدود باشد. WP_DEBUG را برای همیشه روشن نگذارید؛ پس از تشخیص، تنظیم را به حالت عادی برگردانید یا Error Logging را در سطح سرور مدیریت کنید.

چرا WP_DEBUG_DISPLAY باید خاموش باشد؟

نمایش Warning و Stack Trace در Frontend می‌تواند مسیر فایل، نام افزونه، Query، ساختار سرور یا داده حساس را به بازدیدکننده نشان دهد. خطا باید ثبت شود، نه اینکه داخل HTML صفحه محصول یا Checkout نمایش داده شود.

نحوه خواندن یک خطای PHP

مثال ساختاری:

[date time] PHP Fatal error: Uncaught TypeError ...
in /path/wp-content/plugins/example/plugin.php:125

برای تحلیل:

زمان خطا را با رخداد کاربر تطبیق دهید.
Severity را مشخص کنید: Notice، Warning، Deprecated، Fatal.
نخستین فایل متعلق به افزونه یا قالب را پیدا کنید.
Stack Trace را از پایین و بالا بررسی نمایید.
نسخه PHP و افزونه را ثبت کنید.
خطا را روی Staging بازتولید کنید.

فایلی که در آخر Stack Trace دیده می‌شود همیشه عامل اصلی نیست. اولین کد سفارشی یا افزونه‌ای که ورودی نامعتبر ایجاد کرده، اهمیت بیشتری دارد.

Notice و Deprecated را نادیده بگیریم؟

این پیام‌ها معمولاً سایت را فوراً متوقف نمی‌کنند، اما می‌توانند نشانه ناسازگاری آینده باشند. اگر هزاران بار تکرار شوند، Log و Disk I/O را افزایش می‌دهند.

روش درست حذف Log نیست؛ افزونه یا کد تولیدکننده پیام باید اصلاح یا به‌روزرسانی شود.

لایه پنجم: Access Log وب‌سرور

Access Log نشان می‌دهد چه IP و User Agent با چه Method و Status Code به کدام URL درخواست داده است. فیلدهای مفید:

Timestamp
IP واقعی
Request Method
Path و Query
Status Code
Response Size
Referer
User Agent
Response Time در صورت پیکربندی

برای تحلیل حمله یا کندی، Access Log را با WAF، PHP Log و WooCommerce Log در یک بازه زمانی مقایسه کنید.

Status Codeهای مهم

200: پاسخ موفق؛ لزوماً عملکرد صحیح نیست.
301/302: Redirect؛ افزایش غیرعادی می‌تواند Loop باشد.
401/403: مشکل احراز یا Block توسط WAF.
404: URL گمشده یا اسکن Bot.
429: Rate Limit.
500: خطای برنامه یا سرور.
502/503/504: مشکل Upstream، Worker، Timeout یا Maintenance.

یک ۴۰۴ منفرد بحرانی نیست. نرخ خطا نسبت به کل درخواست و مسیرهای درگیر مهم است.

IP واقعی پشت Cloudflare یا Proxy

اگر Reverse Proxy فعال باشد، وب‌سرور ممکن است IP شبکه Proxy را ثبت کند. تنظیم بازیابی IP واقعی باید فقط Header مورد اعتماد Proxy را بپذیرد؛ قبول‌کردن Header دلخواه کاربر امکان جعل IP را ایجاد می‌کند.

جزئیات WAF و Origin در مقاله آموزش فایروال وردپرس توضیح داده شده است.

لایه ششم: لاگ‌های WooCommerce

مسیر WooCommerce → Status → Logs مرکز اصلی بررسی خطاهای فروشگاه است. WooCommerce و افزونه‌های سازگار Logها را براساس Source ثبت می‌کنند.

Sourceهای رایج

fatal-errors
نام درگاه پرداخت
transactional-emails
Webhookها
Import و Export
Shipping یا Tax Service
افزونه‌های سفارشی

برخی Logها خودکارند، اما درگاه یا افزونه ممکن است Debug Logging جدا داشته باشد که باید موقتاً از تنظیمات همان افزونه فعال شود.

تنظیمات Logger ووکامرس

در WooCommerce → Status → Logs → Settings معمولاً این موارد قابل تنظیم‌اند:

فعال یا غیرفعال‌بودن Logger
ذخیره در File System یا Database
Retention Period
Level Threshold

برای سایت زنده، File System روش پیش‌فرض و معمولاً سبک‌تر است. ذخیره همه Logها در Database می‌تواند حجم جدول را بالا ببرد. تغییر Storage، Logهای قبلی را خودکار به محل جدید منتقل نمی‌کند.

Levelهای Log

Emergency
Alert
Critical
Error
Warning
Notice
Info
Debug

Threshold بالا، Logهای کم‌اهمیت را حذف می‌کند؛ اما هنگام عیب‌یابی ممکن است اطلاعات لازم از دست برود. Debug را فقط برای دوره محدود فعال کنید و پس از پایان خاموش نمایید.

امنیت مسیر wc-logs

در حالت File System، WooCommerce فایل‌ها را معمولاً داخل زیرپوشه wc-logs از Uploads قرار می‌دهد و برای Apache فایل محافظ اضافه می‌کند. همه وب‌سرورها الزاماً .htaccess را اجرا نمی‌کنند. در صورت امکان، مسیر Log را خارج از Web Root قرار دهید و دسترسی مستقیم را آزمایش کنید.

چه اطلاعاتی نباید داخل Log باشد؟

رمز عبور
کد TOTP و Recovery Code
Secret Key درگاه
Application Password
شماره کامل کارت
Cookie و Session Token
فایل یا لینک خصوصی بدون Mask

ایمیل، تلفن، IP و آدرس نیز داده شخصی‌اند. Retention و دسترسی Log باید با سیاست حریم خصوصی هماهنگ باشد.

لاگ درگاه پرداخت

برای خطای پرداخت این زنجیره را دنبال کنید:

Order Note
Log افزونه درگاه
Access Log مسیر Callback
WAF Event
پنل پذیرنده
Transaction ID

Debug Mode درگاه ممکن است Request و Response حساس ثبت کند. Log را فقط هنگام نیاز فعال، پس از رفع خطا غیرفعال و فایل‌های قدیمی را طبق سیاست پاک کنید.

راهنمای کامل در مقاله تنظیم درگاه پرداخت ووکامرس قرار دارد.

لاگ ایمیل‌های تراکنشی

Source با نام transactional-emails می‌تواند وضعیت ایجاد و تحویل ایمیل ووکامرس به Mailer را نشان دهد. وضعیت Sent به معنی ورود قطعی به Inbox نیست؛ برای تحویل نهایی باید SMTP Log، Bounce و گزارش سرویس مقصد بررسی شود.

مقاله آموزش ایمیل‌های ووکامرس این فرایند را توضیح می‌دهد.

لایه هفتم: Activity Log

Activity Log پاسخ می‌دهد چه کسی، چه چیزی را، در چه زمانی و از کدام IP تغییر داده است. برای سایت دارای تیم یا فروشگاه، رویدادهای مهم عبارت‌اند از:

Login موفق و ناموفق
تغییر Role و User
ساخت Administrator
نصب، فعال‌سازی یا حذف افزونه
تغییر قالب و Customizer
ویرایش فایل یا Snippet
تغییر URL، ایمیل مدیر و Permalink
تغییر محصول، قیمت، موجودی و کوپن
تغییر وضعیت سفارش و Refund
تغییر درگاه و Webhook

Activity Log باید Actor، Object، Action، Timestamp و نتیجه را ذخیره کند؛ اما Secret و Payload حساس را ثبت نکند.

انتخاب افزونه Activity Log

پیش از نصب بررسی کنید:

سازگاری با WordPress و WooCommerce فعلی
پشتیبانی از HPOS
Retention و پاک‌سازی خودکار
Export و جست‌وجو
هشدار رویدادهای حساس
مصرف دیتابیس
عدم ثبت داده حساس
امکان ذخیره خارج از دیتابیس سایت

روی dev-source.ir افزونه Activity Log اختصاصی مشاهده نشد. نصب آن باید ابتدا روی Staging و همراه افزونه‌های سفارشی آزمایش شود.

لایه هشتم: WP-Cron

WP-Cron زمان‌بندی وظایف وردپرس را مدیریت می‌کند. این سیستم در حالت معمول هنگام Page Load بررسی می‌کند کدام Event باید اجرا شود. در سایت کم‌ترافیک ممکن است Job با تأخیر اجرا شود و در سایت پرترافیک فراخوانی‌های مکرر منابع اضافی مصرف کنند.

وظایف وابسته به Cron

انتشار نوشته زمان‌بندی‌شده
بررسی Update
پاک‌سازی داده‌های موقت
ارسال بعضی ایمیل‌ها
Jobهای افزونه‌ها
نگهداری WooCommerce

تست WP-Cron با WP-CLI

wp cron test

این دستور بررسی می‌کند Spawn سیستم Cron از طریق HTTP کار می‌کند یا خیر.

فهرست Eventها:

wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence

اجرای Eventهای Due:

wp cron event run --due-now

اجرای دستی ممکن است ایمیل، پاک‌سازی، Webhook یا عملیات مالی را فعال کند. دستور را فقط با Backup و شناخت Hook اجرا کنید.

استفاده از System Cron

برای اجرای دقیق‌تر می‌توان Scheduler سیستم‌عامل یا cPanel را تنظیم کرد و سپس فراخوانی Page Load را غیرفعال نمود:

define( 'DISABLE_WP_CRON', true );

این Constant را فقط پس از ساخت و تست Cron واقعی فعال کنید. اگر System Cron تنظیم نشده باشد، Jobهای زمان‌بندی‌شده متوقف می‌شوند.

لایه نهم: Action Scheduler

WooCommerce و بسیاری از افزونه‌ها برای Jobهای پس‌زمینه از Action Scheduler استفاده می‌کنند. مسیر:

WooCommerce → Status → Scheduled Actions

وضعیت‌ها

Pending
In-progress
Complete
Failed
Canceled

در صفحه Action می‌توانید Hook، Group، زمان، Argumentها و Log اجرای آن را مشاهده کنید.

نشانه‌های مشکل Action Scheduler

افزایش مداوم Pendingها
تکرار Failed برای یک Hook
Actionهای In-progress قدیمی
ایمیل یا Webhook با تأخیر
Analytics به‌روز نمی‌شود.
Import مرحله‌ای متوقف شده است.

Action Scheduler در مستندات خود توضیح می‌دهد Action طولانی‌تر از حدود پنج دقیقه ممکن است Timeout و Failed فرض شود و در صورت تکمیل بعدی، وضعیتش تغییر کند. بنابراین فقط Status را نبینید؛ Log همان Action را بخوانید.

آیا Action Failed را دوباره Run کنیم؟

قبل از Run مجدد:

Hook و افزونه مالک را پیدا کنید.
خطا را در PHP یا Woo Log بررسی نمایید.
بررسی کنید عملیات Idempotent است یا تکرار آن داده دوباره می‌سازد.
از دیتابیس Backup بگیرید.
روی Staging بازتولید کنید.

تکرار Job پرداخت، ایمیل یا Import بدون شناخت می‌تواند عملیات تکراری ایجاد کند.

لایه دهم: عملکرد و منابع سرور

حداقل Metricهای سرور:

CPU Usage و Load Average
RAM و Swap
Disk Space و Inode
Disk I/O
PHP-FPM یا LiteSpeed Worker
Database Connection و Slow Query
Object Cache Hit Ratio
HTTP Response Time و TTFB
۵xx Rate

یک Snapshot لحظه‌ای کافی نیست. Trend یک ساعت، یک روز و یک هفته را مقایسه کنید تا رشد تدریجی دیده شود.

هشدار فضای دیسک

پرشدن دیسک می‌تواند Upload، Session، Log، Cache، دیتابیس و Backup را متوقف کند. سیاست نمونه:

Warning در ۷۵ یا ۸۰ درصد
Critical در ۹۰ درصد
بررسی جداگانه Inode

عددها باید با اندازه دیسک و سرعت رشد تنظیم شوند. فایل‌های Backup و Log قدیمی از علت‌های رایج رشد ناگهانی هستند.

LiteSpeed Cache را چه‌طور مانیتور کنیم؟

Cache Hit و Miss
صفحه‌های Excludeشده
QUIC.cloud یا CDN
Purgeهای غیرعادی
Critical CSS و Image Optimization Queue
Object Cache Connection
خطاهای Crawler

Cart، Checkout و My Account نباید Cache عمومی شوند. بعد از تغییر LiteSpeed، خرید مهمان و حساب‌دار را تست کنید.

Slow Query و دیتابیس

کندی دیتابیس می‌تواند از این موارد باشد:

Optionهای Autoload بزرگ
جدول Log بدون Retention
Action Scheduler انباشته
Sessionهای ووکامرس
Query افزونه سفارشی
فیلتر محصول بدون Index مناسب

Query Monitor برای عیب‌یابی Staging مفید است، اما روی Production پرترافیک باید با احتیاط استفاده شود؛ خودش سربار و اطلاعات حساس ایجاد می‌کند.

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

گاهی زیرساخت سالم است، اما کسب‌وکار مشکل دارد. شاخص‌های عملیاتی:

تعداد سفارش در ساعت نسبت به الگوی معمول
نرخ Failed و Pending Payment
نرخ Refund
کاهش ناگهانی Conversion
افزایش سفارش صفر یا کوپن غیرعادی
محصول Out of Stock پرفروش
دانلود غیرعادی از یک سفارش
عدم ارسال ایمیل Processing

هشدار باید براساس Baseline سایت ساخته شود. فروش صفر در ساعت سه صبح شاید طبیعی باشد، اما در ساعت اوج کمپین می‌تواند بحرانی باشد.

مانیتورینگ سفارش و پرداخت

Pending Payment

افزایش آن می‌تواند از خطای درگاه، Callback، واحد پول یا Checkout باشد.

Failed

تعداد و پیام خطا را براساس درگاه و دستگاه مقایسه کنید.

On Hold

در روش انتقال بانکی طبیعی است، اما انباشت بدون بررسی مشکل عملیاتی ایجاد می‌کند.

Refund

افزایش Refund باید با محصول، دلیل، کمپین و درگاه تحلیل شود.

راهنمای وضعیت‌ها در مقاله مدیریت سفارش‌های ووکامرس قرار دارد.

مانیتورینگ دانلود فایل

برای فروش PDF و کتاب الکترونیک:

تعداد دانلود هر سفارش
IPهای بسیار متعدد
دریافت سریع فایل‌های متعدد
خطای ۴۰۳ یا ۴۰۴ لینک دانلود
فایل گمشده یا Permission ناقص
حجم و Hash فایل اصلی

افزایش Download الزاماً سرقت نیست؛ مشتری می‌تواند فایل را چندبار دریافت کند. الگو و محدودیت قرارداد را بررسی کنید.

مانیتورینگ افزونه‌های سفارشی

سایت فعلی چند افزونه Custom برای Import، PDF، Checkout و اطلاعات محصول دارد. هر افزونه باید Source Log مستقل داشته باشد.

نمونه Logger ووکامرس:

$logger  = wc_get_logger();
$context = array( 'source' => 'custom-product-import' );

$logger->info( 'Import started.', $context );
$logger->error( 'Import failed for product.', $context );

پیام باید شناسه داخلی و مرحله عملیات را ثبت کند، نه Token، رمز یا محتوای کامل مشتری.

Correlation ID

برای دنبال‌کردن یک عملیات میان چند Log، یک شناسه یکتا تولید کنید:

Request ID برای API
Order ID برای پرداخت
Job ID برای Import
Action ID برای Scheduled Action

با این روش می‌توان Log افزونه، WooCommerce، PHP و سرویس خارجی را برای یک رخداد مشخص کنار هم گذاشت.

هماهنگی ساعت و منطقه زمانی

وردپرس سایت فعلی از Asia/Tehran استفاده می‌کند، اما Server Log، Cloudflare، درگاه و سرویس SMTP ممکن است UTC یا منطقه دیگری داشته باشند. هنگام Incident:

Timezone هر منبع را ثبت کنید.
در Dashboard یک منطقه استاندارد انتخاب نمایید.
Timestamp اصلی را تغییر ندهید.
در گزارش، تبدیل زمان را شفاف بنویسید.

اختلاف سه ساعت یا نیم‌ساعت می‌تواند باعث شود رویدادهای مرتبط جدا به‌نظر برسند.

Retention لاگ‌ها

نگهداری نامحدود Log هزینه، ریسک حریم خصوصی و کندی ایجاد می‌کند. سیاست نمونه:

Debug: چند روز
Application Error: چند هفته یا ماه
Security Audit: براساس نیاز حقوقی
Payment Log: حداقل داده و مدت مصوب

نسخه رسمی WooCommerce برای Logger امکان Retention دارد و در مستندات فعلی مقدار پیش‌فرض ۳۰ روز ذکر شده است. مدت واقعی سایت را از تنظیمات بررسی کنید.

Log Rotation

Log باید پس از رسیدن به حجم یا زمان مشخص Rotate و فشرده شود. بدون Rotation:

دیسک پر می‌شود.
جست‌وجو کند می‌شود.
Backup بزرگ می‌شود.
حذف فایل در حال استفاده دشوار می‌شود.

قبل از حذف Log، Incident باز و الزامات نگهداری را بررسی کنید.

Dashboard مانیتورینگ چه چیزهایی نمایش دهد؟

صفحه مدیریت روزانه

Uptime و Response Time
آخرین Backup موفق
خطای ۵۰۰
Failed Action
Failed Payment
Disk و Memory

صفحه هفتگی

Trend TTFB
خطا براساس افزونه
Pending Queue
Login Failure
Refund و Email Failure
آپدیت‌های معوق

Dashboard شلوغ که ده‌ها نمودار بدون Action دارد، ارزش عملی کمی دارد.

Runbook برای هر هشدار

کنار هر Alert بنویسید:

این هشدار چه معنی دارد؟
اولین صفحه یا Log برای بررسی چیست؟
چه کسی مسئول است؟
چه زمانی Escalate شود؟
راه Rollback چیست؟
چگونه Resolve تأیید می‌شود؟

مثال: «Failed Payment بیشتر از حد معمول» → بررسی درگاه، Order Note، Callback، WAF و پنل پذیرنده.

روال روزانه مانیتورینگ

بررسی Alertهای Critical
Failed Order و Failed Action
فضای دیسک و Backup
Fatal Error جدید
ورود مدیر ناشناس

روال هفتگی

Site Health و System Status
Trend سرعت و خطا
Logهای پرتکرار
آپدیت‌های معوق
Retention و حجم جدول‌ها
آزمایش یک ایمیل و یک سفارش

روال ماهانه

Restore آزمایشی Backup
بازبینی User و API Key
Audit افزونه‌های سفارشی
تست Uptime و Alert Route
بازبینی Runbook و شماره تماس‌ها

برنامه پیشنهادی برای dev-source.ir

یک Uptime Monitor خارجی برای صفحه اصلی، محصول و Checkout تعریف شود.
هشدار SSL و Domain Expiry فعال گردد.
Activity Log سازگار با HPOS روی Staging آزمایش شود.
PHP Error Log در سطح هاست مشخص و دسترسی آن مستند گردد.
WooCommerce Logs و Retention بازبینی شوند.
برای افزونه‌های سفارشی Source مستقل و Correlation ID تعریف شود.
WP-Cron با wp cron test بررسی شود.
Scheduled Actions Failed و Pending مانیتور شوند.
هشدار Failed Payment و Email Failure ساخته شود.
Disk، Inode، CPU، RAM و PHP Worker در پنل هاست هشدار داشته باشند.
Dashboard روزانه با حداکثر شاخص‌های قابل اقدام ساخته شود.
هر ماه Restore و Checkout آزمایشی انجام شود.

این برنامه مکمل چک‌لیست امنیت وردپرس و راهنمای بکاپ و بازیابی است.

خطا: سایت آنلاین است ولی مانیتور Down نشان می‌دهد

WAF مانیتور را Challenge کرده است.
Location مانیتور مشکل شبکه دارد.
User Agent یا IP مسدود شده است.
Timeout مانیتور بسیار پایین است.
DNS Cache قدیمی است.

از چند Location و یک Browser واقعی مقایسه کنید. مانیتور را با Allowlist گسترده از همه WAFها عبور ندهید؛ Rule محدود بسازید.

خطا: debug.log بسیار بزرگ شده است

Debug را غیرفعال، فایل را پس از Backup و بررسی Rotate و خطای پرتکرار را از ریشه اصلاح کنید. حذف روزانه Log بدون رفع علت فقط علامت را پنهان می‌کند.

خطا: Cron اجرا نمی‌شود

DISABLE_WP_CRON فعال است ولی System Cron وجود ندارد.
Loopback توسط WAF یا Basic Auth مسدود شده است.
DNS یا SSL مشکل دارد.
PHP Fatal Error رخ می‌دهد.
هاست Cron را محدود کرده است.

wp cron test، Site Health و Error Log را کنار هم بررسی کنید.

خطا: Actionهای Pending زیاد شده‌اند

WP-Cron، PHP Error، Worker، جدول Action Scheduler و Hook پرتکرار را بررسی کنید. پاک‌کردن گروهی Pendingها ممکن است سفارش، ایمیل یا Import را ناقص کند.

خطا: WooCommerce Log خالی است

افزونه موردنظر Logging را فعال نکرده است.
Threshold پیام را حذف می‌کند.
Source متفاوت است.
Storage تغییر کرده است.
پوشه Log قابل نوشتن نیست.

خطا: ساعت Logها با سفارش متفاوت است

Timezone وردپرس، Server، دیتابیس و سرویس خارجی را مقایسه کنید. Order Note ممکن است زمان سایت و Access Log زمان UTC داشته باشد.

خطا: مانیتور هر چند دقیقه هشدار کاذب می‌دهد

Retry، Threshold، Location و Maintenance Window را اصلاح کنید. هشدار باید براساس چند Failure متوالی و از بیش از یک نقطه صادر شود.

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

Uptime خارجی و مستقل از هاست فعال است.
صفحه اصلی، محصول و Checkout بررسی می‌شوند.
محتوا و زمان پاسخ کنار Status Code کنترل می‌شوند.
SSL، DNS و دامنه هشدار دارند.
Site Health دوره‌ای بررسی می‌شود.
System Status ووکامرس مستند است.
PHP Error Log قابل دسترسی و محافظت‌شده است.
خطا در Frontend نمایش داده نمی‌شود.
Access Log، WAF و PHP Log قابل Correlate هستند.
WooCommerce Logs و Retention تنظیم‌اند.
Secret داخل Log ثبت نمی‌شود.
Activity Log تغییرهای حساس را ثبت می‌کند.
WP-Cron تست شده است.
Action Scheduler Failed و Pending مانیتور می‌شود.
Failed Payment، Email و Download هشدار دارند.
Disk، Inode، CPU و Memory کنترل می‌شوند.
Runbook هر Alert نوشته شده است.
Alert Fatigue با Severity و Retry کنترل می‌شود.
Backup و Restore آزمایشی در برنامه نگهداری قرار دارند.

📌 همچنین بخوانید: ارتقای نسخه PHP وردپرس، نگهداری دوره‌ای وردپرس و انتقال وردپرس به هاست جدید

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

بهترین افزونه مانیتورینگ وردپرس چیست؟

یک افزونه به‌تنهایی همه نیازها را پوشش نمی‌دهد. Uptime باید خارج از سرور باشد؛ Activity Log، Error Monitoring و Metric سرور نیز ابزارهای جدا می‌خواهند.

آیا Site Health برای امنیت سایت کافی است؟

خیر. Site Health مشکلات شناخته‌شده پیکربندی را نشان می‌دهد، اما جای WAF، 2FA، اسکن فایل، Log و تست Checkout را نمی‌گیرد.

WP_DEBUG را روی سایت زنده روشن کنیم؟

فقط برای عیب‌یابی کنترل‌شده، با WP_DEBUG_DISPLAY=false و Log محافظت‌شده. برای مانیتورینگ دائمی از Error Log سرور یا سرویس تخصصی استفاده کنید.

چرا Sent در Log ایمیل به معنی دریافت نیست؟

Sent فقط تحویل به Mailer را نشان می‌دهد. SMTP، سرور مقصد و Spam Filter هنوز می‌توانند پیام را رد کنند.

آیا می‌توان همه Actionهای Failed را دوباره اجرا کرد؟

خیر. ابتدا Hook، خطا و Idempotency را بررسی کنید؛ تکرار بعضی Jobها عملیات دوباره ایجاد می‌کند.

هر چند وقت Uptime را بررسی کنیم؟

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

آمار بازدید همان مانیتورینگ است؟

خیر. آمارگیر رفتار بازدید را نشان می‌دهد؛ قطعی، PHP Error، Cron و Failed Payment به مانیتورهای عملیاتی نیاز دارند.

جمع‌بندی

مانیتورینگ وردپرس باید از بیرون سایت شروع شود و تا داخل PHP، WooCommerce، Cron، درگاه، ایمیل و شاخص‌های کسب‌وکار ادامه پیدا کند. HTTP 200 صفحه اصلی تنها یک سیگنال است و سلامت واقعی فروشگاه را تضمین نمی‌کند.

Uptime خارجی قطعی را کشف می‌کند، Site Health و System Status وضعیت پیکربندی را نشان می‌دهند، PHP و Access Log علت فنی را مشخص می‌کنند و Activity Log پاسخ می‌دهد چه کسی چه تغییری داده است. WooCommerce Logs و Action Scheduler نیز مسیر سفارش، پرداخت، ایمیل و Jobهای پس‌زمینه را قابل پیگیری می‌کنند.

برای سایت فعلی، اولویت عملی راه‌اندازی Uptime خارجی، دسترسی مستند به Error Log هاست، کنترل Action Scheduler، ثبت Activityهای حساس و افزودن Logger استاندارد به افزونه‌های سفارشی است. هر هشدار باید Severity، مالک و Runbook مشخص داشته باشد.

منابع رسمی

آموزش‌های تازه، کد آماده و رفع خطاهر هفته در کانال Dev Source؛ رایگان.

✈️ کانال تلگرام 🟣 کانال روبیکا