Автоматическая очистка кэша Nginx: настройка cron-задач и скриптов

Автоматическая очистка кэша Nginx решает задачу контроля дискового пространства и актуальности данных без ручного вмешательства. Вы настраиваете cron-задачу, которая запускает shell-скрипт, удаляет устаревшие файлы fastcgi- или proxy-кэша, пишет лог и при необходимости отправляет уведомление. Далее разобраны готовые скрипты, критерии удаления, настройка логирования и интеграция с Zabbix и Prometheus.

Кэш Nginx хранит ответы бэкенда на диске, чтобы не генерировать их заново при каждом запросе. Для динамики через FastCGI используется fastcgi_cache, для проксирования на бэкенд - proxy_cache. Оба типа создают иерархию каталогов с файлами, имена которых основаны на хэшах ключей. Со временем часть данных устаревает: контент изменился, товар снят с публикации, страница удалена. Если кэш не очищать, он разрастается и занимает место, а при ограниченном диске может привести к деградации сервиса.

Ручная очистка через find и rm работает, но не масштабируется. Администратор забывает запустить команду, пропускает нужный каталог или удаляет лишнее. Автоматизация убирает человеческий фактор, гарантирует регулярность и фиксирует результат в логе. Это особенно важно при частом обновлении контента, строгих политиках хранения данных и работе нескольких сайтов на одном сервере.

Зачем автоматизировать очистку кэша Nginx?

Кэш Nginx бывает двух основных типов: fastcgi и proxy. Первый используется при работе с PHP-FPM и другими FastCGI-бэкендами, второй - при проксировании запросов на upstream-серверы. Оба типа хранят файлы на диске, и оба требуют периодической очистки.

Автоматизация нужна в трёх случаях. Первый: высокая частота обновления контента. Если каталог товаров или лента новостей меняется каждые несколько минут, устаревший кэш отдаёт неверные данные. Второй: ограниченное дисковое пространство. Кэш на 20–30 ГБ для VPS с диском 50 ГБ - это риск заполнения раздела. Третий: политики хранения. Компании требуют хранить кэш не дольше определённого срока, и cron-задача обеспечивает соблюдение регламента.

Ручная очистка отнимает время и подвержена ошибкам. Автоматический скрипт выполняется ночью, в непиковые часы, не требует присутствия администратора и оставляет запись в логе. Результат предсказуем: освобождённое место, актуальные данные, меньше инцидентов.

Подготовка к автоматизации: что нужно знать

Перед написанием скрипта определите пути к каталогам кэша и критерии удаления. Ошибка в пути приведёт к тому, что скрипт удалит не те файлы или не найдёт кэш. Ошибка в критериях - к удалению свежих данных и лишней нагрузке на бэкенд.

Определение путей к кэшу fastcgi и proxy

Пути задаются директивами fastcgi_cache_path и proxy_cache_path в конфигурации Nginx. Пример для fastcgi:

fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=FASTCGICACHE:100m inactive=60m max_size=1g;

Пример для proxy:

proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=PROXYCACHE:100m inactive=60m max_size=1g;

Проверить актуальные пути можно командой nginx -T, которая выводит полную конфигурацию, включая подгруженные файлы. Отфильтруйте вывод:

nginx -T 2>/dev/null | grep -E 'fastcgi_cache_path|proxy_cache_path'

В дистрибутивах Debian и Ubuntu кэш обычно находится в /var/cache/nginx, в CentOS и AlmaLinux - там же, но при кастомной сборке путь может отличаться. Всегда проверяйте конфигурацию, а не полагайтесь на значения по умолчанию.

Выбор критериев для удаления файлов

Основной критерий - время последнего изменения файла, mtime. Команда find с параметром -mtime +7 найдёт файлы, изменённые более 7 дней назад. Для кэша это рабочий вариант: если файл не обновлялся неделю, данные с высокой вероятностью устарели.

Используйте -type f, чтобы исключить каталоги из обработки. Добавьте -name '*' для явного указания всех файлов. Не удаляйте файлы, которые находятся в процессе записи: Nginx создаёт временные файлы и переименовывает их. Параметр -mmin +10 вместо mtime позволяет отсечь файлы моложе 10 минут и снизить риск конфликта.

