Часто с каким-либо проектом на битрикс возникают проблемы. Например, какой-то запрос подвесил базу, и сайт был недоступен в течение нескольких минут. Манагеры идут к админу и просят узнать, что могло вызвать причину недоступности. Для этого будем снаряжать инструменты траблшутинга.
- Зафиксируем процессы в БД. Каждую минуту будем записывать все процессы. Для этого на сервере с базой (подразумевается, что он отдельно от сервера приложения) ставим ежеминутно на крон следующий скрипт:
#!/bin/bash
PATH=/u01/mysql_process_list/`date +%Y`/`date +%m`/`date +%d`
if [ ! -d $PATH ] ; then mkdir -p $PATH; fi
echo "show full processlist" | mysql -u root -A database > $PATH/process_`date +%Y-%m-%d_%H-%M-%S`Каждую минуту будет создаваться папка, если таковой не существует, с датой и временем, куда будет записываться вывод всех текущих процессов в БД вида:
Id User Host db Command Time State Info Rows_sent Rows_examined
2802551 corp 10.89.108.132:37018 Sleep 25 NULL 0 0
2804074 corp 10.89.108.132:51250 Sleep 7 NULL 0 0
2804079 corp 10.89.108.132:51298 Sleep 7 NULL 0 0
2804082 corp 10.89.108.132:52032 Query 3 Sending data SELECT \n\t`main_user_ref`.`COLOR` AS `COLO
2804087 corp 10.89.108.132:52208 Sleep 2 NULL 0 0
2804088 corp 10.89.108.132:52602 Sleep 1 NULL 0 0
2804089 root localhost Query 0 starting show full processlist 0 02. Зафиксируем сетевые соединения на сервере приложения для веб-сервера httpd. Каждую минуту будем собирать открытые сетевые соединения и складировать в директорию с датой и временем по аналогии с процессами в БД. Скрипт такой:
#!/bin/bash
PATH=/var/log/netstat/`date +%Y`/`date +%m`/`date +%d`
if [ ! -d $PATH ] ; then mkdir -p $PATH; fi
/bin/netstat -ntp | grep 'httpd' > $PATH/stat-`date +%Y-%m-%d_%H-%M-%S`Результат будет вида:
tcp 0 0 127.0.0.1:8888 127.0.0.1:59420 ESTABLISHED 4282/httpd
tcp 0 0 127.0.0.1:8888 127.0.0.1:58464 ESTABLISHED 4327/httpd
tcp 0 0 10.89.108.132:52032 10.89.108.129:3306 ESTABLISHED 4297/httpd
tcp 0 0 127.0.0.1:8888 127.0.0.1:59244 ESTABLISHED 4297/httpd
tcp 0 0 10.89.108.132:51250 10.89.108.129:3306 ESTABLISHED 4327/httpd
tcp 0 0 127.0.0.1:8888 127.0.0.1:58512 ESTABLISHED 4316/httpd
tcp 0 0 10.89.108.132:52208 10.89.108.129:3306 ESTABLISHED 4282/httpd
tcp 0 0 127.0.0.1:58504 127.0.0.1:1230 ESTABLISHED 4327/httpd
tcp 0 0 127.0.0.1:58552 127.0.0.1:1230 ESTABLISHED 4316/httpd
tcp 0 0 10.89.108.132:51298 10.89.108.129:3306 ESTABLISHED 4316/httpd3. И теперь осталось зафиксировать информацию из самого веб-сервера, используя модуль status. По умолчанию, в виртуальной машине Bitrix данный модуль уже был включен. Конфиг его следующий:
<IfModule mod_status.c>
ExtendedStatus On
<Location /server-status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</Location>
</IfModule>Разрешается обращение по <srv-name>/server-status с локального хоста, остальным запрещено. И сам скрипт вывода информации:
#!/bin/bash
PATH=/var/log/server-status/`date +%Y`/`date +%m`/`date +%d`
if [ ! -d $PATH ] ; then mkdir -p $PATH; fi
/bin/curl localhost:8888/server-status > $PATH/status-`date +%Y-%m-%d_%H-%M-%S`Апач слушает на порту 8888.
Вывод будет следующий:
Теперь, используя все подготовленные инструменты, можно явно найти, какой запрос навредил сайту и положил его.
Например, сайт упал в 10:37. Идём в директорию, куда складируются все процессы БД и открываем нужную за 10.37. Видим, что был какой-то один запрос:
2804082 corp 10.89.108.132:52032 Query 3 Sending data SELECT \n\t`main_user_ref`.`COLOR` AS `COLOR......Имеем информацию, что он пришёл с сервера 10.89.108.132 с соединения 52032.
Далее уже на веб-сервере 10.89.108.132 в директории сетевых соединений по тому же времени падения ищем нужный процесс с 52032:
ESTABLISHED 4327/httpd
tcp 0 0 10.89.108.132:52032 10.89.108.129:3306В итоге получили, что это апач с PID 4327, который можно найти в последнем оставшемся логе server-status, где показано, какой URL или скрипт вызвал обрушение.