Кэширование nginx: Мониторинг

Оригинал статьи тут, себе копирую, чтоб не потерять.

Объявляем новый log_format в nginx.conf:

log_format rt_cache '$remote_addr - $upstream_cache_status [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';

в server разделе вашего vhost:

И замените

access_log /var/log/nginx/example.com.access.log;
На вот такое:

access_log /var/log/nginx/example.com.access.log rt_cache;

Или можно поступить как-то так.

access_log /var/log/nginx/example.com.access.log;
access_log /var/log/nginx/example.com.cache.log rt_cache;

обратите внимание, что в разных логах различаются имена файлов.

Анализируем логи:

HIT vs MISS vs etc

Можно посмотреть статистику из access.log:

awk '{print $3}' access.log | sort | uniq -c | sort -r

Sample output:

800 HIT
779 -
392 BYPASS
19 EXPIRED
14 MISS

Важно: тире (“-“) означает прочие коды return 403, return 444, и возможно всякие файлы, что не попали к нам в локейшин в котором действует кэш.

Посмотреть список уролов с MISS

awk '($3 ~ /MISS/)' access.log | awk '{print $7}' | sort | uniq -c | sort -r

BYPASS Requests URLs

awk '($3 ~ /BYPASS/)' access.log | awk '{print $7}' | sort | uniq -c | sort -r
MISS v/s BYPASS

MISS – Это промахнулись мимо кэша, возможно это первое обращение, после которого кэш создаётся.

BYPASS – это пропуск к бэкэнду минуя кэн nginx например для залогиненных пользователей.

md0 после сбоя не стартует

Запись будет дополнятся, но пока ключевое для себя вынесу в такой сумбур.

Уже 2 раза было, проблемы с питанием, рушится рейд, точнее выходит покурить один из дисков, тесты по диску проходят отлично но, диск назад не идёт в рейд под различными предлогами.
в статусе написано
State : active, degraded, Not Started
при добавлении диска в сислоге отражается вот это
md0: ADD_NEW_DISK not supported
по пол дня убивал на воскрешение, и решил записать примерную последовательность.

помогает удалить этот диск из рейда, и заного собрать массив с -f флагом
пробуем собрать массив
mdadm --assemble --scan
смотрим что там и как
mdadm --detail /dev/md0
раз не пошло, тормозим его
mdadm --stop /dev/md0
и пробуем ещё раз
mdadm --assemble --force /dev/md0
смотрим что буквы U_UUUU появились
cat /proc/mdstat
если по началу было так
Personalities : [raid6] [raid5] [raid4]
md0 : inactive sdf1[9] sdg1[2] sdh1[3] sdc1[5] sdd1[4] sda1[8] sdb1[7] sde1[0]
12697839538 blocks super 1.2

то стало так
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sde1[0] sdb1[7] sda1[8] sdd1[4] sdc1[5] sdh1[3] sdg1[2] sdf1[9]
10255949312 blocks super 1.2 level 5, 512k chunk, algorithm 2 [8/7] [U_UUUUUU]
[>....................] recovery = 1.5% (22352004/1465135616) finish=1610.7min speed=14928K/sec

unused devices:

Удалить большое число файлов из каталога

Так получилось, что место хранения файлов сессий было перенесено, и пару сотен миллионов файлов мило хранилось в одном каталоге, удалить ни каталог ни файлы не получалось классическими методами.
на хабре был по подсмотрен вот такой вот выход:

nice -n 19 ionice -c3 find /home/tmp/folder.ru/ -maxdepth 1 -type f -name sess* | xargs -n1 nice -n 19 ionice -c3 rm

Ещё вариант на пёрле через unlink

perl -e 'chdir "/home/tmp/site.sess" or die; opendir D, "."; while ($n = readdir D) { unlink $n }'

где /home/tmp/site.sess это каталог с сессиями

mdadm заменить диск, изменить размер массива (программный рейд)

ВАЖНО перед любыми операциями на хранилище убедитесь что бэкапы актуальны и исправны.

Сначала смотрим состояние массива, важно чтоб не шла синхронизация либо пересборка..
(я сделал ошибку, диск сбойнул и электричество выключили, я поменял физически диск и потом пытался собрать массив, что стоило мне немного нервов, надо было дождаться восстановления массива(а диск что вылетел пометить как сбойный), а уже потом идти менять диск.)

cat /proc/mdstat

вот например

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sdc1[8] sde1[7] sdg1[5] sdf1[2] sdd1[6]
5860147200 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU]
[=================>...] resync = 88.6% (1732051884/1953382400) finish=38.6min speed=95562K/sec

unused devices:

если такого нет, то помечаем диск сбойным

mdadm --manage /dev/md0 --fail /dev/sda1

затем удаляем его из массива
mdadm --manage /dev/md0 --remove /dev/sda1

выключаем сервер, меняем диск, новый диск перед добавлением в массив надо подготовить
а именно, копируем на него таблицу разделов с уже имеющего в рейде диска
sfdisk -d /dev/sdb | sfdisk /dev/sda

И добавляем заменённый диск в массив
mdadm --manage /dev/md0 --add /dev/sda1

после чего автоматически начнётся пересборка массива.

Расширение массива
Так получилось, что у меня массив состоял из дисков по 1.5ТБ но потом их перестали выпускать, и я менял диски на 2ТБ, но они не использовались по полной…
в итоге остался один диск на 1.5ТБ, решено его заменить на 2ТБ и расширить массив.

также перед началом смотрим что массив наш исправен, если всё ок то начинаем
mdadm --grow /dev/md0 --size=max
Автоматически начинается пересборка массива, у меня началась с 75%

вот что было до команды
# mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Mar 11 11:32:41 2013
Raid Level : raid6
Array Size : 4395018240 (4191.42 GiB 4500.50 GB)
Used Dev Size : 1465006080 (1397.14 GiB 1500.17 GB)
Raid Devices : 5
Total Devices : 5

вот что стало после
# mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Mar 11 11:32:41 2013
Raid Level : raid6
Array Size : 5860147200 (5588.67 GiB 6000.79 GB)
Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB)
Raid Devices : 5
Total Devices : 5

После синхронизации дисков, нужно расширить Файловую систему
предварительно выполнив проверку текущей, но
перед проверкой надо отмонтировать фс
umount /dev/md0
и проверяем
e2fsck -f /dev/md0

если всё ок, то расширяем ФС
resize2fs /dev/md0

Следить за процессом пересборки массива удобно вот такой командой
watch cat /proc/mdstat

apache 2.4 не видит виртуальные хосты не выполняет php ( [authz_core:error] client denied by server configuration )

Сразу несколько проблем в раз.

Местами встречаясь с Debian 8 стал замечать? что мои прошлые наработки и конфиги перестают работать.

Например, Apache перестал видеть виртуальные хосты, которые я ему создаю, а причина оказалась проста, отныне вхосты теперь должны иметь расширение .conf остальные файлы игнорируются.

поэтому делаем так
mv /etc/apache2/sites-available/example.com /etc/apache2/sites-available/example.com.conf

также обязательно добавить Require all granted в секцию Directory вашей конфигурации, а это без этого бутт ошибка

[authz_core:error] AH01630: client denied by server configuration:

Более подробно можно почитать вот тут