Сколько строк логов в день вы генерируете: расчёт хранилища на год вперёд

MAATRIX

Диск под логи почти никогда не планируют — берут «с запасом» и забывают, пока раздел не заполняется в самый неподходящий момент. Разница между «с запасом» и точным расчётом простая: замерить текущую скорость роста, применить к ней коэффициент сжатия при ротации и честно заложить рост нагрузки на год вперёд. Ниже — рабочая методика без гадания, с конкретными командами.

Замер текущей скорости роста логов

Прежде чем считать что-то на год вперёд, нужна base rate — сколько логов реально пишется сегодня. Не «на глаз по ощущениям», а измеренная цифра за несколько дней подряд, потому что один день может быть нетипичным (пиковый трафик, инцидент с ретраями, включённый debug-режим).

Самый простой способ — снимать размер директорий с логами раз в сутки и складывать в файл:

# в cron, раз в сутки, например в 23:55
echo "$(date +%F) $(du -sb /var/log | cut -f1)" >> /var/log/growth-tracking.log

Через неделю-две в growth-tracking.log будет ряд чисел, по которому легко посчитать суточный прирост:

awk 'NR>1{print $1, $2-prev} {prev=$2}' /var/log/growth-tracking.log

Если под рукой нет пары недель истории и нужно быстро прикинуть — посчитайте построчно. Для nginx это просто:

wc -l /var/log/nginx/access.log

Разделите число строк на длительность лога (когда был создан текущий файл — смотрите stat -c %Y /var/log/nginx/access.log и текущее время) и умножьте на средний размер строки (du -sb файла делить на wc -l). Получите строк/сутки и байт/сутки одновременно — это и есть ваша база для прогноза. Для приложения без чёткой ротации по времени тот же приём работает с любым лог-файлом: главное — знать, с какого момента он пишется.

Отдельно проверьте разницу между df и du: если сервис держит открытый файловый дескриптор на уже удалённый (например, ротация logrotate без copytruncate и рестарта процесса) лог-файл, du покажет одно, а реальное занятое место на диске — другое. Это отдельная и частая причина, почему расчёт «по du» расходится с тем, что видит df -h; если сталкивались с таким — у нас есть разбор, почему df и du показывают разное.

Учитывайте источники логов по отдельности, а не только суммарно: у веб-сервера, приложения, СУБД и journald разная динамика роста, и для прогноза полезно видеть каждый вклад:

du -sh /var/log/nginx /var/log/app /var/log/mysql /var/log/journal 2>/dev/null | sort -h

Как ротация и сжатие меняют реальный расход диска

