Professional Monitoring Setup for 1C-Bitrix
Recently, a client approached us with a catalog of 150,000 items. Pages loaded in 8 seconds, but load testing showed nothing—the problem only appeared under real traffic. It turned out that slow SQL queries accumulated over a week, and the system degraded gradually. Monitoring caught the trend in time, and we optimized the queries in one day. Without continuous metric collection, you learn about the problem from the user, not from the system.
According to Bitrix Benchmark, 60% of projects have suboptimal SQL queries that go unnoticed until a crash.
Why Continuous Monitoring Is More Effective Than One-Time Measurements
A one-time load test is a photo; continuous monitoring is high-definition video. A one-time measurement captures the state at the moment of the test but does not show trends. Continuous monitoring allows you to see: a 200% increase in SQL query time over a month, a 2 GB weekly increase in Redis memory consumption, or PHP-FPM approaching saturation. Only with history can you distinguish a random spike from systemic degradation. For example, on one project, we noticed a 15% increase in 5xx errors over a week—it turned out that a module update caused a memory leak in Redis. Monitoring caught it 2 days before the first complaints.
Problems We Solve
- Hidden degradation: response time increases by 300% over two weeks due to non-optimal queries. Without monitoring—only customer complaints.
- PHP-FPM overflow: active processes > 85% max_children—the site starts to slow down, and you don't know if it's time to expand the pool.
- Redis memory leak: memory consumption grows by 2 GB per week after a module update. Monitoring detects the leak before Redis starts evicting keys.
- MySQL slow queries: 10+ slow queries per minute—indexes and query structure require review.
How We Set Up Monitoring: Stack and Configs
We deploy Prometheus with exporters on target servers. For a typical project, we use:
-
node_exporter— system metrics (CPU, RAM, disk, network) -
mysqld_exporter— MySQL/MariaDB metrics (slow queries, InnoDB, connection pool) -
php-fpm_exporter— PHP-FPM metrics from/fpm-status -
redis_exporter— Redis metrics (memory, hit rate, connected clients)
To get PHP-FPM status, add to the pool config:
pm.status_path = /fpm-status In nginx:
location /fpm-status { allow 127.0.0.1; deny all; fastcgi_pass unix:/run/php/php8.1-fpm.sock; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } The /fpm-status endpoint shows active/idle/waiting processes. If active processes is close to max_children — PHP is saturated, need to increase the pool or optimize code.
Then we collect data in Grafana: build dashboards with key metrics for Bitrix. Example alert: if php_fpm_active_processes exceeds 85% of max for more than 5 minutes — Telegram notification. If MySQL slow queries > 10/minute — Email. If site response time > 3 seconds — Telegram + call.
What Metrics Are Critical for Bitrix?
On the Grafana dashboard, we display:
-
php_fpm_active_processes / php_fpm_max_active_processes— PHP-FPM load -
mysql_global_status_slow_queries— number of slow queries -
redis_memory_used_bytes— Redis memory usage -
node_load1/node_load5— system load - Percentage of 5xx errors — indicator of application-level issues
Learn more about Prometheus and Grafana.
Monitoring Tools Comparison
| Tool | Type | History Storage | Alert Flexibility | Deployment Time |
|---|---|---|---|---|
| Built-in Bitrix Monitor | Internal | No (only current log) | Basic (time threshold) | 30 minutes |
| Prometheus + Grafana | External | Yes (up to 30 days or more) | Full (conditions, channels) | 3–4 hours |
| UptimeRobot | Availability | No | HTTP notifications | 10 minutes |
Key Metrics and Alert Thresholds
| Metric | Type | Alert Threshold | Priority |
|---|---|---|---|
| PHP-FPM load (active/max) | Percentage | > 85% for more than 5 min | High |
| Slow SQL queries | Count/min | > 10 | Medium |
| Redis memory | MB | > 80% of maxmemory | High |
| System load (load1) | Number | > 2 * (number of CPU cores) | Medium |
| 5xx errors | Percentage | > 1% over 5 min | Critical |
Example Grafana Dashboard for Bitrix
Graphs: PHP-FPM load (line), slow queries (histogram), 5xx errors (counter). All metrics aggregated by hour and day, allowing you to see trends. Alerts configured to Telegram and Email.Process of Work
- Analysis: study current architecture, load (number of requests, peaks), bottlenecks (what you already know).
- Design: choose exporters, develop alert schema, define thresholds.
- Implementation: deploy Prometheus, Grafana, configure metric collection with exporters.
- Test: verify data correctness, simulate failures, set up dashboards.
- Deploy: move to production, document, conduct team training (1-hour webinar on dashboards and alert responses).
What's Included in the Work
- Deployment of Prometheus + Grafana stack on your servers or in the cloud.
- Configuration of exporters (node, mysql, php-fpm, redis, optionally nginx).
- Development of dashboards with key metrics for Bitrix.
- Setup of alerts with notifications to Telegram and Email.
- Documentation on using dashboards and responding to alerts.
- Team training (up to 2 hours online).
- Post-release support for 2 weeks (threshold adjustments, exporter updates).
Timeline — from 3 to 5 business days for full implementation. Typical cost is $1,000–$2,000, with savings of $10,000+ in prevented downtime. Our team has 8+ years of experience and 50+ successful projects, guaranteeing reliable monitoring.
Order a free assessment of your project — we will analyze the current architecture and show the benefits of a monitoring system. Contact us to set up monitoring that identifies problems before users notice them.