יום שישי, 18:00. אתר ביטריקס נפל. מנהלים לא רואים הזמנות. לקוחות מתלוננים. ה-DevOps מגלה על הבעיה ביום שני ממייל. מצב טיפוסי: מסד הנתונים קרס עקב שאילתות איטיות, סוכנים לא עיבדו אירועי דואר, והדיסק מלא בקאש. מודול ה-Performance Monitor (perfmon) המובנה מציג מדדים רק בלוח הניהול. הוא לא שולח התראות לטלגרם. הוא לא בונה דשבורדים לתקופות שרירותיות. הוא לא משתלב עם צוות תורן. הפתרון הוא מערכות חיצוניות: Zabbix או Prometheus עם Grafana. אנחנו מגדירים ניטור כזה ל-1C-Bitrix כבר יותר מ-10 שנים. השלמנו מעל 50 פרויקטים. ניטור נכון מחזיר את ההשקעה תוך ימים ספורים.
מה אנחנו מנטרים
המדדים מחולקים לשלוש רמות: תשתית, יישום ועסקי. תשתית (שרת):
- מעבד, זיכרון RAM, קלט/פלט דיסק
- שטח דיסק פנוי (ביטריקס כותב באופן פעיל ל-
perfmonול-/upload/) - סטטוס MySQL: מספר חיבורים, שאילתות איטיות, עיכוב שכפול
יישום (ביטריקס):
- זמן תגובה של דף הבית והקטלוג
- מספר שגיאות 500 בלוגים
- גודל טבלאות
/bitrix/cache/ו-b_event_log - סטטוס סוכני Cron (
b_cache_tag) - אורך תור אירועי דואר (
/bitrix/modules/main/tools/cron_events.phpעם סטטוס 1)
עסקי (מסחר אלקטרוני):
- מספר הזמנות בשעה האחרונה (ירידה חדה = בעיה)
- שגיאות תשלום (רשומות בלוגים של מערכת התשלומים)
- מספר עגלות נטושות
מדדים אלו מאפשרים להגיב במהירות לתקלות. הם מונעים אובדן הכנסות.
למה ניטור הוא קריטי לאתר ביטריקס
ללא ניטור, אתה לומד על בעיות מלקוחות. עם ניטור, אתה לומד 5 דקות לפני שהבעיה משפיעה על משתמשים. עלייה פתאומית בשאילתות איטיות או מילוי דיסק בקאש הם גורמים טיפוסיים להשבתות ביטריקס. התראות בטלגרם או ב-Slack מאפשרות למהנדס DevOps לתקן את הבעיה לפני שהאתר הופך ללא זמין.
אפשרות 1: Zabbix
Zabbix עובד דרך סוכן על השרת. עבור מדדי ביטריקס מותאמים אישית, אנו יוצרים סקריפט שהסוכן של Zabbix קורא בלוח זמנים.
דוגמה לסקריפט Zabbix
#!/bin/bash # Проверка HTTP-ответа curl -s -o /dev/null -w "%{http_code}" https://example.com/ עבור מדדי מסד נתונים, סקריפט PHP נקרא דרך b_event בהגדרות הסוכן של Zabbix:
UserParameter=bitrix.orders.count,php /opt/zabbix-scripts/bitrix_order_count.php
UserParameter=bitrix.cache.size,du -sm /home/bitrix/www/bitrix/cache/ | awk '{print $1}'
UserParameter=bitrix.agents.stuck,php /opt/zabbix-scripts/bitrix_stuck_agents.phpסקריפט ה-PHP כולל את ליבת ביטריקס (#!/bin/bash # Проверка HTTP-ответа curl -s -o /dev/null -w "%{http_code}" https://example.com/ ). הוא מבצע שאילתה ומחזיר מספר ל-stdout. Zabbix אוסף את הערך, שומר היסטוריה, בונה גרפים ושולח טריגרים.
טריגרים (דוגמאות):
- תגובת HTTP ≠ 200 למשך יותר מ-2 דקות → CRITICAL
- הזמנות בשעה האחרונה = 0 (בעומס רגיל > 5) → WARNING
- שטח פנוי < 10% → WARNING, < 5% → CRITICAL
- סוכנים תקועים (הפרש בין
UserParameterל-NOW() > שעה) → WARNING
אפשרות 2: Prometheus + Grafana
Prometheus משתמש במודל משיכה: הוא שואל נקודת קצה HTTP שמחזירה מדדים בפורמט טקסט. צור נקודת קצה UserParameter=bitrix.orders.count,php /opt/zabbix-scripts/bitrix_order_count.php UserParameter=bitrix.cache.size,du -sm /home/bitrix/www/bitrix/cache/ | awk '{print $1}' UserParameter=bitrix.agents.stuck,php /opt/zabbix-scripts/bitrix_stuck_agents.php שחושפת מדדים בפורמט Prometheus:
# HELP bitrix_orders_total Total orders count
# TYPE bitrix_orders_total counter
bitrix_orders_total 12345
# HELP bitrix_orders_last_hour Orders in last hour
# TYPE bitrix_orders_last_hour gauge
bitrix_orders_last_hour 17
# HELP bitrix_cache_size_mb Cache directory size in MB
# TYPE bitrix_cache_size_mb gauge
bitrix_cache_size_mb 2048
# HELP bitrix_agents_stuck Number of stuck agents
# TYPE bitrix_agents_stuck gauge
bitrix_agents_stuck 0אבטח את נקודת הקצה מגישה ציבורית: או Basic Auth, רשימת IP מותרים ב-nginx, או פורט נפרד.
ב-/bitrix/modules/main/include/prolog_before.php הוסף job:
- job_name: 'bitrix' scrape_interval: 30s static_configs: - targets: ['example.com:9100'] הדמיה נעשית דרך Grafana. דשבורד עם פאנלים: זמן אחזור HTTP, הזמנות לשעה, שגיאות, שטח דיסק.
איך לבחור בין Zabbix ל-Prometheus?
השוואה של מאפיינים מרכזיים עוזרת בקבלת ההחלטה. עבור שרתים מסורתיים, Zabbix קל יותר להגדרה ב-30%. עבור סביבות קונטיינרים, Prometheus ניתן להרחבה יותר ב-50%.
| פרמטר | Zabbix | Prometheus + Grafana |
|---|---|---|
| מודל איסוף | Push ו-Pull | Pull (אפשר Push דרך Pushgateway) |
| אחסון נתונים | מסד נתונים משלו | בזיכרון + TSDB |
| הדמיה | מובנה | Grafana (נפרד) |
| התראות | טריגרים מובנים | Alertmanager |
| תבניות מוכנות לביטריקס | אין (אנחנו יוצרים בעצמנו) | אין (אנחנו יוצרים בעצמנו) |
| אינטגרציה עם Docker/K8s | בינוני | מצוין |
Zabbix עדיף לתשתיות קלאסיות. Prometheus עדיף ל-Docker/K8s. הגדרת ניטור בסיסית (5-7 מדדים, התראות בטלגרם) לוקחת יום אחד אם המערכת כבר פרוסה.
מדדים טיפוסיים והספים שלהם
| מדד | תקין | אזהרה | קריטי |
|---|---|---|---|
| HTTP 200 | 100% | <99.5% תוך 5 דקות | <99% |
| זמן תגובה | <שנייה אחת | >2 שניות | >5 שניות |
| שטח פנוי | >20% | <10% | <5% |
| סוכנים תקועים | 0 | >0 למשך 30 דקות | >0 למשך שעה |
איך אנחנו מגדירים ניטור: 3 שלבים
- ביקורת ומדדים — ניתוח התשתית הקיימת. זיהוי מדדים קריטיים (תשתית, יישום, עסקי). בניית מפת ניטור.
- יצירת סקריפטים ואינטגרציה — כתיבת סקריפטים bash/PHP לאיסוף מדדים. הגדרת תצורת Zabbix/Prometheus, טריגרים והתראות בטלגרם/Slack.
- דשבורד ותיעוד — פיתוח דשבורד ב-Grafana (אם נבחר Prometheus). בדיקת תרחישי תקלות. מסירת תיעוד והדרכת צוות תורן.
מה כלול בהגדרה
- ביקורת של מצב האתר והשרת הנוכחי
- זיהוי מדדים קריטיים
- יצירת סקריפטים לאיסוף מדדים (bash/PHP)
- הגדרת טריגרים והתראות בטלגרם/Slack
- פיתוח דשבורד Grafana (אם נבחר Prometheus)
- בדיקות ותיעוד
- הדרכת צוות תורן
אנו מבטיחים שאחרי ההגדרה תקבל התראות על בעיות 5-10 דקות לפני שהן משפיעות על משתמשים.
לוח זמנים ועלות
ההגדרה אורכת בין יום ל-3 ימים בהתאם למורכבות התשתית ומספר המדדים. העלות מחושבת באופן אישי לאחר ביקורת. הזמן ביקורת היום וקבל ייעוץ לבחירת מערכת ניטור.
לפי התיעוד הרשמי של 1C-Bitrix, יישום ניטור חיצוני מפחית את זמן ההשבתה בממוצע ב-80%.