Cron и обслуживание
Запланированные задачи
Заголовок раздела «Запланированные задачи»Контейнер cron запускает supercronic по файлу docker/supercronic/crontab. Все команды вызываются как php /app/bin/console <name>.
| Команда | Расписание | Назначение |
|---|---|---|
partitions:rotate | 0 2 * * * — ежедневно в 02:00 UTC | Создаёт партиции на 2 месяца вперёд; удаляет партиции старше окна хранения |
rate_limits:cleanup | 0 3 * * 0 — по воскресеньям в 03:00 UTC | Удаляет истёкшие корзины rate-limit из базы |
bots:update | 0 5 * * * — ежедневно в 05:00 UTC | Обновляет core.bot_ips из списка IP-ботов myip.ms |
bots:update-extra | 30 5 * * * — ежедневно в 05:30 UTC | Обновляет core.bot_asns (bad-ASN-список brianhama) и core.bot_cidrs (CIDR-списки датацентров + VPN от X4BNet) |
db:vacuum-stats | 30 3 * * * — ежедневно в 03:30 UTC | VACUUM ANALYZE текущей месячной партиции каждой таблицы статистики |
geoip:check | 0 6 * * * — ежедневно в 06:00 UTC | Проверяет файлы GeoLite2 .mmdb; логирует предупреждение и выходит с ненулевым кодом, если какой-то отсутствует или старше 14 дней (Telegram-уведомление об устаревшем GeoIP доставляется отдельно ежечасной задачей telegram:alerts) |
stats:refresh | */5 * * * * — каждые 5 минут | Обновляет материализованное представление stats.clicks_hourly |
telegram:digest | 0 10 * * * — ежедневно в 10:00 UTC | Отправляет ежедневную сводку (клики, конверсии, доход) в настроенный Telegram-чат |
telegram:alerts | 0 * * * * — каждый час | Отправляет системные оповещения (высокая доля ботов, лаг БД и т. д.) в Telegram |
db:backup | 0 1 * * * — ежедневно в 01:00 UTC | pg_dump в custom-формате; ротация на 14 дней |
postback:deliver | * * * * * — каждую минуту | Сливает ожидающие строки из core.postback_deliveries (исходящие S2S-постбэки с повторами по экспоненциальной задержке) |
inbox:flush | * * * * * — каждую минуту | Перекачивает stats.pixel_events_inbox → stats.pixel_events (обогащение GeoIP + UA); запускает 55-секундный внутренний цикл, поэтому события появляются за ~5–6 секунд |
rrweb:flush | * * * * * — каждую минуту | Перекачивает stats.rrweb_inbox → gzip-сжатые stats.rrweb_chunks + upsert stats.rrweb_sessions; тот же 55-секундный цикл, поэтому реплеи сессий появляются за несколько секунд |
Подробнее о том, как наполняются списки для обнаружения ботов, см. в разделе «Обнаружение ботов» в «Фильтрации трафика».
Партиции и хранение данных
Заголовок раздела «Партиции и хранение данных»stats.clicks, stats.pixel_events и stats.visitors_fingerprints RANGE-партиционированы по created_at с месячным интервалом. Каждая партиция также несёт BRIN-индекс по created_at (кроме visitors_fingerprints, где используется обычный индекс по fp_hash). stats.rrweb_chunks (сырые данные реплеев сессий) партиционируется посуточно — они объёмные и живут недолго.
partitions:rotate (запускается ежедневно в 02:00 UTC) делает две вещи:
- Создаёт вперёд — гарантирует наличие партиций для текущего месяца и следующих 2 месяцев (всего 3).
- Удаляет истёкшие — удаляет партиции, данные которых полностью вне настроенного окна хранения.
Значения хранения по умолчанию (применяются, если в core.settings нет переопределения):
| Таблица | Хранение по умолчанию |
|---|---|
stats.clicks | 365 дней |
stats.pixel_events | 90 дней |
stats.visitors_fingerprints | 30 дней |
core.auth_events | 180 дней |
Чтобы изменить окна хранения, используйте вкладку General на /admin/settings — см. Настройки и уведомления. Изменения применяются при следующем запуске partitions:rotate.
Чтобы вручную провести ротацию партиций:
docker compose exec app php bin/console partitions:rotateЭто также необходимо перед запуском набора интеграционных тестов (make test-up вызывает её автоматически против db-test).
db:backup (ежедневно в 01:00 UTC) запускает pg_dump --format=custom и пишет дамп в /app/var/backups/ внутри контейнера app. После каждого успешного дампа он ищет файлы старше 14 дней и удаляет их, храня не более 14 дней истории.
Чтобы запустить бэкап вручную:
docker compose exec app php bin/console db:backup# или:make backupЧтобы восстановиться из дампа:
# Список доступных дамповdocker compose exec app ls /app/var/backups/
# Восстановление (аргумент 'yes' подтверждает деструктивную операцию)docker compose exec app php bin/console db:restore <filename>.dump yesСмонтируйте том хоста поверх /app/var/backups/, если вам нужны копии дампов вне контейнера.