Сырой суточный объём — это не то, что реально лежит на диске через месяц. logrotate сжимает старые файлы (обычно gzip), и текстовые логи сжимаются заметно — но конкретный коэффициент зависит от структуры данных: у access-логов с повторяющимися полями (User-Agent, статус-коды, пути) он выше, у логов с уникальными строками (например, полными JSON-payload'ами с разными данными) — заметно ниже. Не берите чужую цифру за истину — проверьте на своих логах:

gzip -k -c /var/log/nginx/access.log.1 | wc -c
wc -c /var/log/nginx/access.log.1

Отношение этих двух чисел — ваш реальный коэффициент сжатия. Дальше в расчёте объёма на год используйте не «сырой» суточный прирост, а взвешенный: несколько дней (пока файл активен и не сжат) в исходном виде плюс всё, что старше — с поправкой на этот коэффициент.

Второй момент — сама ротация не освобождает место мгновенно и не всегда освобождает его вообще, если процесс продолжает писать в старый inode (классическая грабля: диск полон, а du по /var/log показывает свободное место). Для расчёта хранилища это важно: закладывайте не только конечный размер после сжатия, но и временный пик — период, когда несжатая копия ещё существует рядом со сжатой (это стандартное поведение logrotate с delaycompress, оно держит место занятым на одну ротацию дольше).

Пример конфига logrotate, который явно фиксирует и сжатие, и глубину хранения:

/var/log/app/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

rotate 14 здесь — не догма, а параметр, который должен быть результатом расчёта retention (см. дальше), а не значением по умолчанию из шаблона.

От суточного объёма к годовому прогнозу

Имея измеренную суточную скорость роста (после поправки на сжатие) и текущее понимание, растёт ли нагрузка на сервис, можно построить простую модель. Годовой прогноз — это не просто «суточный объём × 365», потому что почти в любом растущем проекте нагрузка не постоянна.

Базовая формула:

V(t) = V0 × (1 + r)^t

где V0 — суточный объём логов сегодня (после сжатия), r — ожидаемый темп роста нагрузки за период (месяц или квартал — выбирайте единицу, в которой у вас есть хоть какая-то оценка), t — число периодов до конца горизонта планирования.

Если у вас нет модели роста продукта — не выдумывайте её ради точности формулы. Возьмите три сценария и посчитайте диапазон:

Конкретные проценты роста в столбец «умеренный»/«агрессивный» подставляйте свои — это то, что реально знает только владелец продукта (маркетинговый план, план найма клиентов, сезонность). Наша задача — не подобрать красивое число, а показать инженеру, что даже без роста продукта логи за год — это не то же самое, что логи за месяц, умноженные на 12: сюда добавляются новые фичи, которые начинают логировать (интеграции, вебхуки, аудит), и это тоже вклад в r, который легко забыть.

Отдельно стоит учитывать, что при кратном росте продукта растут не только логи приложения, но и логи всей цепочки вокруг него — балансировщика, кэша, очереди сообщений, каждого прокси. Если это ваш случай, посмотрите разбор цены логирования и мониторинга при росте нагрузки в десять раз — там разобрано, какие компоненты логов растут непропорционально быстро.

Retention: что держать горячим, что уносить в холодное хранилище

Расчёт объёма без политики хранения бессмысленен: «хранить всё вечно» превращает любой прогноз в бесконечно растущую линию. Практичный подход — разделить логи по возрасту на несколько уровней с разной стоимостью хранения и доступностью:

• Горячий уровень (0-7 дней) — несжатые или свежесжатые логи на быстром диске сервера, к которым нужен мгновенный доступ при инциденте (grep, journalctl, поиск в реальном времени).
• Тёплый уровень (7-30/90 дней) — сжатые архивы, доступные локально, но редко читаемые. Живут на том же или на отдельном, более дешёвом разделе.
• Холодный уровень (от 90 дней до требуемого срока хранения) — объектное хранилище (S3-совместимое) или отдельный сервер с холодными дисками, куда логи уезжают по расписанию и откуда достаются только по запросу (расследование инцидента, юридический запрос, аудит).

Срок хранения на каждом уровне — не техническое решение, а результат ответа на два вопроса: как часто вам реально нужны логи такого возраста для дебага, и есть ли регуляторные требования хранить их дольше, чем нужно для дебага. Требования по типу данных (платёжные операции, доступ к персональным данным, VPN-подключения) сильно различаются, и их стоит уточнять отдельно, а не закладывать «на глаз».

Практическая проверка перед тем как закладывать долгий retention: посчитайте, сколько раз за последние полгода вы реально открывали лог старше месяца. Если ответ «ни разу» — это сильный аргумент за то, чтобы держать хранение таких логов на минимально возможном по регуляторике уровне, а не «на всякий случай»: логи, которые никто не читает, но за объём которых каждый месяц платят — частая и обидная ситуация на растущих проектах.

Считаем нужный объём диска: от прогноза к конкретным гигабайтам

Собираем всё вместе на примере. Пусть измеренный суточный объём (уже после сжатия) — 3 ГБ/сутки, из них горячий уровень держим 7 дней в исходном виде (в среднем чуть крупнее сжатого — закладываем ×2 на несжатую часть), тёплый — 30 дней сжатым, холодный — до требуемого срока (например, год) в объектном хранилище.

Горячий:  7  дней × 3 ГБ × 2 (несжато)  ≈ 42 ГБ на разделе сервера
Тёплый:   30 дней × 3 ГБ (сжато)         ≈ 90 ГБ на разделе сервера (или отдельном томе)
Холодный: 365 дней × 3 ГБ (сжато)        ≈ 1095 ГБ в объектном хранилище

Итого локально на сервере нужно закладывать под логи порядка 130-150 ГБ (горячий + тёплый, с запасом на пики и на temp-файлы logrotate во время самой ротации), а не терабайт — если холодный архив вынесен за пределы основного диска. Это принципиально меняет требования к разделу: держать всё локально на растущем проекте означает регулярно расширять диск, тогда как разделение уровней превращает задачу в «фиксированный объём под горячее + тёплое, всё остальное — в масштабируемое внешнее хранилище».

Отдельно заложите запас сверх расчётного значения — не впритык. Правило «занято не больше 70-80% раздела под логи» защищает от ситуации, когда всплеск логирования (инцидент, включённый debug на проде, DDoS с горой строк в access-логе) съедает оставшееся место быстрее, чем вы успеете среагировать. Подробнее про то, сколько дискового пространства закладывать с запасом и почему «впритык» — плохая идея, разобрано в статье сколько дискового пространства закладывать с запасом.

Если логи растут заметно быстрее остального сервера (типичная ситуация для приложений с частым debug-логированием или большим числом микросервисов), рассмотрите отдельный раздел или отдельный диск под /var/log — это изолирует риск: даже если логи неожиданно съедят весь выделенный им объём, это не остановит базу данных или веб-сервер, у которых кончится место на своём разделе.

Автоматизация: чтобы не проверять руками каждую неделю

Ручной пересчёт раз в квартал работает, пока кто-то не забудет его сделать. Минимальная автоматизация — это два элемента: сбор истории (уже описан выше через cron + du -sb) и алерт до того, как место закончится, а не после.

Простой алерт на процент занятости конкретного раздела с логами:

#!/usr/bin/env bash
THRESHOLD=80
USAGE=$(df --output=pcent /var/log | tail -1 | tr -dc '0-9')
if [ "$USAGE" -ge "$THRESHOLD" ]; then
    echo "Раздел /var/log занят на ${USAGE}%" | mail -s "Диск логов: предупреждение" ops@example.com
fi

Это защищает от резкого заполнения, но не от медленного вытеснения места логами месяцами — для этого полезнее алерт на аномальную скорость роста, а не только на текущий процент: если суточный прирост внезапно вырос в разы относительно вашего исторического ряда из growth-tracking.log, это сигнал раньше, чем диск реально заполнится.

Если у вас уже есть Prometheus/Grafana или аналог — выносите туда не только node_filesystem_* метрики раздела, но и производную метрику «прирост за последние 24 часа» по директории с логами: разовое число «занято 60%» ничего не говорит о скорости, с которой вы придёте к 100%. Настройку ротации логов, которая не даёт разделу переполниться в первую очередь, разбирали отдельно — в статье ротация логов, чтобы не забивался диск есть конкретные конфиги для logrotate и journald.

Частые вопросы