למה ניטור שרת Bitrix הוא קו ההגנה הראשון
אתר יכול להיות כתוב באופן מושלם, אבל אם השרת אינו זמין, הלקוח רואה ERR_CONNECTION_REFUSED. ביותר מ-10 שנות עבודה עם Bitrix, נתקלנו עשרות פעמים במצב שבו VPS נפל בגלל דליפת זיכרון ב-MySQL או הצפת דיסק ב-/upload/.
ניטור זמינות השרת הוא שכבה מתחת לניטור האתר. כאן לא נבדקת תגובת ה-HTTP של האפליקציה, אלא פעולת המכונה עצמה: רשת, דיסק, זיכרון, תהליכים.
זה רלוונטי במיוחד ל-Bitrix: הפלטפורמה עתירת משאבים, ו-VPS טיפוסי באחסון משותף פועל בגבול היכולת שלו. בפרויקט אחד, דליפת זיכרון ב-MySQL צרכה 12 GB מתוך 16 GB RAM, ה-swap גדל ל-2 GB, וה-TTFB זינק ל-7 שניות. מערכת הניטור הופעלה תוך 2 דקות — ההשבתה נמנעה.
אילו מדדים יש לנטר תחילה?
ניטור שרת אינו בדיקה אחת אלא מספר רבדים, שכל אחד מהם תופס סוג אחר של בעיות. Ping (ICMP). הבדיקה הבסיסית ביותר: אם השרת מגיב ל-ping, המכונה פועלת והרשת עובדת. אם הוא אינו מגיב, ייתכן שהשרת מושבת, הרשת אינה זמינה, או שחומת אש חוסמת ICMP (ובמקרה כזה ping חסר תועלת). מרווח — 30-60 שניות.
פורטים. אנו בודקים חיבור TCP בפורטים מרכזיים:
| פורט | שירות | מה משמעות חוסר הזמינות |
|---|---|---|
| 80 | HTTP | שרת האינטרנט אינו פועל |
| 443 | HTTPS | שרת האינטרנט או SSL אינו עובד |
| 3306 | MySQL | מסד הנתונים אינו זמין |
| 5432 | PostgreSQL | מסד הנתונים אינו זמין |
| 22 | SSH | אין גישה מרחוק |
הפורט מגיב, אך השירות שבתוכו תקוע — לחיצת היד של TCP עוברת, אך אין נתונים. עבור HTTP, זה נתפס באמצעות ניטור HTTP (TTFB > סף). עבור MySQL, באמצעות בדיקות ייעודיות, למשל SELECT 1.
מדדי מערכת. CPU, RAM, דיסק, swap, load average. נאספים על ידי סוכן על השרת (Zabbix agent, Telegraf, node_exporter עבור Prometheus). ספים קריטיים עבור שרת Bitrix טיפוסי:
| מדד | אזהרה | קריטי |
|---|---|---|
| שימוש ב-CPU | > 80% (5 דקות) | > 95% (5 דקות) |
| שימוש ב-RAM | > 85% | > 95% |
| שימוש בדיסק | > 80% | > 90% |
| שימוש ב-swap | > 50% | כל שימוש ב-swap |
| Load average | > מספר הליבות | > פי 2 מהליבות |
Swap על שרת Bitrix הוא אות מדאיג. MySQL ו-PHP-FPM ב-swap פועלים לאט בסדר גודל. אם ה-swap גדל, ה-RAM אינו מספיק; יש לבצע אופטימיזציה או להוסיף עוד.
למה ניטור swap קריטי עבור Bitrix?
MySQL ו-PHP-FPM כאשר אין מספיק RAM נכנסים ל-swap, מה שגורם לירידה בביצועים פי 10-30. עבור קטלוג טיפוסי עם 50 אלף מוצרים, זה אומר TTFB > 5 שניות. התראה על כל שימוש ב-swap מאפשרת לזהות את הבעיה לפני שהמשתמשים מתחילים להתלונן. בפרקטיקה שלנו, זה מנע השבתה שעלותה לשעה מחושבת לאחר ביקורת.
כיצד להגדיר התראות עבור Bitrix?
עבור ניטור שרת, מהירות התגובה קריטית יותר מאשר עבור ניטור אפליקציה. אם השרת אינו זמין, כל האתרים עליו מושבתים. שרשרת ההתראות: Telegram (באופן מיידי) → SMS (לאחר 5 דקות ללא אישור) → שיחה (לאחר 15 דקות).
עבור צוותים — אינטגרציה עם PagerDuty או OpsGenie עם לוחות זמנים של תורנויות. זה מפחית את זמן זיהוי התקלה הממוצע מ-30 דקות לדקה אחת.
תהליכים: מה אמור לפעול. עבור תצורת Bitrix טיפוסית (Apache/Nginx + PHP-FPM + MySQL), אנו מנטרים את נוכחות התהליכים:
- nginx —
systemctl is-active nginx. אם הוא מושבת — 502 Bad Gateway. - php-fpm —
systemctl is-active php8.1-fpm. אם הוא מושבת — 502 או 500. - mysqld —
systemctl is-active mysql. אם הוא מושבת — מסך לבן או שגיאת חיבור למסד הנתונים. - cron —
systemctl is-active cron. אם הוא מושבת — סוכני Bitrix אינם פועלים (בעת שימוש ב-cron_events).
בנוסף עבור תצורת production:
- memcached או redis — אם משתמשים בהם כ-backend של מטמון (
cache_typeב-.settings.php). כשל של שרת מטמון אינו מפיל את האתר אך מגדיל בחדות את העומס על MySQL. - sphinx או elasticsearch — אם משתמשים באינדקס חיפוש חיצוני.
כיצד לבחור כלי ניטור לפרויקט שלך?
Zabbix — מערכת ניטור מלאה. סוכן Zabbix מותקן על השרת, אוסף מדדים ושולח אותם לשרת Zabbix. תבניות מוכנות מראש ל-Linux, MySQL, Nginx, PHP-FPM.
הגדרת טריגר: {host:system.cpu.util.avg(5m)} > 80 — התראה כאשר CPU > 80% למשך 5 דקות. עבור שרת בודד, Zabbix מוגדר פי שניים מהר יותר מ-Prometheus.
Prometheus + Grafana — סטאק חלופי. Node_exporter אוסף מדדים, Prometheus מאחסן אותם, Grafana מציגה אותם ויזואלית. Alertmanager שולח התראות. גמיש יותר מ-Zabbix בויזואליזציה אך דורש יותר זמן הגדרה. עבור תשתית מקובצת — בהחלט Prometheus.
Netdata — סוכן עם ממשק ווב, מותקן תוך דקה. מציג מדדים בזמן אמת עם פירוט ברזולוציית שנייה. ללא אחסון היסטוריה מובנה (נדרשת אינטגרציה עם Prometheus/Graphite). מתאים לאבחון מהיר.
לוח בקרה (ISPmanager, VestaCP). אם השרת מנוהל דרך לוח בקרה, בדרך כלל יש בו ניטור בסיסי: גרפים של CPU, RAM, דיסק. ככלל, אין התראות.
מאפיינים של שרתי Bitrix
סביבת BitrixVM. אם השרת נפרס מדימוי BitrixVM, יש לו סט מותקן מראש של סקריפטים לניטור: /etc/cron.d/bx_*, בדיקת סטטוס דרך /opt/webdir/bin/bx-monitor.
סקריפטים אלה בודקים את MySQL, Nginx, PHP-FPM ושולחים את התוצאה לפאנל BitrixVM (https://server:8443). ניטור בסיסי, אך ללא התראות חיצוניות. כפי שצוין בתיעוד BitrixVM, ניטור ברמת מערכת ההפעלה הוא קו ההגנה הראשון.
MySQL. עבור Bitrix, הפרמטרים הבאים קריטיים: Threads_connected (חיבורים נוכחיים), Slow_queries (שאילתות איטיות), Innodb_buffer_pool_reads (החמצות מטמון InnoDB). אנו מנטרים באמצעות תבנית Zabbix MySQL או באמצעות mysqladmin extended-status.
גודל /upload/. תיקיית /upload/ באתרי Bitrix גדלה ללא שליטה: תמונות קטלוג, קבצי החלפה עם 1C, קבצים זמניים.
אנו מנטרים du -sh /home/bitrix/www/upload/ — אם היא מתקרבת למגבלת הדיסק, יש צורך בניקוי באמצעות הכלי המובנה של Bitrix "הגדרות → ניקוי קבצים" או בדיקה ידנית.
גיבויים. ניטור לא רק של השרת אלא גם של הגיבויים שלו. אנו בודקים את תאריך הגיבוי האחרון (קובץ בתיקיית /backup/ או רשומת לוג). אם הגיבוי ישן מ-24 שעות — אזהרה. אובדן נתונים ללא גיבוי טרי הוא קטסטרופה שניטור חייב למנוע.
מה כלול בהגדרת ניטור במסלול מלא
אנו מספקים מחזור עבודה מלא:
- ביקורת של תצורת השרת הנוכחית וזיהוי צווארי בקבוק.
- פיתוח תוכנית ניטור: מדדים, טריגרים, ערוצי התראות.
- התקנה והגדרה של סוכנים (Zabbix/Prometheus) ואינטגרציה עם Telegram/PagerDuty.
- יצירת לוחות מחוונים ב-Grafana (אופציונלי).
- תיעוד עם הוראות לצוות שלך.
- הדרכת עובדים לעבודה עם המערכת.
- אחריות על ביצועים למשך 30 יום לאחר ההטמעה.
אנו מנהלים מערכות Bitrix כבר יותר מ-10 שנים והשלמנו למעלה מ-50 פרויקטים. המהנדסים שלנו מוסמכים ובעלי ניסיון עם מערכות בעומס גבוה. צרו קשר לקבלת הערכה של הפרויקט שלכם — אנו מבטיחים שהתשתית שלכם תהיה תחת שליטה 24/7. קבלו ייעוץ; אנו נחשב את העלות ואת לוח הזמנים באופן אישי.
איך ההתקנה מתבצעת ב-5 שלבים
- ביקורת של התצורה הנוכחית — אנו בודקים את התשתית: גרסאות תוכנה, עומס, צווארי בקבוק. אנו מתעדים את הספים הנוכחיים.
- פיתוח של תוכנית ניטור — אנו מגדירים מדדים, טריגרים וערוצי התראות עבור הארכיטקטורה שלך.
- התקנה ותצורה של סוכנים — Zabbix agent / Prometheus node_exporter, תצורת איסוף מדדים.
- יצירה של לוחות מחוונים והתראות — ב-Grafana (אופציונלי) או Zabbix, אינטגרציה עם Telegram/SMS/PagerDuty.
- בדיקות ותיעוד — אנו בודקים שההתראות מופעלות, וכותבים הוראות עבור הצוות שלך.
הזמן התקנה של ניטור שרת 1C-Bitrix — נהפוך את הכאוס של המדדים לתמונה ברורה.