בריאות ותפקוד

ניתוח הבריאות והביצועים של האתר רץ היום מחוץ לליבה, אצל אולג AI המאוחסן (https://oleg.wizzo.market). בליבה נשאר מה שרק השרת של האתר יכול לעשות: לאסוף נתונים, למדוד תעבורה אמיתית, ולהריץ פעולה מוגנת אחת (בניית אינדקס). בדף הזה: מה נאסף ובאילו ספים, איך המנוע החיצוני קורא את זה, ומה הכלים החיים שנשארו בפאנל (server_load, error_log, sqllog).

SystemHealth: האוסף#

libraries/SystemHealth.php הוא collector בלבד: הוא לא שומר, לא מנתח ולא מציג. שתי מתודות ציבוריות עיקריות, ועוד עוזר אחד.

$findings = SystemHealth::collect();

foreach ($findings as $f)
{
    if ($f["severity"] === "high")
    {
        error_log($f["source"] . ": " . $f["title"]);
    }
}

מקורות הנתונים והספים#

הספים הם קבועים בראש הקובץ (DISK_WARN_PCT, ERRLOG_WARN_BYTES ועוד), בכוונה שמרניים: התראה שחוזרת כל שעה ואף אחד לא פועל לפיה מלמדת מנהלים להתעלם מכל הדוח.

perf_runner: הדלת של אולג אל האתר#

system/perf_runner הוא controller של הליבה (נתיב system/ מנותב ישירות, בלי שורה ב-CRM_modules), מליבה 5.0.83 ומעלה. המנוע החיצוני קורא לו, והוא מעביר ל-OlegAgent (libraries/OlegAgent.php) את העבודה. הוא זהה בדפוסו ל-seo_runner (ראו חבילת ה-SEO).

אימות וגוף הבקשה#

• פעולות המנוע דורשות Authorization: Bearer <api_key>:<secret_key> של שירות אולג, שנבדק ב-OlegHosted::request_ok() עם hash_equals. כשה-header נופל בדרך (אירוח cgi-fcgi), WIZZO_KEY::incoming() קורא גם את הערוצים החלופיים.
• הגוף הוא JSON רגיל, או מעטפת gzip: {"z":"<base64 של gzip של ה-JSON>"}. המעטפת קיימת כי שתי פעולות נושאות SQL בגוף (deep_dive ו-apply_index) ו-WAF עלול לחסום אותן עוד לפני ש-PHP רואה אותן. כשהמעטפת בשימוש, התשובה כוללת "z": 1.
• כל פעולה מתקבלת גם כ-?do=<action>, למקרה שהשרת מנתב system/<controller>/<action> ל-index() ומאבד את הסגמנט האחרון.
• כל תשובה היא {"ok":true,...} או {"ok":false,"error":"..."}. לא מאומת: 401 unauthorized. פעולות האתר: 403 admin or engine only.

הפעולות#

apply_index: האינדקס היחיד שהמנוע בונה#

OlegAgent::apply_index($sql, $run = false) מקבל רק פקודת CREATE INDEX או ALTER TABLE ... ADD INDEX פשוטה; כל דבר אחר נדחה עם הודעה להריץ ידנית. זה תהליך בשני שלבים:

1. run ריק: בדיקה בלבד. מוחזרים גודל הטבלה, מנוע האחסון, וסימון אם הבנייה אונליין (mode: "info").
2. run מלא: ב-InnoDB נבנה ALGORITHM=INPLACE, LOCK=NONE. בטבלת MyISAM או Aria אין בנייה אונליין, ולכן היא מותרת רק לטבלה קטנה (עד 300,000 שורות ו-256MB). טבלה גדולה כזו נדחית עם פקודה להרצה ידנית בשעת שפל.

אם האינדקס כבר קיים, התשובה היא ok עם already: 1.

צורת התשובות שנשארו בליבה#

בנוסף ל-perf_runner, שני controllers ישנים נשארו כ"מעטפת" ריקה בכוונה, כדי ששורות cron ישנות באתרים לא יתמלאו באדום:

ראו Cron לניהול המשימות.

הכלים החיים בפאנל#

שלושה כלי ניטור נשארו בפאנל. כולם מופיעים תחת כלים למפתחים ב-{admin}.

server_load: עומסי השרת#

ADMINMODULE_server_load הוא דשבורד של משאבי השרת בזמן אמת, ומתרענן כל 2 שניות. {admin}/server_load/stats מחזיר JSON עם:

כל מדד נקרא בזהירות: במקום שאין /proc (Windows, אירוח מוגבל) הכרטיס מציג "לא זמין" ואינו שובר את העמוד.

sqllog ולוג SQL#

כש-PARAMS log_sql הוא "1", DB::log_sql_to_file() כותבת כל שאילתה (עם url, date, source שהוא admin או site, ו-backtrace) כשורת JSON לקובץ sqllog.txt בשורש האתר. הקובץ מצמצם את עצמו: מעל 5MB נשמר רק השליש האחרון. הפאנל {admin}/sqllog מציג את הלוג בעמודים של 100 שורות, עם סינון filter_source=admin|site, ומאפשר להפעיל, לכבות ולרוקן.

error_log#

ADMINMODULE_error_log קורא את הקובץ שמוגדר ב-ini_get('error_log') (עד 10MB האחרונים), מקבץ לפי סוג, קובץ ושורה, ומציג stack traces מקופלים. סינון ומיון נעשים בפרמטרי GET: sort_by, sort_dir, filter_type, filter_text, filter_file, filter_from_date.

ניקויים מתוזמנים#

שני controllers קטנים מנקים בלי מעורבות אדם, ומופעלים כמשימות cron בתיקיית "מערכת":

ראו גם#

• Cron, ניהול המשימות ו-heartbeat
• אבחון קוד ו-lint
• דיבוג מסד נתונים
• מערכת המטמון ו-ממשק המטמון
• סקירת Wizzo Market