Логи – это «жизненный журнал» любой системы. При росте нагрузки их объём может достигать десятков и даже сотен гигабайт, что создаёт серьёзные проблемы: нехватка места, замедление поиска, риск потери данных. В этой статье мы разберём, почему важно архивировать большие логи, какие подходы существуют, и как реализовать надёжную схему архивирования с помощью готовых утилит (logrotate), скриптов и современных централизованных систем (ELK, Loki, ClickHouse).

Содержание

1. Зачем архивировать большие логи
2. Типичные проблемы при работе с большими логами
3. Базовый подход: logrotate
4. Скриптовое архивирование (bash, find, gzip)
5. Централизованные решения (ELK, Loki, ClickHouse)
6. Политика хранения и очистки
7. Мониторинг и оповещение о переполнении
8. Безопасность и целостность архивов

Почему важно архивировать большие логи

• Экономия дискового пространства. Без ротации и сжатия один‑дневный лог может занимать несколько гигабайт.
• Скорость анализа. Поиск по огромному файлу (grep, awk) становится медленным; архивы позволяют работать только с нужным диапазоном дат.
• Надёжность. При переполнении диска система может выйти из строя, а логи, которые нужны для расследования инцидентов, будут утеряны.
• Соответствие требованиям. Многие регуляторы (PCI‑DSS, GDPR) требуют хранить логи определённый срок и гарантировать их неизменность.

Типичные проблемы при работе с большими логами

С ростом объёма логов возникают следующие сложности:

1. Фрагментация файловой системы. Постоянное создание новых файлов приводит к разбросу данных.
2. Отсутствие единообразного формата. Разные приложения пишут в разные форматы (plain‑text, JSON, CSV).
3. Недостаток автоматизации. Ручные операции (перемещение, сжатие) легко забыть.
4. Сложности с ретеншном. Нужно хранить логи N дней, но автоматически удалять более старые.
5. Скорость записи. При попытке «копировать‑truncate» может возникнуть потеря записей, если приложение не закрывает файл.

Базовый подход: logrotate

Для большинства Linux‑серверов logrotate – это «де‑факто» решение. Оно умеет:

• Ротацию по времени (daily, weekly, monthly) и по размеру (size 100M).
• Перемещение старых файлов в отдельный каталог (olddir).
• Сжатие (compress, delaycompress).
• Ограничение количества хранимых копий (rotate N).
• Работу с приложениями, которые не закрывают файл (copytruncate).

Пример конфигурации для логов вида yyyy_mm_dd_name.log

/var/log/*name.log {
 daily # каждый день создаём новый файл
 missingok # если файл отсутствует – не ругаться
 rotate 30 # хранить 30 последних архивов (≈ месяц)
 compress # gzip‑сжатие
 delaycompress # первый архив оставляем без сжатия (быстрее доступ)
 olddir /var/log/archive # перемещать в отдельный каталог
 dateext # добавлять дату к имени архива
 dateformat -%Y_%m_%d # формат даты, совпадающий с именем файлов
 notifempty # не ротировать пустые файлы
 create 0640 root adm # создавать новый пустой файл с правами
 sharedscripts
 postrotate
 # При необходимости посылаем сигнал приложению
 # kill -USR1 $(cat /var/run/myapp.pid) ->/dev/null || true
 endscript
}

Эта конфигурация решает большинство задач, описанных в Stack Overflow: файлы старше вчера автоматически перемещаются в /var/log/archive, сжимаются и удаляются после 30‑ти дней.

Скриптовое архивирование (bash, find, gzip)

Если по тем или иным причинам logrotate нельзя использовать (например, требуется более гибкая фильтрация), можно написать собственный скрипт.

Шаг 1. Выбор файлов

# Выбираем файлы вида yyyy_mm_dd_name.log, старше вчера
find /var/log -maxdepth 1 -type f 
 -regextype posix-extended 
 -regex "./[0-9]{4}_[0-9]{2}_[0-9]{2}_[^_]+.log" 
 ! -regex "./$(date +%Y_%m_%d)_[^_]+.log" 
 ! -regex ".*/$(date -d 'yesterday' +%Y_%m_%d)_[^_]+.log"

Шаг 2. Перемещение и сжатие

# Папка назначения
ARCHIVE_DIR="/var/log/archive"
mkdir -p "$ARCHIVE_DIR"

find /var/log -maxdepth 1 -type f 
 -regextype posix-extended 
 -regex "./[0-9]{4}_[0-9]{2}_[0-9]{2}_[^_]+.log" 
 ! -regex "./$(date +%Y_%m_%d)_[^_]+.log" 
 ! -regex ".*/$(date -d 'yesterday' +%Y_%m_%d)_[^_]+.log" 
 -exec mv {} "$ARCHIVE_DIR" ; 
 -exec gzip "{}.log" ;

Для больших объёмов удобно использовать pigz (многопоточный gzip) вместо обычного gzip:

... -exec pigz -p 4 "{}" ;

Шаг 3. Планирование

Скрипт сохраняем, например, в /usr/local/sbin/archive_logs.sh, делаем исполняемым и добавляем в crontab:

