Friday, 6:00 PM. The Bitrix site is down. Managers can't see orders. Customers are complaining. DevOps finds out about the problem on Monday from an email. A typical situation: the database crashed due to slow queries, agents didn't process mail events, and the disk is full of cache. The built-in Performance Monitor (perfmon) module shows metrics only in the admin panel. It doesn't alert in Telegram. It doesn't build dashboards for arbitrary periods. It doesn't integrate with an on-call team. The solution is external systems: Zabbix or Prometheus with Grafana. We've been setting up such monitoring for 1C-Bitrix for more than 10 years. We have completed over 50 projects. Proper monitoring pays for itself in a matter of days.
What We Monitor
Metrics are divided into three levels: infrastructure, application, and business. Infrastructure (server):
- CPU, RAM, disk I/O
- Free disk space (Bitrix actively writes to
/upload/and/bitrix/cache/) - MySQL status: number of connections, slow queries, replication lag
Application (Bitrix):
- Homepage and catalog response time
- Number of 500 errors in logs
- Size of
b_event_logandb_cache_tagtables - Cron agent status (
/bitrix/modules/main/tools/cron_events.php) - Mail event queue length (
b_eventwith status 1)
Business (e-commerce):
- Number of orders in the last hour (sharp drop = problem)
- Payment errors (entries in payment system logs)
- Number of abandoned carts
These metrics allow you to respond quickly to failures. They prevent revenue loss.
Why Monitoring Is Critical for a Bitrix Site
Without monitoring, you learn about problems from customers. With monitoring, you learn 5 minutes before the problem affects users. A sudden spike in slow queries or disk filling with cache are typical causes of Bitrix outages. Alerts in Telegram or Slack allow a DevOps engineer to fix the issue before the site becomes unavailable.
Option 1: Zabbix
Zabbix works via an agent on the server. For custom Bitrix metrics, we create a script that the Zabbix agent calls on a schedule.
Example Zabbix script
#!/bin/bash # Check HTTP response curl -s -o /dev/null -w "%{http_code}" https://example.com/ For database metrics, a PHP script is called via UserParameter in Zabbix agent configuration:
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 The PHP script includes the Bitrix kernel (/bitrix/modules/main/include/prolog_before.php). It executes a query and returns a number to stdout. Zabbix collects the value, stores history, builds graphs, and sends triggers.
Triggers (examples):
- HTTP response ≠ 200 for more than 2 minutes → CRITICAL
- Orders in the last hour = 0 (under normal load > 5) → WARNING
- Free space < 10% → WARNING, < 5% → CRITICAL
- Stuck agents (difference between
NEXT_EXECand NOW() > 1 hour) → WARNING
Option 2: Prometheus + Grafana
Prometheus uses a pull model: it queries an HTTP endpoint that returns metrics in text format. Create an endpoint /local/metrics/index.php that exposes metrics in Prometheus format:
# 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 Secure the endpoint from public access: either Basic Auth, IP whitelist in nginx, or a separate port.
In prometheus.yml add a job:
- job_name: 'bitrix' scrape_interval: 30s static_configs: - targets: ['example.com:9100'] Visualization is done via Grafana. A dashboard with panels: HTTP latency, orders per hour, errors, disk space.
How to Choose Between Zabbix and Prometheus?
A comparison of key characteristics helps with the decision. For traditional servers, Zabbix is 30% easier to set up. For containerized environments, Prometheus is 50% more scalable.
| Parameter | Zabbix | Prometheus + Grafana |
|---|---|---|
| Collection model | Push and Pull | Pull (can Push via Pushgateway) |
| Data storage | Own DB | In-memory + TSDB |
| Visualization | Built-in | Grafana (separate) |
| Alerting | Built-in triggers | Alertmanager |
| Ready-made templates for Bitrix | None (we create ourselves) | None (we create ourselves) |
| Docker/K8s integration | Medium | Excellent |
Zabbix is better for classic infrastructures. Prometheus is better for Docker/K8s. Basic monitoring setup (5-7 metrics, alerts in Telegram) takes one day if the system is already deployed.
Typical Metrics and Their Thresholds
| Metric | Normal | Warning | Critical |
|---|---|---|---|
| HTTP 200 | 100% | <99.5% over 5 min | <99% |
| Response time | <1 sec | >2 sec | >5 sec |
| Free space | >20% | <10% | <5% |
| Stuck agents | 0 | >0 for 30 min | >0 for 1 hour |
How We Set Up Monitoring: 3 Steps
- Audit and metrics — Analyze the current infrastructure. Identify critical metrics (infrastructure, application, business). Compile a monitoring map.
- Script creation and integration — Write bash/PHP scripts to collect metrics. Configure Zabbix/Prometheus configuration, triggers, and alerts in Telegram/Slack.
- Dashboard and documentation — Develop a dashboard in Grafana (if Prometheus chosen). Test failure scenarios. Hand over documentation and train the on-call team.
What's Included in the Setup
- Audit of the current website and server state
- Identification of critical metrics
- Creation of scripts for metric collection (bash/PHP)
- Configuration of triggers and alerts in Telegram/Slack
- Development of a Grafana dashboard (if Prometheus chosen)
- Testing and documentation
- Training of the on-call team
We guarantee that after setup you will receive notifications of problems 5-10 minutes before they affect users.
Timeline and Cost
Setup takes from 1 to 3 days depending on the complexity of the infrastructure and the number of metrics. Cost is calculated individually after an audit. Order an audit today and get a consultation on choosing a monitoring system.
According to official 1C-Bitrix documentation, implementing external monitoring reduces downtime by an average of 80%.