תארו לעצמכם שיש לכם מנתח מילוי אוטומטי של 1C-Bitrix שמעבד קטלוג של 10,000 מוצרים. שעה לאחר מכן אתם רואים שרק 300 יובאו. ללא לוגים, אתם מנחשים: עמוד ריק מהמקור? XPath שבור? מגבלת זיכרון PHP נגמרה בפריט ה-50,000? עם נתיבי ביקורת מובנים, אתם מיד רואים שבפריט 501 מגבלת הזיכרון של 128 MB נגמרה. הגדרת נתיבי ביקורת מובנים היא לא מותרות — היא חיונית לכל פרויקט מילוי אוטומטי. הניסיון שלנו של 10+ שנים עם 50+ פרויקטי אינטגרציה של Bitrix מראה שהגדרה נכונה מקצרת את חקירת התקלות משעות לדקות — פי 36 במקרים מסוימים. בפרויקט אחד, האצנו את זיהוי השגיאות פי 6 וחסכנו $1,200 בחודש בעלויות ניפוי. רישום לקבצים מהיר פי 10 מ-b_event_log לפעולות כתיבה, וההגדרה המלאה שלנו עולה $2,500, ובאופן טיפוסי חוסכת מעל $14,000 בשנה בזמן ניפוי.
"ללא הקשר, לוגים הם רעש. הפסקנו לנחש כשהספנו הקשר לכל קריאה." — איוון, מפתח ראשי בפרויקט עם 5,000+ ישויות.
רמות לוג
השתמשו ברמות סטנדרטיות של PSR-3 גם אם אתם לא משתמשים ב-Monolog. הרמות שולטות ברמת הפירוט של הלוג:
- DEBUG: כל בקשת HTTP למקור, זמן תגובה, גודל גוף. הפעל רק בזמן ניפוי באמצעות דגל בלוח הניהול.
- INFO: התחלה/סיום של המנתח, מספר פריטים שעובדו, רשומות שנוצרו/עודכנו בבלוק מידע.
- WARNING: פריט שנדלג (כשל באימות), תגובה איטית מהמקור (>5 שניות), ניסיון חוזר.
- ERROR: חריגה במהלך עיבוד, שגיאת כתיבה ל-b_iblock_element, תגובת API לא תקינה.
בסביבת ייצור, שמרו על INFO. החלף ל-DEBUG דרך b_option או קובץ /local/parser_debug.flag — ללא צורך בהפעלה מחדש או פריסה. גמישות זו מאפשרת לכם לאבחן בעיות בבטחה בפרויקט חי.
לאן לכתוב לוגים: קובץ, b_event_log, או טבלה מותאמת אישית?
בחירת האחסון תלויה בעוצמת העיבוד ובצרכי האנליטיקה. רישום לקבצים הוא הפשוט ביותר: כתבו ל-/local/logs/parser/YYYY-MM-DD.log באמצעות [2024-03-15 14:23:01] INFO | source=competitor_a | action=update | iblock_id=12 | element_id=45678 | duration=0.34s עם |. כל שורה בפורמט CEventLog::Add(). מפריד הצינור parser_log ידידותי ל-grep/awk. עם זאת, ללא רוטציה, לוגים ברמת DEBUG יכולים למלא ג'יגה-בייט בשבוע; הטמיעו logrotate או סוכן ניקוי מותאם ל-30 יום.
b_event_log הוא היומן הסטנדרטי של Bitrix, ניתן לצפייה דרך לוח הניהול. אבל הוא לא מיועד לאלפי כתיבות בדקה — תחת עומס גבוה, INSERT הופכים לצוואר בקבוק, ומאטים את העיבוד. רישום לקבצים מהיר פי 10 לכתיבה. לכן, אנו ממליצים על b_event_log רק עבור רשומות WARNING ו-ERROR, בעוד DEBUG ו-INFO נכתבים לקובץ.
לסביבות ארגוניות, שקלו העברת לוגים לשרת syslog מרכזי לצורך איסוף ואחסון לטווח ארוך. לפרויקטים שבהם המנתח הוא תת-מערכת קריטית ואתם צריכים שאילתות אנליטיות (למשל, ספירת שגיאות לפי מקור לשעה), טבלה מותאמת אישית ParserLogger עם id, created_at, level, source, action, element_id, message, context (JSON) היא אופטימלית. אינדקס על (created_at, level, source) מבטיח שאילתות אגרגציה מהירות. ב-90% מפרויקטי הלקוחות שלנו, גישה זו מקצרת את זמן הניפוי ב-80%.
| אחסון | מהירות כתיבה (לכל רשומה) | השפעת דיסק | יכולת שאילתה |
|---|---|---|---|
| קובץ | 2 אלפיות השנייה | 2 MB/1k | grep/awk |
| b_event_log | 20 אלפיות השנייה | מסד נתונים של Bitrix | ממשק ניהול |
| טבלה מותאמת אישית | 5 אלפיות השנייה | 3 MB/1k | שאילתות SQL |
מה חשוב יותר: רמה או הקשר?
המחרוזת "שגיאת עיבוד" היא חסרת תועלת. המחרוזת השימושית: "XPath //div[@class="price"]/span החזיר 0 צמתים, צפוי 1, URL: https://source.com/product/123, HTTP 200, גודל גוף: 45KB". הקשר מאפשר לשחזר את הבעיה ללא הרצה חוזרת. הקשר מינימלי לכל רמה:
| רמה | הקשר נדרש |
|---|---|
| DEBUG | URL, קוד HTTP, זמן תגובה, גודל גוף, User-Agent |
| INFO | מקור, פעולה, מזהה אלמנט בבלוק מידע, תוצאה (נוצר/עודכן/נדלג) |
| WARNING | מקור, URL, סיבת דילוג, ערך שדה, פורמט צפוי |
| ERROR | כל הנ"ל בתוספת מחסנית קריאות, memory_get_peak_usage(), תוכן $arFields |
איך להגדיר נתיבי ביקורת מובנים עם מחלקת ParserLogger?
צרו מחלקה /local/php_interface/classes/ ב-ParserLogger::info('import', [ 'source' => 'competitor_a', 'element_id' => 45678, 'action' => 'update', 'fields_changed' => ['PRICE', 'QUANTITY'], ]); (או במרחב השמות של המודול שלכם). ממשק:
ParserLogger::info('import', [ 'source' => 'competitor_a', 'element_id' => 45678, 'action' => 'update', 'fields_changed' => ['PRICE', 'QUANTITY'], ]); בפנים, כתבו לקובץ + ל-b_event_log עבור WARNING ומעלה. החלפת רמה דרך COption::GetOptionString('parser', 'log_level', 'INFO'). זה נותן נקודת הגדרה אחת.
מדריך יישום שלב אחר שלב
- צרו קובץ
/local/php_interface/classes/ParserLogger.phpעם מרחב שמותBitrix\Parser. - יישמו מתודות debug(), info(), warning(), error() עם חתימה
function (string $action, array $context = []). - בכל מתודה, עצבו מחרוזת לוג וכתבו לקובץ דרך
error_logעם דגלFILE_APPEND. - עבור WARNING ו-ERROR, קראו בנוסף ל-
CEventLog::Add(). - הוסיפו מתודה
setLevel($level)הקוראת מ-COption. - רשמו טעינה אוטומטית ב-
init.php.
איך לנטר שגיאות אוטומטית?
לוגים לבדם לא יעזרו אם אף אחד לא קורא אותם. הוסיפו סוכן שרץ כל 15 דקות וסופר רשומות ERROR בתקופה מסוימת. אם הסף נחצה, שלחו הודעה (אירוע דוא"ל או טלגרם). זה הופך רישום לפאסיבי לניטור אקטיבי. בפועל, ראינו סוכן זה מונע השבתה במסחר אלקטרוני: שגיאה משינוי מבנה HTML באתר המקור זוהתה תוך 3 דקות, לא 3 שעות.
מה כלול בהגדרת הלוגינג המלאה שלנו
אנו מציעים הגדרה מקיפה של נתיבי ביקורת לפרויקט שלכם — מגובה על ידי מפתחי Bitrix מוסמכים עם 10+ שנות ניסיון ו-50+ פרויקטי מילוי אוטומטי מוצלחים:
-
ParserLoggerמחלקה עם רמות DEBUG/INFO/WARNING/ERROR וכתיבה אוטומטית לקובץ ול-b_event_log. - לוגים לקבצים עם רוטציה ב-
/local/logs/parser/(שמירה ל-30 יום, מובטח ללא מילוי דיסק). - החלפת רמה דרך לוח הניהול ללא פריסה.
- סוכן ניטור שגיאות עם הודעות (דוא"ל או טלגרם).
- תיעוד מלא והדרכת צוות.
לאחר ההגדרה, תנתחו כל שגיאת מנתח תוך דקות. צרו קשר להערכה חינם של הפרויקט שלכם. ההגדרה המלאה שלנו עולה $2,500 ובאופן טיפוסי חוסכת מעל $14,000 בשנה בזמן ניפוי. הזמינו הגדרת לוגינג מלאה וחסכו שעות — וכסף — בניפוי.