0 2 * * * /usr/local/sbin/archive_logs.sh >> /var/log/archive_logs.log 2>&1

Запуск в 2 чутка ночи гарантирует, что большинство процессов уже завершили запись в текущий лог.

Централизованные решения (ELK, Loki, ClickHouse)

Для действительно «больших» систем (сотни серверов, десятки ТБ логов) локальная ротация уже не решает задачу. Нужно собрать логи в одно место, где их можно быстро искать и анализировать.

5.1 ELK‑стек (Elasticsearch + Logstash + Kibana)

• Logstash – собирает логи из файлов, syslog, Docker, Kafka и передаёт в Elasticsearch.
• Elasticsearch – хранит данные в распределённом индексе, поддерживает TTL (time‑to‑live) и автоматическое удаление старых шардов.
• Kibana – визуализация, построение дашбордов, поиск по запросам Lucene.

Плюсы:

• Масштабируемость линейная → логарифмическая при добавлении нод.
• Мощный поиск и агрегации.
• Поддержка JSON‑логов, структурированных данных;

Минусы:

• Требует отдельных ресурсов (CPU, RAM, SSD).
• Сложнее в настройке и обслуживании.

5.2 Loki + Grafana

Loki – «лог‑хранилище от Grafana Labs», ориентировано на хранение «неструктурированных» логов с небольшими метаданными. Отличается тем, что не индексирует каждую строку, а использует метки (labels), что экономит место.

Идеально подходит для:

• Контейнерных окружений (Docker, Kubernetes).
• Сценариев, где нужен быстрый просмотр, но не глубокий анализ.

5.3 ClickHouse

Колонковая СУБД, часто используется для «лог‑аналитики» в реальном времени. Позволяет хранить терабайты строк и выполнять запросы за секунды.

Типичный пайплайн:

tail -F /var/log/app/*.log | 
 clickhouse-client --query="INSERT INTO logs FORMAT JSONEachRow"

Выбор решения

Политика хранения и очистки

Независимо от выбранного инструмента, необходимо формализовать политику ретеншна.

• Краткосрочное хранение (Hot tier). Последние 7‑14 дней – быстрый доступ, не сжатый.
• Среднесрочное (Warm tier). 30‑90 дней – сжатие gzip, хранение на менее дорогих SSD.
• Долгосрочное (Cold tier). >90 дней – архив в объектном хранилище (S3, MinIO) с высокой степенью сжатия (zstd, lz4).

Для logrotate это реализуется опциями rotate и compress. Для ELK – index.lifecycle политики. Для Loki – retention_period в конфиге.

Мониторинг и оповещение о переполнении

Автоматическое архивирование не спасёт, если система не знает, что место заканчивается.

7.1 Метрики

• node_filesystem_avail_bytes (Prometheus) – свободное место на диске.
• logrotate_last_success – кастомный экспортёр, фиксирующий время последнего успешного запуска.
• logstash_queue_size – размер очереди, если она растёт – значит лог‑источник генерирует больше, чем система успевает обработать.

7.2 Оповещения

# Пример правила Alertmanager
- alert: DiskSpaceLow
 expr: node_filesystem_avail_bytes{mountpoint="/var/log"} < 5 * 1024 * 1024 * 1024
 for: 5m
 labels:
 severity: critical
 annotations:
 description: "Осталось менее 5 ГБ свободного места. Проверьте архивирование логов."

Для Windows‑систем аналогично можно использовать Performance Monitor + Task Scheduler.

Безопасность и целостность архивов

• Контроль доступа. Доступ к /var/log/archive должен иметь только root и группы adm, logread.
• Подпись и хеш. При архивировании генерируем SHA‑256 хеш и сохраняем в отдельный файл filename.log.sha256. Позволяет проверять целостность позже.
• Шифрование. Если логи содержат персональные данные, используем gpg --symmetric или openssl enc -aes-256-cbc перед загрузкой в облако.
• Аудит доступа. Включаем аудит (auditd) для операций mv, gzip в каталоге логов.

Пример создания хеша и подписи

gzip -c "$FILE" > "$ARCHIVE_DIR/${FILE##/}.gz"
sha256sum "$ARCHIVE_DIR/${FILE##/}.gz" > "$ARCHIVE_DIR/${FILE##/}.gz.sha256"
gpg --symmetric --cipher-algo AES256 "$ARCHIVE_DIR/${FILE##/}.gz"

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

1. Для небольших и средних систем используйте logrotate с опциями daily, compress, olddir и rotate N.
2. Если требуется более гибкая фильтрация (по дате в имени файла), пишите простой bash‑скрипт с find и gzip/pigz, планируйте его в cron.
3. Для крупных распределённых сред переходите к централизованным системам (ELK, Loki, ClickHouse) и задавайте политики жизненного цикла индексов.
4. Определите уровни хранения (hot/warm/cold) и автоматизируйте перемещение в объектное хранилище.
5. Настройте мониторинг свободного места и оповещения, чтобы избежать «поломки» из‑за переполнения диска.
6. Не забывайте о безопасности: ограничьте доступ, подпишите архивы и, при необходимости, зашифруйте их.

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