יום שישי, 18:00. אתר ביטריקס נפל. מנהלים לא רואים הזמנות. לקוחות מתלוננים. DevOps מגלה על הבעיה ביום שני ממייל. מצב טיפוסי: מסד הנתונים קרס עקב שאילתות איטיות, סוכנים לא עיבדו אירועי דואר, והדיסק מלא בקאש. מודול Performance Monitor (perfmon) המובנה מציג מדדים רק בלוח הניהול. הוא לא שולח התראות לטלגרם. הוא לא בונה דשבורדים לתקופות שרירותיות. הוא לא משתלב עם צוות תורן. הפתרון הוא מערכות חיצוניות: Zabbix או Prometheus עם Grafana. אנחנו מגדירים ניטור כזה ל-1C-Bitrix כבר יותר מ-10 שנים. השלמנו מעל 50 פרויקטים. ניטור נכון מחזיר את עצמו תוך ימים ספורים.
מה אנחנו מנטרים
המדדים מחולקים לשלוש רמות: תשתית, יישום ועסקי. תשתית (שרת):
- CPU, 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% |
| זמן תגובה | <1 שנייה | >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%.