Настройка скриптов траблшутинга Apache в Bitrix

Часто с каким-либо проектом на битрикс возникают проблемы. Например, какой-то запрос подвесил базу, и сайт был недоступен в течение нескольких минут. Манагеры идут к админу и просят узнать, что могло вызвать причину недоступности. Для этого будем снаряжать инструменты траблшутинга.

  1. Зафиксируем процессы в БД. Каждую минуту будем записывать все процессы. Для этого на сервере с базой (подразумевается, что он отдельно от сервера приложения) ставим ежеминутно на крон следующий скрипт:
#!/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       0

2. Зафиксируем сетевые соединения на сервере приложения для веб-сервера 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/httpd

3. И теперь осталось зафиксировать информацию из самого веб-сервера, используя модуль 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 или скрипт вызвал обрушение.

Обсуждение закрыто.