Стоимость хранения журналов событий дольше года

Год хранения журналов не равен 365 суточным объемам на дорогих дисках. Цена определяется тем, сколько данных приходит, во что они превращаются после индексации, сколько копий создает платформа и какая доля истории действительно должна отвечать на запрос за секунды.

Я видел сметы, в которых учитывали только сырой поток, а через несколько месяцев кластер упирался в диск. Видел и обратное: организация покупала быстрый массив под события, к которым обращалась раз в год. Нормальный расчет разделяет доступность, сохранность и скорость поиска. Тогда у каждой части истории появляется подходящий носитель, а у бюджета - проверяемая формула.

Сначала измерьте суточный поток, а не размер текущей папки

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

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

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

du -cb /var/log/export/2026-06-15/* | tail -1

Вывод имеет вид 318472901224 total: это байты файлов за выбранные сутки. Если данные лежат в объектном хранилище, суммируйте размер объектов по префиксу даты. Если платформа выставляет счет за принятые гигабайты, выгрузите суточное значение из ее метрик и сверьте хотя бы с одним независимым замером на коллекторе.

Не смешивайте GB и GiB. Производители дисков считают десятичными единицами: 1 TB равен 1 000 000 000 000 байт. Операционная система нередко показывает двоичные TiB, где 1 TiB равен 1 099 511 627 776 байт. Диск на 100 TB даст около 90,95 TiB до форматирования. Ошибка почти в десять процентов уже съедает заметную часть резерва.

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

Рабочая формула считает копии, рост и свободное место

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

Требуемая емкость = D × R × K × C × G / U

Здесь D - сырой объем в сутки, R - число дней, K - отношение размера на диске к сырому объему после разбора, индексации и сжатия, C - число полных копий данных, G - запас на рост, а U - допустимая доля заполнения дисков. Например, запас на рост 20% задается как G = 1,20, а предел заполнения 80% как U = 0,80.

Коэффициент C часто считают неверно. Одна основная и одна реплика означают две копии, то есть C = 2, а не единицу. RAID тоже не заменяет реплику поискового кластера и не заменяет резервную копию. RAID помогает пережить отказ носителя внутри узла, реплика поддерживает работу при потере узла, а резервная копия защищает от логического удаления, повреждения или ошибки администратора. Это разные отказы и разные строки сметы.

Свободное место нельзя считать роскошью. Документация Elasticsearch задает стандартные пороги заполнения: при 85% кластер ограничивает новое размещение шардов, при 90% начинает перемещать их, а при 95% блокирует запись в затронутые индексы. Даже если используется другая платформа, ей нужны место для слияний, временных файлов, восстановления и перебалансировки. Планировать рабочую систему на 95% заполнения означает заранее согласиться с аварийным режимом.

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

Сжатие измеряют на своих событиях

Фраза «логи сжимаются в пять раз» не годится для бюджета. Повторяющиеся текстовые строки действительно сжимаются хорошо, но UUID, хеши, шифрованные поля, трассировки и уже сжатые полезные нагрузки ведут себя иначе. Индекс добавляет словари, структуры поиска и значения полей; иногда индексированный набор занимает меньше сырого JSON, иногда больше.

Возьмите репрезентативный срез за три-семь дней, загрузите его с боевым шаблоном полей и дождитесь завершения фоновых слияний. Затем разделите фактический размер основных шардов на размер сырого входа. Повторите отдельно для крупных классов событий. Средневзвешенное значение станет K, а диапазон покажет риск.

Для Elasticsearch размер основных шардов можно проверить так:

GET _cat/indices/logs-*?h=index,pri,rep,docs.count,pri.store.size,store.size&s=index

Если сырой вход за тот же период равен 1,00 TB, pri.store.size равен 0,62 TB, а store.size с одной репликой равен 1,24 TB, то K = 0,62, C = 2. Не подставляйте в формулу 1,24 как коэффициент и затем еще раз две копии: так реплика посчитается дважды.

Документация Elastic для режима logsdb описывает best_compression на базе ZSTD для хранимых полей и специальные кодеки для числовых значений. Это полезная оптимизация, но не обещание конкретного процента. Более плотное сжатие также может повысить расход процессора при записи и чтении. Сравнивайте варианты на одинаковых запросах, одинаковом оборудовании и уже слитых сегментах.

У архива другая проверка. Сожмите суточные файлы выбранным форматом, запишите отношение архивного размера к сырому и измерьте время распаковки. Хранить миллионы крошечных объектов невыгодно: каталоги и API работают тяжелее, а некоторые архивные классы тарифицируют минимальный размер или метаданные на объект. Документация Amazon S3, например, указывает 40 KB дополнительных метаданных для каждого объекта в Glacier Flexible Retrieval и Deep Archive. Суточный или часовой пакет обычно практичнее файла на каждое событие.

Год быстрого поиска нужен редко

Требование «хранить год» обычно описывает срок сохранности, а не время ответа на произвольный запрос. Если аудитору достаточно получить выгрузку за несколько часов, держать весь год в поисковом кластере бессмысленно. Если аналитик расследует инцидент по событиям девятимесячной давности и должен строить корреляции сразу, холодный архив без поискового слоя не выполнит задачу.

Разделите сроки на три обещания. Горячий слой принимает запись и отвечает на частые запросы. Теплый слой хранит менее свежие индексы на более емких носителях, но остается доступным для поиска. Архив сохраняет исходные или нормализованные события, а перед анализом их нужно вернуть, подключить или обработать отдельным движком.

Граница проходит не по красивому числу дней, а по данным об использовании. Соберите за квартал возраст временного диапазона для каждого запроса и расследования. Если 96% интерактивных запросов касаются последних 30 дней, это веский довод держать месяц горячим. Остальные четыре процента еще не доказывают, что всю старую историю надо архивировать: возможно, часть таблиц нужна в теплом слое на 90 дней.

Microsoft в документации Azure Monitor прямо разделяет analytics retention и long-term retention. В долгосрочном режиме данные не имеют всех возможностей обычной таблицы, а для извлечения запускается поисковое задание. Полезен сам принцип: низкая цена хранения покупается за счет иного способа доступа. В собственной архитектуре это ограничение надо записать в SLA понятными словами.

Не переносите в архив единственную копию, пока не проверили цепочку восстановления. Архив без каталога, контрольных сумм, схемы полей и работающего инструмента импорта формально существует, но расследование из него не собрать.

Холодное хранилище меняет цену, а не отменяет расходы

Архив уменьшает стоимость носителя и часто снимает лицензирование поискового слоя со старых данных. Взамен появляются операции записи объектов, минимальный срок хранения, плата за чтение, запросы API, сетевой вывод, временная площадка для восстановления и труд администратора. Считать только цену одного GB в месяц опасно.

У архивных классов есть физическое следствие: данные возвращаются не мгновенно. Документация Amazon S3 указывает для Glacier Flexible Retrieval время от минут до 12 часов в зависимости от режима, а для Deep Archive - от 9 до 48 часов. Там же заданы минимальные сроки хранения 90 и 180 дней. Досрочное удаление или перевод объекта не всегда прекращает начисления сразу. Конкретные тарифы меняются по региону, поэтому в модели их следует хранить параметрами, а не вшивать в проект навсегда.

Годовая стоимость облачного архива считается так:

Хранение = сумма(средний GB за месяц × цена GB-месяца)
Извлечение = восстановленный GB × цена чтения
Операции = число запросов по типам × цена запроса
Передача = выведенный GB × цена передачи

В первый год объем растет постепенно. Если архив начинается пустым и ежедневно получает одинаковую порцию, средний занятый объем за год близок к половине объема на конец года. Во второй полный год при политике «храним последние 365 дней» архив уже держится около предельного объема. Смета, которая умножает конечные 30 TB на двенадцать месяцев для первого года, завышает хранение; смета, которая использует половину объема для каждого последующего года, занижает его.

Для локального архива посчитайте полезную емкость после RAID или erasure coding, запасные носители, серверы, полки, сетевые порты, электропитание, охлаждение, гарантийную замену и труд. Добавьте вторую площадку, если потеря одного здания не должна уничтожить журналы. Дешевый диск в прайс-листе не равен дешевой сохранности.

Срок назначают классу событий, а не всему потоку

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

Рабочая матрица может выглядеть так:

• Изменения учетных записей и прав: быстрый поиск 90 дней, полный срок 1-3 года по политике; после быстрого слоя остаются нормализованное событие и оригинал.
• События средств защиты: быстрый поиск 30-90 дней, полный срок один год; в архиве остаются поля расследования и исходная запись.
• Журналы приложений уровня info: быстрый поиск 14-30 дней, полный срок 90 дней; сохраняются только нужные сервисы или агрегаты.
• Подробная отладка: быстрый поиск 3-7 дней, полный срок 7-30 дней; после устранения дефекта архив обычно не нужен.
• Метрики здоровья: быстрый поиск 30 дней, полный срок один год; дальше достаточно часовых или суточных агрегатов.

Это пример проектной формы, а не готовая политика. Закон, договор, отраслевое правило или внутреннее расследование могут потребовать другой срок и неизменяемость. NIST SP 800-92 советует организации определить требования к хранению журналов в политике, а не оставлять их побочным эффектом настройки серверов. Я бы добавил: в политике должны быть указаны точка начала срока, допустимое время восстановления и лицо, которое разрешает удаление.

Фильтрация до записи дает самый большой выигрыш, но требует осторожности. Удаляйте доказанно бесполезный шум, например частые успешные проверки, если их отсутствие не ломает контроль доступности. Не выбрасывайте поля только потому, что сегодня по ним нет запроса. Идентификатор субъекта, точное время, источник, действие, результат и идентификатор корреляции часто становятся связующей нитью будущего расследования.

Агрегация подходит метрикам и повторяющимся техническим событиям, но не заменяет аудит. Суточное число неудачных входов не ответит, какая учетная запись, с какого адреса и в какое время проверялась. Сохраняйте агрегат для тренда, а исходные события - на срок, который нужен для расследования.

Пример расчета для потока 300 GB в сутки

Пусть коллекторы принимают 300 GB сырых событий в сутки. Пилот показал K = 0,65 для поискового индекса и K = 0,22 для архивных файлов. В поисковом слое есть одна реплика, значит C = 2. План предусматривает рост 20%, а диски должны оставаться заполненными не более чем на 80%.

Если держать весь год в одном поисковом слое, расчет такой:

300 × 365 × 0,65 × 2 × 1,20 / 0,80 = 213 525 GB

Нужно заказать около 213,5 TB полезной предоставленной емкости до учета системных данных, временного места для восстановления и резервных копий. На дисках, продаваемых в TB, это уже крупный массив. Снимок кластера следует считать отдельно: он может сжиматься и дедуплицироваться иначе, но его нельзя считать бесплатным.

Теперь оставим 30 дней в быстром слое, а предыдущие 335 дней отправим в архив. Для поиска потребуется:

300 × 30 × 0,65 × 2 × 1,20 / 0,80 = 17 550 GB

Объем архива на конец года без дополнительной прикладной копии:

300 × 335 × 0,22 × 1,20 = 26 532 GB

Итоговые 17,55 TB быстрого слоя и 26,53 TB архивного объекта нельзя складывать как равнозначные диски: у них разные цена, отказоустойчивость и скорость доступа. Но сравнение показывает, почему разделение слоев меняет проект. Вместо 213,5 TB емкости поискового кластера требуется меньше десятой части, а старая история хранится в более плотном виде.

Вариант с 90 днями быстрого поиска даст 52,65 TB предоставленной емкости. Архив для оставшихся 275 дней займет около 21,78 TB с теми же коэффициентами. Дополнительные 60 дней быстрого доступа стоят примерно 35,1 TB поискового слоя. Теперь владелец расследований может ответить, оправдана ли эта разница реальными запросами, а закупка получает не абстрактное «надо больше дисков», а цену конкретного SLA.

Проверьте модель еще двумя сценариями: рост потока на 50% и ухудшение K до верхней границы пилота. Если проект разваливается при одном новом источнике журналов, резерв выбран слишком оптимистично. Если даже неблагоприятный сценарий оставляет половину массива пустой, можно покупать емкость этапами.

Цена диска составляет лишь часть TCO

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

У поисковой платформы проверьте единицу лицензирования. Если продукт тарифицируется по принятому GB, архивирование после приема может не уменьшить плату за ingestion. Если лицензия зависит от узлов или ресурсов, переход старых данных на дешевый слой может сократить число дорогих узлов. Если оплачивается сканируемый объем запроса, редкие широкие поиски по архиву становятся отдельной переменной.

Для локального проекта сравнивайте варианты на одинаковом горизонте, обычно три-пять лет. Включите замену дисков, расширение полок, поддержку и стоимость капитала. Не приписывайте купленному массиву нулевую цену после первого года: он потребляет ресурсы и занимает место весь срок службы. Облачный вариант, напротив, не требует стартовой покупки, но платеж продолжается и зависит от роста, чтения и передачи.

В инфраструктурном проекте GSE.kz может связать расчет глубины хранения с конфигурацией серверов, дата-центра и программного слоя, не привязывая архитектуру к одному производителю. До обращения к интегратору все равно соберите D, K, требования к копиям и статистику возраста запросов: без них любой поставщик будет закладывать дорогой запас или гадать.

Отдельно оцените стоимость проверки. Архив, который никто не восстанавливал, дает ложную экономию. Ежеквартальное тестовое восстановление выбранного дня должно создавать проверяемый набор файлов, подтверждать контрольные суммы, поднимать схему и выполнять несколько заранее записанных запросов. В смете нужны временная емкость и рабочие часы на этот тест.

Неизменяемость требует отдельного расчета

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

Неизменяемость влияет на емкость. Ошибочно выгруженный пакет нельзя тихо перезаписать более компактной версией, а неверно выбранный долгий срок может запретить удаление уже ненужных данных. Сначала проверьте политику на отдельном контейнере и коротком интервале. Запишите, кто может включить удержание, кто может его продлить, возможна ли юридическая блокировка и что происходит с объектом после окончания срока. Эти ответы важнее названия функции у поставщика.

Microsoft в документации по экспорту Azure Monitor отмечает, что записи в Log Analytics нельзя изменить после приема, но их можно удалить процедурой purge; для защищенного от изменений хранения предлагается экспорт в учетную запись с политикой неизменяемости. Здесь хорошо видна разница между защитой содержимого внутри поисковой платформы и защитой от удаления всей записи. В собственной системе проверьте обе операции отдельно.

У каждого архивного пакета нужен небольшой манифест: источник, начало и конец интервала, число записей, размер, версия схемы и контрольная сумма. Контрольную сумму создают после окончательного сжатия и до передачи в архив. Простейшая проверка выглядит так:

sha256sum events-2026-06-15.json.zst > events-2026-06-15.sha256
sha256sum -c events-2026-06-15.sha256

Успешный вывод имеет вид events-2026-06-15.json.zst: OK. Сам файл контрольной суммы храните рядом с пакетом и включайте в защищенный каталог, иначе злоумышленник сможет заменить данные вместе с суммой. Для строгой доказательной процедуры могут понадобиться цифровая подпись, доверенная отметка времени и журнал доступа, но их требования должен определить владелец контроля, а не администратор дискового массива.

Шифрование архива добавляет еще одну зависимость. Данные, ключ и инструкция восстановления должны пережить один и тот же срок, однако их нельзя складывать в одно место с одинаковыми правами. При ротации ключей проверьте, можно ли прочитать старые объекты, и сохраните версию формата. Я встречал архивы, физически целые спустя годы, но бесполезные после удаления учетной записи службы или смены системы управления ключами.

Формат тоже входит в срок хранения. Открытый построчный JSON проще восстановить разными инструментами, но он занимает больше места и медленнее читается. Parquet плотнее хранит типизированные столбцы и удобен для выборочного анализа, зато требует сохранить схему и совместимый читатель. Выбор зависит от способа будущего поиска. Хорошая проверка состоит в том, что другая команда на чистой площадке читает пакет только по манифесту и инструкции, без устных подсказок автора архива.

Не включайте неизменяемость для каждого технического лога из осторожности. Она повышает счет и усложняет исправление ошибок классификации, а персональные или секретные данные могут получить конфликтующий срок удаления. Выберите классы, где защита от изменения действительно требуется, и считайте их отдельно. Тогда неизменяемый архив остается контролем, а не дорогой свалкой, которую никто не имеет права очистить.

Разумную границу задает время восстановления

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

Для большинства потоков стоит проверить базовый вариант: 30 дней быстрого поиска, 90 дней для наиболее нужных таблиц в теплом слое и остаток обязательного срока в архиве. Это не универсальная норма. Аудит привилегированных действий может заслуживать более длинного интерактивного окна, а подробная отладка - гораздо более короткого.

Закрепите решение тестом приемки. Выберите случайную дату старше быстрого слоя, восстановите один класс событий в изолированную площадку, проверьте количество записей и контрольные суммы, выполните запрос расследования, затем безопасно удалите временную копию. Измерьте часы и труд. Если результат нарушает SLA, двигайте границу или меняйте способ архивации; покупка еще одного года быстрых дисков остается самым дорогим способом избежать этого теста.

Пересчитывайте модель после подключения крупного источника, изменения схемы, коэффициента репликации или политики. Суточный объем и K удобно хранить как ежемесячный временной ряд. Тогда закупка емкости происходит до порога заполнения, а не после блокировки записи. Разумная граница проходит там, где восстановление еще укладывается в работу, а не там, где закончилась строка бюджета.