עם ניסיון של למעלה מ-10 שנים ויותר מ-200 התקנות ניטור מוצלחות עבור 1C-Bitrix, אנו מבטיחים פתרון חזק. שמת לב שהאתר שלך יכול להיות לא זמין במשך שעות, ואתה מגלה על כך רק כשהלקוח מתקשר? בפרויקט אחד ראינו שהקטלוג עבד, אבל עגלת הקניות נכשלה כל 10 דקות — הניטור המובנה לא תפס את זה. שגיאת 500 בדף התשלום נתלתה במשך יום עד שבדקו את הלוגים ידנית. זמן השבתה ממוצע ללא ניטור הוא 4 שעות, מה שמוביל לאובדן של עד 35% מההזמנות ועד 2,000$ לחודש בהכנסות. עם תעריף שעתי של מנהל מערכת בסביבות 50$, ההפסדים החודשיים יכולים לעלות על כמה אלפי דולרים. ללא ניטור חיצוני, אתה מסתכן באובדן של עד 30% מההמרות אם זמן ההשבתה עולה על 5 דקות. התראות הקריסה שלנו ל-Bitrix מודיעות לך באופן מיידי דרך טלגרם, ומפחיתות את זמן ההשבתה ב-95%. בואו נפרק מה לנטר ואיך להגדיר את זה על 1C-Bitrix.
מה בדיוק לנטר
מערך נקודות הבדיקה המינימלי כולל 10 דפים קריטיים — קטלוג, עגלת קניות, תשלום — שנבדקים כל 3 דקות. מדדים נוספים:
- סטטוס HTTP של הדף הראשי ו-10 דפים קריטיים — קטלוג, עגלת קניות, תשלום. אם
/catalog/מחזיר 200 אבל/personal/order/make/מחזיר 500, בדיקת בריאות כללית בדף הראשי לא תגלה את זה. בדוק כל 3 דקות. - תפקוד Cron — סוכני Bitrix (
/bitrix/modules/main/tools/cron_events.php) חייבים לרוץ באופן קבוע. בדוק לפי תאריך ההפעלה המוצלחת האחרונה בטבלתb_agent. אם חסרות 2+ ריצות — התראה. - זמינות MySQL/MariaDB — בדוק לא רק את החיבור אלא בצע SELECT לבדיקה. מספר החיבורים המקסימלי הוא בדרך כלל 500, חריגה ממנו גורמת לשגיאה. Bitrix מציג מסך לבן ללא רישום בלוג כשהחיבור למסד הנתונים נופל.
- שטח דיסק פנוי — כשהמחיצה עם
/tmpאוupload/מתמלאת, האתר מתחיל לזרוק שגיאות כתיבה לסשן ולמטמון. התראה ב-<10% שטח פנוי. - גודל error.log — עלייה חדה ב-
/var/log/php-fpm/error.logאו/bitrix/modules/main/tools/log.txtמאותתת על בעיה לפני שהיא נראית למשתמשים. התראה כשחורגים מ-100 MB.
כלים מובנים של Bitrix
לפי התיעוד הרשמי (https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=2180), מודול monitoring (אם קיים) מוגדר תחת הגדרות → ניטור. הוא יכול לבדוק זמינות אתר דרך HTTP, לעקוב אחרי סוכנים ולשלוח הודעות דוא"ל. מגבלות: עובד רק כשהאתר חי, לא בודק תלות חיצונית, ולא משתלב עם מסרונים ללא התאמה אישית.
שימושי יותר הוא יומן האירועים (b_event_log). דרך ה-API של CEventLog::Add() ניתן לתעד אירועים מותאמים אישית, ודרך מסנני הניהול ניתן להגדיר התראות לרמות חומרה ספציפיות.
למה ניטור חיצוני אמין יותר מהמובנה?
הניטור המובנה של Bitrix בודק את האתר מבפנים — אם PHP או מסד הנתונים נופלים, הוא לא יופעל. שירות חיצוני בודק את האתר מבחוץ ורואה בעיות שאינן נראות על השרת. לדוגמה, במהלך מתקפת DDoS (https://en.wikipedia.org/wiki/Denial-of-service_attack) או חסימת ראוטר, הניטור המובנה עשוי להראות 200 בעוד משתמשים אמיתיים רואים timeout.
| כלי | מה הוא בודק | ערוצי התראה |
|---|---|---|
| UptimeRobot (חינמי) | סטטוס HTTP, בדיקת מילות מפתח | דוא"ל, טלגרם, Slack, webhook |
| Healthchecks.io | משימות Cron (מנגנון איש מת) | דוא"ל, טלגרם, PagerDuty |
| Zabbix / Prometheus + Alertmanager | הכל: HTTP, דיסק, CPU, לוגים | כל דרך אינטגרציות |
לפרויקטים קטנים, אנו משלבים ניטור Bitrix עם UptimeRobot עם בדיקות כל 5 דקות + Healthchecks.io ל-cron. לבינוניים וגדולים — Prometheus עם blackbox_exporter לבדיקות HTTP ו-node_exporter למדדי שרת. Prometheus מתקפל פי 10 מהר יותר מ-Zabbix על מאות מארחים.
| ערוץ | מהירות מסירה | אמינות | מורכבות אינטגרציה |
|---|---|---|---|
| טלגרם | 1-2 שניות | גבוהה | בינונית |
| דוא"ל | 1-5 דקות | בינונית | נמוכה |
| Slack | 2-5 שניות | גבוהה | בינונית |
| PagerDuty | מיידי | גבוהה מאוד | גבוהה |
איך ליישם נקודת בדיקת בריאות?
צור קובץ /healthcheck.php בשורש האתר שבודק את מערכות המפתח:
- חיבור למסד נתונים דרך
$DB->Query("SELECT 1") - זמינות Memcached/Redis דרך
CBitrixCache - גישת כתיבה לתיקיית הקבצים הזמניים (בודק שהדיסק לא מלא)
- נוכחות מפתח רישיון (בדוק
CModule::IncludeModule('main'))
אם כל הבדיקות עוברות — החזר HTTP 200 עם גוף OK. כל כשל — HTTP 503 עם תיאור השגיאה. ניטור חיצוני קורא לנקודת קצה זו פעם בדקה ומגיב לסטטוס שאינו 200. זמן הביצוע לא יעלה על 200 אלפיות השנייה, אחרת הניטור עלול לחשוב שנקודת הקצה לא זמינה.
דוגמת קוד לבדיקת בריאות
<?php require($_SERVER['DOCUMENT_ROOT'].'/bitrix/modules/main/include/prolog_before.php'); $status = 200; $errors = []; if (!$DB->Query("SELECT 1")) { $errors[] = 'DB'; $status = 503; } if (!is_writable($_SERVER['DOCUMENT_ROOT'].'/upload/')) { $errors[] = 'Disk'; $status = 503; } http_response_code($status); echo $status == 200 ? 'OK' : implode(',', $errors); איך לשלב התראות טלגרם?
עבור Bitrix24 יש אינטגרציה מובנית עם webhooks. עבור אתרים על 1C-Bitrix, הדרך הקלה ביותר היא לשלוח התראות דרך Telegram Bot API ישירות ממטפל השגיאות. ב-<?php require($_SERVER['DOCUMENT_ROOT'].'/bitrix/modules/main/include/prolog_before.php'); $status = 200; $errors = []; if (!$DB->Query("SELECT 1")) { $errors[] = 'DB'; $status = 503; } if (!is_writable($_SERVER['DOCUMENT_ROOT'].'/upload/')) { $errors[] = 'Disk'; $status = 503; } http_response_code($status); echo $status == 200 ? 'OK' : implode(',', $errors); , רשום מטפל מותאם אישית דרך init.php ששולח בקשת POST ל-set_exception_handler() על שגיאות קריטיות. אל תשלח כל שגיאה — השתמש במגבלת קצב: לא יותר מהודעה אחת לכל 5 דקות עבור כל סוג שגיאה. אחרת, במהלך כשל המוני, טלגרם תחסום את הבוט בגלל ספאם.
טעויות אופייניות בהגדרת ניטור
- 50% מההגדרות בודקות רק את הדף הראשי — דפים אחרים עלולים להיות לא זמינים, כמו במקרה של עגלת הקניות.
- ל-40% מהפרויקטים אין cron מוגדר — סוכנים לא רצים, מטמון האתר מתמלא לאט.
- ניטור מבפנים — לא יעבוד כשהאתר נופל.
- התראות תכופות מדי (כל דקה) — אחרי שעה מתחילים להתעלם מהן. מרווח של 3-5 דקות הוא אופטימלי.
- זמן השבתה בשעות שיא יכול לעלות עשרות כ-$9–13 בחיסכון — אל תחסכו בניטור.
מה כלול בעבודה
- ביקורת של התשתית הקיימת וזיהוי צווארי בקבוק עם ניתוח לוגים.
- פיתוח נקודת קצה לבדיקת בריאות עם מערך בדיקות אישי (עד 20 מדדים).
- הגדרת ניטור חיצוני (UptimeRobot, Prometheus, או מקביל) עם תדירות בדיקה של 1-5 דקות.
- אינטגרציה של התראות לטלגרם, דוא"ל, Slack עם מגבלת קצב.
- תיעוד תפעולי והדרכה לצוות שלך (שעתיים).
- תמיכה לחודש אחד לאחר ההשקה עם התאמות סף.
עם ניסיון של 10+ שנים ב-Bitrix ומומחים מוסמכים, אנו מבטיחים SLA מלא. המחיר מחושב באופן אישי לאחר ניתוח המפרט הטכני. חיסכון בתקציב יכול להגיע לעשרות כ-$9–13 בחיסכון לחודש באמצעות אוטומציה. קבל ייעוץ לפרויקט שלך — נבחר את הפתרון האופטימלי. צור קשר לביקורת ניטור וקבל דוח עם המלצות.