Стратегия по размеру: если кэш превышает лимит, удаляйте самые старые файлы до достижения целевого объёма. Стратегия по количеству: ограничивайте число файлов в каталоге. Для большинства сценариев достаточно mtime.

Создание shell-скрипта для очистки кэша

Скрипт должен быть идемпотентным: повторный запуск не должен ломать систему. Используйте переменные для путей и параметров, проверяйте существование каталога, логируйте результат.

Пример скрипта для fastcgi-кэша

#!/bin/bash
set -euo pipefail

CACHE_DIR="/var/cache/nginx/fastcgi"
LOG_FILE="/var/log/nginx-cache-clean.log"
DAYS=7

if [ ! -d "$CACHE_DIR" ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') ERROR: $CACHE_DIR not found" >> "$LOG_FILE"
    exit 1
fi

SIZE_BEFORE=$(du -sh "$CACHE_DIR" 2>/dev/null | cut -f1)
COUNT=$(find "$CACHE_DIR" -type f -mtime +$DAYS -print -delete | wc -l)
SIZE_AFTER=$(du -sh "$CACHE_DIR" 2>/dev/null | cut -f1)

echo "$(date '+%Y-%m-%d %H:%M:%S') fastcgi: deleted $COUNT files, size before: $SIZE_BEFORE, after: $SIZE_AFTER" >> "$LOG_FILE"

Скрипт удаляет файлы старше 7 дней, считает их количество и фиксирует размер каталога до и после. Лог дополняется при каждом запуске.

Пример скрипта для proxy-кэша

#!/bin/bash
set -euo pipefail

CACHE_DIR="/var/cache/nginx/proxy"
LOG_FILE="/var/log/nginx-cache-clean.log"
DAYS=7

if [ ! -d "$CACHE_DIR" ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') ERROR: $CACHE_DIR not found" >> "$LOG_FILE"
    exit 1
fi

SIZE_BEFORE=$(du -sh "$CACHE_DIR" 2>/dev/null | cut -f1)
COUNT=$(find "$CACHE_DIR" -type f -mtime +$DAYS -print -delete | wc -l)
SIZE_AFTER=$(du -sh "$CACHE_DIR" 2>/dev/null | cut -f1)

echo "$(date '+%Y-%m-%d %H:%M:%S') proxy: deleted $COUNT files, size before: $SIZE_BEFORE, after: $SIZE_AFTER" >> "$LOG_FILE"

Структура та же, меняется только путь. Для серверов с обоими типами кэша объедините очистку в один скрипт с двумя блоками или создайте отдельные файлы.

Обработка ошибок и безопасность скрипта

Директива set -euo pipefail останавливает скрипт при любой ошибке, неинициализированной переменной или сбое в конвейере. Это предотвращает продолжение работы с некорректными данными.

Проверяйте права на каталог кэша. Скрипт должен выполняться от пользователя, у которого есть доступ на чтение и запись. Обычно это root или пользователь nginx. Запуск от root в cron допустим, но ограничьте права на сам скрипт: chmod 700 /usr/local/bin/nginx_cache_clean.sh.

Тестируйте на нерабочей среде. Скопируйте каталог кэша во временную директорию, запустите скрипт с изменённым путём и проверьте результат. Только после этого переносите в production.

Настройка cron-задачи для регулярного запуска

Cron - стандартный планировщик в Linux. Задача добавляется в crontab пользователя или в системный файл /etc/cron.d. Синтаксис: минуты, часы, день месяца, месяц, день недели, команда.

Выбор периодичности очистки

Периодичность зависит от скорости заполнения кэша и частоты обновления контента. Для активного сайта с обновлением каждые 10–15 минут - ежедневный запуск. Для корпоративного портала с редкими изменениями - раз в неделю. Слишком частая очистка увеличивает нагрузку на бэкенд: после удаления кэша Nginx заново генерирует ответы.

Оцените скорость заполнения: запустите du -sh /var/cache/nginx/proxy дважды с интервалом в сутки. Если прирост составляет 2–3 ГБ в день, а лимит 20 ГБ, ежедневная очистка файлов старше 7 дней поддерживает занятость в пределах 14–21 ГБ.

Добавление задачи в crontab

Откройте crontab:

crontab -e

Добавьте строку для ежедневного запуска в 3 часа ночи:

0 3 * * * /usr/local/bin/nginx_cache_clean.sh

Для еженедельного запуска по воскресеньям в 4 утра:

0 4 * * 0 /usr/local/bin/nginx_cache_clean.sh

Проверьте добавление:

crontab -l

Указывайте полный путь к скрипту. Cron использует ограниченное окружение, и относительные пути или алиасы не сработают. Если скрипт требует переменных окружения, задайте их в начале crontab или внутри скрипта.

Логирование и мониторинг выполнения

Лог - единственный способ убедиться, что очистка выполняется. Без него сбой останется незамеченным, пока кэш не заполнит диск.

Настройка уведомлений администратору

Для отправки email после выполнения скрипта используйте mailx или sendmail. Добавьте в конец скрипта:

if [ $? -eq 0 ]; then
    echo "Cache cleaned successfully" | mailx -s "Nginx cache clean OK" admin@example.com
else
    echo "Cache clean failed" | mailx -s "Nginx cache clean FAIL" admin@example.com
fi

Для отправки только при ошибке оберните основную логику в условие. Альтернатива - Slack или Telegram через webhook: curl с POST-запросом на URL бота. Это быстрее настраивается и не требует почтового сервера.

Интеграция с системами мониторинга (Zabbix, Prometheus)

Для Zabbix используйте zabbix_sender. Скрипт отправляет метрику о размере кэша или времени последней очистки:

zabbix_sender -z 127.0.0.1 -s "nginx-host" -k nginx.cache.size -o "$SIZE_AFTER"

В Zabbix создайте элемент данных типа Zabbix trapper с ключом nginx.cache.size. Триггер сработает при превышении порога.

Для Prometheus используйте node_exporter с текстовым коллектором. Создайте файл /var/lib/node_exporter/textfile_collector/nginx_cache.prom:

nginx_cache_size_bytes $(du -sb /var/cache/nginx/proxy | cut -f1)
nginx_cache_last_clean_timestamp $(date +%s)

Node_exporter подхватит файл автоматически. Метрики доступны на endpoint /metrics и могут быть визуализированы в Grafana.

Тестирование и устранение неполадок

Перед добавлением в cron запустите скрипт вручную:

bash /usr/local/bin/nginx_cache_clean.sh

Проверьте лог и размер каталога. Если скрипт не выполняется, запустите с отладкой:

bash -x /usr/local/bin/nginx_cache_clean.sh

Проверка работы cron-задачи

Системный лог cron находится в /var/log/syslog (Debian/Ubuntu) или /var/log/cron (CentOS/AlmaLinux). Проверьте записи:

grep CRON /var/log/syslog | tail -20

Для отладки временно добавьте задачу с выводом в файл:

* * * * * /usr/local/bin/nginx_cache_clean.sh >> /tmp/cron-debug.log 2>&1

После проверки удалите или замените на рабочую запись.

Частые проблемы и их решения

Скрипт не выполняется: проверьте права на файл (chmod +x) и путь в crontab. Удаляются не те файлы: перепроверьте критерии find и путь к каталогу. Лог не пишется: убедитесь, что каталог для лога существует и доступен для записи. Cron не запускает задачу: проверьте, что в crontab нет ошибок синтаксиса, и что переменная PATH включает нужные каталоги.

Заключение: лучшие практики автоматизации очистки кэша

Регулярная очистка кэша Nginx поддерживает производительность и предотвращает заполнение диска. Используйте скрипты с проверкой каталога и логированием, запускайте их в непиковые часы, настройте уведомления при сбоях. Периодически пересматривайте период хранения: при росте трафика уменьшайте DAYS, при спаде - увеличивайте.

Для углубления в тему изучите настройку proxy_cache в Nginx и шпаргалку по директивам кэширования. Для контейнерных сред смотрите очистку кэша в Docker и Kubernetes.