Why Bitrix server monitoring is the first line of defense
A site can be perfectly written, but if the server is unavailable, the client sees ERR_CONNECTION_REFUSED. In 10+ years of working with Bitrix, we have encountered dozens of times a situation where a VPS went down due to a memory leak in MySQL or disk overflow in /upload/.
Server availability monitoring is a layer below website monitoring. Here, it is not the application's HTTP response that is checked, but the operation of the machine itself: network, disk, memory, processes.
This is especially relevant for Bitrix: the platform is resource-intensive, and a typical VPS on shared hosting runs at its limit. In one project, a MySQL memory leak consumed 12 GB out of 16 GB RAM, swap grew to 2 GB, and TTFB soared to 7 seconds. The monitoring system triggered within 2 minutes — downtime was prevented.
What metrics should be monitored first?
Server monitoring is not a single check but several levels, each catching its own class of problems.
Ping (ICMP). The most basic check: if the server responds to ping, the machine is on and the network is working. If it does not respond, either the server is down, the network is unavailable, or a firewall is blocking ICMP (in which case ping is useless). Interval — 30-60 seconds.
Ports. We check TCP connection on key ports:
| Port | Service | What unavailability means |
|---|---|---|
| 80 | HTTP | Web server is not running |
| 443 | HTTPS | Web server or SSL is not working |
| 3306 | MySQL | Database is unavailable |
| 5432 | PostgreSQL | Database is unavailable |
| 22 | SSH | No remote access |
The port responds, but the service inside is hung — TCP handshake passes, but there is no data. For HTTP, this is caught through HTTP monitoring (TTFB > threshold). For MySQL, through specialized checks, for example SELECT 1.
System metrics. CPU, RAM, disk, swap, load average. Collected by an agent on the server (Zabbix agent, Telegraf, node_exporter for Prometheus). Critical thresholds for a typical Bitrix server:
| Metric | Warning | Critical |
|---|---|---|
| CPU usage | > 80% (5 min) | > 95% (5 min) |
| RAM usage | > 85% | > 95% |
| Disk usage | > 80% | > 90% |
| Swap usage | > 50% | Any swap usage |
| Load average | > number of cores | > 2x cores |
Swap on a Bitrix server is an alarming signal. MySQL and PHP-FPM in swap run an order of magnitude slower. If swap is growing, RAM is insufficient; you need to optimize or add more.
Why is swap monitoring critical for Bitrix?
MySQL and PHP-FPM when RAM is insufficient go into swap, causing performance to drop by 10-30 times. For a typical catalog with 50 thousand products, this means TTFB > 5 seconds. An alert for any swap usage allows detecting the problem before users start complaining. In our practice, this prevented downtime whose cost per hour is calculated after audit.
How to set up alerts for Bitrix?
For server monitoring, response speed is more critical than for application monitoring. If the server is unavailable, all sites on it are down. Notification chain: Telegram (instantly) → SMS (after 5 minutes without acknowledgment) → call (after 15 minutes).
For teams — integration with PagerDuty or OpsGenie with on-call schedules. This reduces the average incident detection time from 30 minutes to 1 minute.
Processes: what should be running. For a typical Bitrix configuration (Apache/Nginx + PHP-FPM + MySQL), we monitor the presence of processes:
- nginx —
systemctl is-active nginx. If it goes down — 502 Bad Gateway. - php-fpm —
systemctl is-active php8.1-fpm. If it goes down — 502 or 500. - mysqld —
systemctl is-active mysql. If it goes down — white screen or database connection error. - cron —
systemctl is-active cron. If it goes down — Bitrix agents do not run (when usingcron_events).
Additionally for a production configuration:
- memcached or redis — if used as a cache backend (
cache_typein.settings.php). A cache server failure does not bring down the site but sharply increases the load on MySQL. - sphinx or elasticsearch — if an external search index is used.
How to choose a monitoring tool for your project?
Zabbix — a full-fledged monitoring system. Zabbix agent is installed on the server, collects metrics, and sends them to Zabbix server. Ready-made templates for Linux, MySQL, Nginx, PHP-FPM.
Trigger setup: {host:system.cpu.util.avg(5m)} > 80 — alert when CPU > 80% for 5 minutes. For a single server, Zabbix is configured twice as fast as Prometheus.
Prometheus + Grafana — alternative stack. Node_exporter collects metrics, Prometheus stores them, Grafana visualizes. Alertmanager sends notifications. More flexible than Zabbix in visualization but requires more setup time. For clustered infrastructure — definitely Prometheus.
Netdata — an agent with a web interface, installed in a minute. Shows metrics in real time with per-second detail. No built-in history storage (integration with Prometheus/Graphite required). Suitable for quick diagnostics.
Control panel (ISPmanager, VestaCP). If the server is managed through a panel, it usually has basic monitoring: CPU, RAM, disk graphs. As a rule, there are no alerts.
Specifics of Bitrix servers
BitrixVM environment. If the server is deployed from a BitrixVM image, it has its own preinstalled set of monitoring scripts: /etc/cron.d/bx_*, status check via /opt/webdir/bin/bx-monitor.
These scripts check MySQL, Nginx, PHP-FPM and send the result to the BitrixVM panel (https://server:8443). Basic monitoring, but without external notifications. As noted in BitrixVM documentation, OS-level monitoring is the first line of defense.
MySQL. For Bitrix, the following are critical: Threads_connected (current connections), Slow_queries (slow queries), Innodb_buffer_pool_reads (InnoDB cache misses). We monitor via the Zabbix MySQL template or via mysqladmin extended-status.
Size of /upload/. The /upload/ directory on Bitrix sites grows uncontrollably: catalog images, 1C exchange files, temporary files.
We monitor du -sh /home/bitrix/www/upload/ — if it approaches the disk limit, cleanup is needed via the built-in Bitrix tool "Settings → File cleanup" or manual review.
Backups. Monitoring not only the server but also its backups. We check the date of the last backup (a file in the /backup/ directory or a log entry). If the backup is older than 24 hours — warning. Data loss without a fresh backup is a catastrophe that monitoring must prevent.
What is included in turnkey monitoring setup
We provide a full cycle of work:
- Audit of the current server configuration and identification of bottlenecks.
- Development of a monitoring scheme: metrics, triggers, notification channels.
- Installation and configuration of agents (Zabbix/Prometheus) and integration with Telegram/PagerDuty.
- Creation of dashboards in Grafana (optional).
- Documentation with instructions for your team.
- Training employees to work with the system.
- 30-day performance guarantee after implementation.
We have been administering Bitrix for more than 10 years and have completed over 50 projects. Our engineers are certified and have experience with high-load systems. Contact us for an assessment of your project — we guarantee that your infrastructure will be under control 24/7. Get a consultation; we will calculate the cost and timeline individually.
How setup takes place in 5 steps
- Audit of the current configuration — we check the infrastructure: software versions, load, bottlenecks. We record the current thresholds.
- Development of a monitoring scheme — we define metrics, triggers, and notification channels for your architecture.
- Installation and configuration of agents — Zabbix agent / Prometheus node_exporter, metric collection configuration.
- Creation of dashboards and alerts — in Grafana (optional) or Zabbix, integration with Telegram/SMS/PagerDuty.
- Testing and documentation — we check that alerts fire, and write instructions for your team.
Order setup of 1C-Bitrix server monitoring — we will turn the chaos of metrics into a clear picture.