תארו לעצמכם: בשעות השיא אתר המסחר האלקטרוני שלכם מבוסס Bitrix מתחיל להאט. מנהלים לא מצליחים לעמוד בקצב ההזמנות, הקטלוג נפתח תוך 8 שניות, והסנכרון עם 1C נתקע. שאילתה אחת ל-b_iblock_element אורכת 4 שניות — ויש אלפי כאלה בדקה. פרופילינג סטנדרטי עם Xdebug מראה את הבעיה, אבל רק כשכבר מאוחר מדי. APM פועל ברציפות, לוכד כל בקשה איטית, כל שגיאה וכל ירידה בתפוקה. אנו משלבים APM ב-1С-Битрикс שלכם כך שתראו נתוני ביצועים אמיתיים 24/7. בניגוד למדידות חד-פעמיות, APM מספק סדרות זמן: אתם יודעים שאתמול זמן התגובה p95 היה 1.2 שניות, והיום הוא 2.9 שניות — ותוכלו להגיב מיד.
אנו משתמשים בשני סטים עיקריים: Elastic APM (קוד פתוח, אירוח עצמי) ו-New Relic / Datadog (SaaS). עבור כל פרויקט אנו בוחרים את האפשרות האופטימלית לפי עומס ותקציב. התוצאה — לוחות מחוונים ב-Kibana או ב-New Relic UI, התראות ב-Slack/Telegram, שליטה מלאה בביצועים. להלן הפרטים הטכניים.
תהליך הגדרת APM
- ניתוח ארכיטקטורה ועומס. זיהוי נקודות קריטיות: דפים איטיים, שאילתות SQL כבדות, קריאות חיצוניות.
- בחירת מחסנית APM. Elastic APM או New Relic — לפי מהירות, תקציב וצרכי שליטה בנתונים.
- התקנה והגדרה של APM Server, Elasticsearch ו-Kibana (או סוכן New Relic).
- הגדרת סוכן PHP על השרת. אופטימיזציה של פרמטרים כמו
transaction_sample_rate. - יצירת לוחות מחוונים והתראות. מעקב אחר זמן תגובה p95, שיעור שגיאות, Apdex.
- בדיקה וכיול. אימות תקינות הנתונים וכיוונון עדין של התראות.
ניטור APM ב-Bitrix
סוכן ה-PHP מיירט את ביצוע הבקשות ושולח מדדים לאחסון מרכזי. זרימת Elastic APM:
PHP-агент (elastic-apm-php) → APM Server → Elasticsearch → Kibana (APM UI) התקנת סוכן ה-PHP:
# Debian/Ubuntu curl -L -O https://github.com/elastic/apm-agent-php/releases/download/v1.x.x/apm-agent-php_Linux_x86-64.deb dpkg -i apm-agent-php_Linux_x86-64.deb ב-PHP-агент (elastic-apm-php) → APM Server → Elasticsearch → Kibana (APM UI) :
extension=elastic_apm.so elastic_apm.server_url=http://apm-server:8200 elastic_apm.service_name=bitrix-site elastic_apm.environment=production elastic_apm.transaction_sample_rate=0.1 # Debian/Ubuntu curl -L -O https://github.com/elastic/apm-agent-php/releases/download/v1.x.x/apm-agent-php_Linux_x86-64.deb dpkg -i apm-agent-php_Linux_x86-64.deb — מנתח 10% מהבקשות. באתרים בעלי עומס גבוה, 100% גורם לעומס ניכר.
פרטי עומס
ב-php.ini, העומס הוא פחות מ-1% לפי המדידות שלנו בפרויקטים עם קטלוגים של עד 500,000 מוצרים. לאתרים עם פחות מ-10,000 בקשות בדקה, ניתן להגדיר 0.5 ללא השפעה משמעותית.
הסוכן לוכד אוטומטית:
- בקשות HTTP נכנסות — זמן תגובה, סטטוס, URL, מתודה.
- שאילתות SQL — ל-
extension=elastic_apm.so elastic_apm.server_url=http://apm-server:8200 elastic_apm.service_name=bitrix-site elastic_apm.environment=production elastic_apm.transaction_sample_rate=0.1,transaction_sample_rate=0.1,sample_rate=0.1ולכל הטבלאות האחרות. מציג זמן, גוף השאילתה, תוכנית ביצוע. - קריאות HTTP חיצוניות —
b_iblock_element,b_sale_order. קריאות ל-1C, שערי תשלום, API חיצוניים. - חריגות —
b_crm_deal, שגיאות שלא טופלו.
לפעולות מותאמות אישית (סקריפטי ייבוא ארוכים, צבירות כבדות), צרו spans ידנית:
use Elastic\Apm\ElasticApm; $transaction = ElasticApm::getCurrentTransaction(); $span = $transaction->beginCurrentContextSpan('import.products', 'custom'); // ... логика импорта ... $span->end(); איזה APM לבחור: Elastic או New Relic?
Elastic APM הוא חינמי, באירוח עצמי, עם שליטה מלאה בנתונים. New Relic הוא מבוסס ענן, קל יותר להתחלה, אבל בתשלום לפי GB. לפרויקטים קטנים (עד 500 בקשות/דקה), Elastic APM לרוב מספיק; לגדולים עם 1000+ בקשות/שנייה, New Relic נוח יותר עם התראות מובנות ואינטגרציות. אנו עוזרים לבחור ולהגדיר כל אחד מהם.
| פרמטר | Elastic APM | New Relic |
|---|---|---|
| רישיון | קוד פתוח (Apache 2.0) | קנייני, בתשלום |
| אירוח | אירוח עצמי (דורש שרת) | SaaS (ענן) |
| קושי הגדרה | בינוני (נדרש ניסיון ניהולי) | נמוך (התחלה מהירה) |
| שליטה בנתונים | מלאה | מוגבלת לפי מדיניות הספק |
| התראות מובנות | דרך Kibana Alerting | תבניות מוכנות + אינטגרציות |
למה curl_exec חשוב?
זהו אחוז הבקשות שעבורן נאספים מעקבים מפורטים. 0.1 (10%) הוא נקודת האיזון: עומס נמוך, מספיק נתונים כדי למצוא צווארי בקבוק. הגדרה של 1.0 מנתחת כל בקשה — העומס הופך ניכר בעומסים גבוהים. אנו מכוונים את sample_rate לפי התעבורה ומשאבי השרת שלכם. לאתר עם 100,000 ביקורים/יום, sample_rate של 0.1 מניב כ-1,000 מעקבים/דקה — מדגם מובהק סטטיסטית.
מדדים והתראות מרכזיים
לאחר ההגדרה, ממשק Kibana APM מספק:
- זמן תגובה — ממוצע ואחוזון 95 לפי URL.
- תפוקה — בקשות לדקה.
- שיעור שגיאות — אחוז הבקשות עם שגיאות.
- Apdex — מדד שביעות רצון: יחס בין בקשות מהירות (<T), סבירות (<4T) ואיטיות.
התראות מוגדרות ב-Kibana Alerting: אם זמן התגובה p95 עולה על 3 שניות למשך יותר מ-5 דקות — הודעה ב-Slack או באימייל. לדפים קריטיים במיוחד (עגלה, תשלום), אנו מורידים את הספים ל-1 שנייה.
לוחות זמנים
| שלב | משך |
|---|---|
| התקנת APM Server + Elasticsearch | יום אחד |
| הגדרת סוכן PHP, נתונים ראשונים | 2–4 שעות |
| הגדרת לוחות מחוונים והתראות | יום אחד |
| כיוונון עדין (דגימה, spans מותאמים) | 1–2 ימים |
מה כלול?
אנו מספקים: תיעוד מלא של ארכיטקטורת ה-APM, הוראות תחזוקה, הדרכה למנהל המערכת שלכם על Kibana/New Relic, הגדרת התראות במסנג'ר הארגוני שלכם. אופציונלית, אינטגרציה עם מערכת הניטור הקיימת שלכם (Zabbix, Prometheus). מפתח ביד — מהתקנת הסוכן ועד לוחות מחוונים חיים. צרו קשר לייעוץ — נעריך את הפרויקט שלכם בחינם.
מה הנתונים אומרים
לפי תיעוד סוכן Elastic APM PHP, העומס המינימלי ב-sample_rate 0.1 הוא פחות מ-1% — מאושר על ידי המדידות שלנו בפרויקטים עם קטלוגים של עד 500,000 מוצרים.
למה לבחור בנו?
אנו עובדים עם 1С-Битрикс ו-APM למעלה מ-5 שנים. הגדרנו ניטור ל-40+ פרויקטים, כולל קטלוגים עם מיליוני מוצרים ו-CRM עם אלפי עסקאות ביום. ניסיון עם Elastic APM, New Relic, Datadog. אנו עובדים תחת חוזה עם אחריות. הזמינו הגדרת APM לאתר ה-Bitrix שלכם וקבלו שקיפות ביצועים.
APM לא מחליף פרופילינג — הוא מראה מה מתדרדר ומתי. פרופילר מסביר למה. אבל יחד הם נותנים שליטה מלאה. קבלו ייעוץ — נעזור לכם למצוא את הפתרון האופטימלי.