Как выбрать политику хранения и ретенции данных в системе мониторинга: практическая схема

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

Начните с разделения данных по типам и ценности. Оставьте свежие метрики, логи и события в быстром hot storage, перенесите менее востребованные данные в warm storage, а историю для аудита и редких расследований отправьте в cold storage или архив. После этого рассчитайте объем, учтите репликацию и индексацию, настройте автоматическое удаление по TTL и проверьте схему на тестовом расследовании.

Срок хранения не должен быть одинаковым для всех сервисов. Production, критичные API, платежные компоненты, Kubernetes-кластеры, временные тестовые окружения и debug-логи требуют разных правил. Политика работает, когда она документирована, автоматизирована и регулярно проверяется по фактическим инцидентам.

Короткий ответ: выбирайте ретенцию по сценарию расследования, а не одним сроком для всех данных

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

Практичная схема состоит из четырех шагов:

1. Перечислите типы данных: метрики, логи, трейсы, события деплоя, изменения конфигурации, алерты, audit- и security-записи.
2. Свяжите каждый тип со сценариями: дежурство, расследование, постмортем, аудит, анализ долгосрочных трендов.
3. Назначьте периоды hot, warm и cold storage с отдельными требованиями к скорости поиска и детализации.
4. Проверьте расчет объема, доступность архива, автоматическое удаление и возможность восстановления.

Базовая модель: горячие, теплые и холодные данные

Hot storage хранит информацию, по которой инженеры регулярно строят интерактивные запросы. Сюда обычно попадают метрики с исходным разрешением, недавние application- и system-логи, алерты, события деплоя и изменения конфигурации. Для hot-слоя важны низкая задержка чтения, быстрые фильтры, полные индексы и достаточный запас IOPS.

Warm storage подходит для данных, которые нужны раз в несколько дней или недель. Метрики здесь часто хранятся после downsampling, например с агрегированием по 1 или 5 минутам. Логи могут быть сжаты, иметь ограниченный набор индексов или храниться в формате, который требует более долгого запроса.

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

Пять вопросов перед выбором срока хранения

1. Какой самый долгий инцидент приходится расследовать? Учтите задержку между появлением симптомов, обнаружением проблемы и началом анализа.
2. Какие данные нужны для постмортема? Обычно это метрики, логи ошибок, алерты, события релиза, изменения конфигурации и история состояния зависимостей.
3. Как быстро их нужно получить? Для дежурного инженера допустим ответ за секунды, для аудита может подойти пакетная выгрузка из архива.
4. Есть ли внутренние или отраслевые требования? Отдельно зафиксируйте сроки для audit- и security-данных, правила доступа, неизменяемость и порядок удаления.
5. Какой бюджет доступен на хранение? В расчет входят диски, объектное хранилище, реплики, индексы, сетевой трафик, compaction, резерв свободного места и восстановление.

Ответы удобно свести в матрицу. Например, если расследование регрессий занимает до 30 дней, а постмортем закрывается в течение 14 дней, то метрики с исходной детализацией могут оставаться в hot storage 14-30 дней, затем переходить в агрегированный warm-слой. Точный срок зависит от фактической нагрузки и истории инцидентов.

Разделите данные: метрики, логи и события требуют разных правил

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

Хранение метрик в мониторинге

Объем метрик зависит не только от числа серверов. Основной фактор роста, количество активных временных рядов. Каждый уникальный набор имени метрики и labels создает отдельную series. Метка с pod UID, request ID, IP клиента, хешем сессии или случайным идентификатором быстро увеличивает кардинальность.

При scrape interval 15 секунд одна series дает 5 760 samples в сутки. Для 50 000 активных series это 288 миллионов samples за день. Размер на диске зависит от сжатия, формата блоков, индекса и репликации, поэтому оценивать его нужно на тестовом наборе данных, а не по размеру одного sample в памяти.

Сырые ряды полезны при поиске коротких пиков latency, burst-нагрузки и проблем после изменения конфигурации. Для долгосрочного анализа часто хватает агрегатов: среднего значения, максимума, p95 или p99 latency, error rate, utilization и saturation. Recording rules и downsampling сокращают потребление хранилища, но снижают детализацию. До удаления исходных рядов проверьте, что агрегаты отвечают на вопросы из постмортемов и SLO-отчетов.

Метрики CPU, памяти, диска, сети, latency и ошибок удобно сопоставлять с историей сервиса. Практику поиска устойчивой деградации и кратких пиков подробно дополняет руководство по поиску узких мест в системе.

Логи приложений, систем и контейнеров

Логи нужно разделять минимум на access, error, debug, audit и security. Access-логи полезны для анализа трафика и кодов ответа, но могут давать большой поток однотипных записей. Error-логи и stack trace обычно нужны дольше, поскольку помогают расследовать редкие сбои. Debug-логи быстро растут в объеме и подходят для короткого hot-периода, особенно в production.

Полнотекстовый индекс для каждого поля резко увеличивает стоимость. Structured logs позволяют индексировать ограниченный набор полей: timestamp, service, environment, severity, request path, error code, trace ID и tenant, если этот идентификатор не создает избыточную кардинальность. Остальную полезную нагрузку можно оставить доступной для просмотра без отдельного индекса.

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

События, алерты и изменения состояния

События редко занимают много места, но часто объясняют причину инцидента. Храните историю деплоев, рестартов, масштабирования, изменения конфигурации, смены secret или certificate, открытия и закрытия алертов, изменения статуса узла и результата автоматических действий.

Во время расследования временная шкала должна отвечать на простые вопросы: какой релиз вышел перед ростом ошибок, кто изменил лимит памяти, когда pod начал перезапускаться, какой алерт сработал первым, отключался ли dependency. Если события удаляются раньше метрик и логов, связь между симптомом и изменением теряется.

Для большинства команд разумно держать события и историю алертов дольше сырых debug-логов. Объем обычно позволяет это сделать. Раздельный маршрут для audit- и security-событий защищает их от общего TTL логового индекса.

Ретенция не заменяет резервное копирование

Retention policy управляет сроком доступности данных в рабочем хранилище. По истечении TTL система удаляет блоки, индексы или объекты. Резервная копия нужна для восстановления после повреждения, ошибочного удаления, сбоя хранилища, компрометации учетной записи или неудачного обновления.

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

Схему копий вне основной площадки, проверку RPO и RTO, а также защиту от удаления можно взять за основу в материале про удаленное резервное копирование.

Определите сроки хранения по эксплуатационным сценариям

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

Оперативное устранение текущих проблем

Во время инцидента инженер обычно строит запросы за последние минуты, часы и дни. Нужны сырые метрики с исходным разрешением, свежие error-логи, текущие события Kubernetes, состояние очередей, история алертов и сведения о последних изменениях.

Для hot storage заранее задайте SLO на поиск. Например, запрос метрик за 24 часа должен завершаться за несколько секунд при типичной параллельной нагрузке, а фильтр логов по сервису, severity и временному диапазону не должен требовать восстановления архива. Фактические целевые значения зависят от дежурной модели и числа пользователей.

Расследование инцидентов с отложенным обнаружением

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

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

Постмортемы и анализ изменений

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

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

Аудит, безопасность и внутренние требования

Audit- и security-данные хранят по отдельным правилам. Техническая потребность в логах за 30 дней не отменяет внутреннюю политику компании, договорные обязательства или требования отрасли. Универсальный юридический срок указывать нельзя: он зависит от юрисдикции, типа организации и категории информации.

Для таких данных определите владельца, срок, уровень доступа, формат архива, порядок экспорта, допустимость изменения и процедуру удаления. Доступ к архиву нужно журналировать. Если запись служит подтверждением действия, проверьте потребность в версионировании, object lock или WORM-режиме.

Постройте многоуровневую схему хранения и архивирования данных мониторинга

Многоуровневое хранение помогает сохранить быстрый доступ к свежей информации и не держать всю историю в дорогом индексе. Жизненный цикл должен быть автоматическим: данные собираются в hot storage, уплотняются или агрегируются, переходят в warm-слой, затем архивируются или удаляются по TTL.

Hot storage для текущей диагностики

В hot storage держите данные, которые нужны при активном инциденте: метрики с исходным разрешением, актуальные application- и system-логи, важные трейсы, алерты, события деплоя и историю изменений конфигурации. Подготовьте индексы по времени, сервису, окружению, severity, namespace и другим стабильным полям.

Размер hot-слоя ограничивают не только диски. Долгая ретенция увеличивает compaction, объем индексов, потребление памяти, нагрузку на дисковую подсистему и время запросов по длинному диапазону. Оценивайте одновременно ingest rate, latency запросов и свободное место.

Warm storage для регулярного анализа

Warm storage хранит информацию, которую команда использует реже, но хочет получать без полноценного восстановления архива. Сюда подходят агрегированные метрики по 1, 5 или 60 минутам, сжатые логи ошибок, итоговые события релизов и данные для регулярных отчетов.

На этом уровне допустимы компромиссы: меньше индексов, более редкие блоки, ограниченный полнотекстовый поиск, более низкая скорость выдачи. Перед переносом логов проверьте, сохраняются ли timestamp, service, environment, severity, trace ID, идентификатор инцидента и поля, нужные для расследования.

Cold storage и долгосрочный архив

Cold storage подходит для редких расследований, аудита и исторических трендов. Часто для него используют объектное хранилище с lifecycle-политиками, отдельные архивные индексы или выгрузки в сжатом формате. Архив не должен быть единственным источником для оперативного реагирования.

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

Правила перехода между уровнями

Для каждого перехода зафиксируйте возраст данных, тип потока, формат, степень агрегации, шифрование, права доступа и проверку целостности. Полезно учитывать среду и критичность сервиса: production-логи ошибок могут жить в warm storage дольше, чем аналогичные записи из development.

metrics_raw: hot, 21d
metrics_5m: warm, 180d
application_error_logs: hot, 14d
application_error_logs_archive: cold, 180d
debug_logs: hot, 3d
audit_events: protected_archive, срок по внутренней политике

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

Рассчитайте объем, стоимость и нагрузку перед запуском политики

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

Что учитывать в расчете объема

Базовая модель для любого потока выглядит так:

итоговый_объем = входящий_поток × срок_хранения × коэффициент_репликации × накладные_расходы

Накладные расходы включают индексы, WAL или журнал записи, служебные метаданные, временные файлы compaction, свободный резерв и возможный дублирующий поток в архив. Коэффициент сжатия нельзя брать из рекламных оценок: измерьте его на данных, близких к production, с реальными labels, размером логов и частотой запросов.

В Kubernetes учтите короткоживущие pod-ы, jobs, namespaces, динамические labels и частую смену endpoint-ов. Временный объект может исчезнуть через несколько минут, но созданные им series и индексные записи будут занимать место до очистки блока.

Кардинальность и детализация метрик

Для метрик полезно считать отдельно число активных series и количество samples. Формула для грубой оценки:

samples_в_сутки = active_series × 86400 / scrape_interval_в_секундах

При 100 000 active series и интервале 15 секунд система принимает 576 миллионов samples в сутки. Увеличение интервала до 30 секунд вдвое сократит поток samples, но может скрыть короткие всплески latency или saturation. Решение принимайте по требованиям диагностики, а не только по объему.

Контролируйте labels с высокой изменчивостью. В большинстве случаев полезно удалять из метрик request ID, user ID, случайные токены, полные URL с параметрами и pod UID. Для анализа запросов используйте логи или трейсы, а в метриках сохраняйте стабильные категории.

Уровень логирования и стоимость индексации

Логи оценивают по числу событий и среднему размеру записи. Например, поток 20 000 событий в секунду со средним размером 700 байт дает около 1,21 ТБ сырых данных за сутки до сжатия, индексов и реплик. При двух копиях и крупном полнотекстовом индексе реальный расход может оказаться значительно выше.

Structured logs снижают стоимость поиска, если индексировать только нужные поля. Для debug-потоков используйте короткий TTL, sampling или отдельный маршрут. В production не включайте подробный debug-режим бессрочно: это повышает стоимость и увеличивает риск записи чувствительных данных.

Нагрузка на запись и чтение

Проверьте ingest rate, задержку записи, число активных ingest-воркеров, очередь, ошибки compaction, время выполнения запросов и параллельную нагрузку пользователей. Запрос за 30 дней по высококардинальной метрике способен затронуть большое число блоков и ухудшить работу дежурного инженера, который в этот момент ищет причину аварии.

Для каждого слоя задайте измеримые цели. Пример: свежие метрики за 24 часа открываются быстрее 10 секунд, поиск error-логов за 7 дней укладывается в 30 секунд, выгрузка объекта из архива занимает не более согласованного RTO. Точные числа зависят от платформы, бюджета и критичности сервисов.

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

Сформируйте отдельные политики для production, тестовых сред и критичных сервисов

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

Production и критичные сервисы

Для production сохраняйте подробные инфраструктурные и application-метрики, error-логи, события деплоя, историю изменений конфигурации, алерты и нужные audit-записи. Сервис относят к критичным по согласованию с владельцем, связи с бизнес-SLO, влиянию на клиентов и последствиям отказа.

Критичный сервис не всегда требует долгого хранения всех логов. Например, access-логи можно агрегировать или сжимать, а error- и security-события сохранять дольше и в более защищенном маршруте. Такой подход снижает расходы без потери материалов для расследования.

Staging, development и временные окружения

Для staging и development обычно достаточно короткого hot-периода, уменьшенного разрешения метрик и ограниченного debug-логирования. Временное окружение должно удалять свои данные после завершения работы, иначе старые namespace и jobs постепенно заполнят хранилище.

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

Политики по важности данных

Исключения и временное продление ретенции

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

Исключение не должно становиться бессрочным. После закрытия расследования данные возвращаются в обычный lifecycle или переносятся в архив с заранее определенным сроком.

Автоматизируйте политику хранения в инструментах мониторинга

Ручное перемещение данных и разовые чистки диска плохо масштабируются. Политику задают через retention settings, lifecycle rules, маршрутизацию потоков, recording rules, downsampling, bucket policies и конфигурацию архивного слоя.

Метрики: исходные ряды, recording rules и downsampling

Сначала определите запросы, которые будут нужны после удаления сырых рядов. Для SLO часто требуются готовые агрегаты error rate, availability, latency percentiles, utilization и saturation. Recording rules рассчитывают их заранее и избавляют от тяжелых запросов по огромному числу series.

raw_series_ttl: 21d
recording_rules_ttl: 180d
downsampling:
  after: 21d
  resolution: 5m

После downsampling проверьте точность. Среднее значение CPU за 5 минут может скрыть краткий пик, а усредненная latency не заменяет p99. Для каждой метрики зафиксируйте допустимую потерю детализации и назначение агрегата.

Логи: маршрутизация, sampling и lifecycle-политики

Маршрутизируйте логи по namespace, сервису, окружению, severity и типу данных. Production error-логи можно направлять в индекс с более долгим сроком, debug-потоки в короткий hot storage, audit-события в защищенный архив. Для шумных сообщений используйте sampling, дедупликацию или счетчики в метриках.

route: production.error
hot_ttl: 14d
archive_ttl: 180d
index_fields: timestamp, service, environment, severity, trace_id

route: production.debug
hot_ttl: 3d
sampling: enabled

Перед включением sampling убедитесь, что он не удаляет редкие ошибки. Хорошее правило: не сэмплировать события с severity error и выше, ошибки аутентификации, изменения прав, события безопасности и записи, связанные с активным инцидентом.

События и аудит: отдельное защищенное хранилище

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

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

Политика как код и контроль версий

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

Шаблон новой политики должен включать тип данных, сервис, окружение, владельца, hot TTL, warm TTL, cold TTL, метод агрегации, правила доступа и дату следующего пересмотра. Автоматические проверки могут искать конфликтующие TTL, отсутствие архива у audit-потока и неограниченный срок у высокообъемных debug-логов.

Учтите безопасность, надежность и требования к удалению данных

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

Контроль доступа к горячему хранилищу и архиву

Разделите роли для просмотра метрик, чтения application-логов, доступа к security- и audit-данным, выгрузки объектов и восстановления архива. Инженер, который ищет ошибку в сервисе, не всегда должен видеть логи другого окружения, персональные сведения или историю действий администраторов.

Используйте отдельные учетные записи для сервисов записи, операторов и автоматических задач lifecycle. Журналируйте экспорт, изменение правил хранения, удаление объектов и восстановление из архива. Шифруйте данные при передаче и хранении, если это требуется политикой безопасности.

Целостность и неизменяемость архивных данных

Архив, который нельзя прочитать или которому нельзя доверять, не решает задачу аудита. Проверяйте контрольные суммы, размер объектов, версии, дату записи и соответствие каталогу. Для чувствительных потоков применяйте раздельные права на запись и удаление, а при необходимости используйте WORM-режим, где объект записывается один раз и затем доступен только для чтения.

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

Чувствительные данные в логах

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

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

Проверьте политику на реальном расследовании и пересматривайте ее при росте системы

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

Тестовое расследование по временной шкале

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

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

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

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

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

Мониторинг самой политики ретенции

Мониторинг должен контролировать собственное хранилище. Добавьте метрики объема, ingest rate, свободного места, возраста самых старых доступных данных, количества active series, ошибок compaction, задержки архивирования, ошибок lifecycle и неудачных восстановлений.

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

Чек-лист перед утверждением политики

• Для каждого типа данных назначен владелец.
• Описаны сценарии дежурства, расследования, постмортема и аудита.
• Отдельно заданы hot, warm и cold storage.
• Сырые метрики, агрегаты, логи, трейсы, события и audit-записи имеют разные сроки.
• Рассчитаны входящий поток, кардинальность, индексы, реплики, compaction и резерв места.
• Настроены TTL, lifecycle rules, маршрутизация и автоматическое удаление.
• Ретенция не подменяет резервное копирование.
• Проверены права доступа, шифрование, журналирование и защита архива.
• Пройдено тестовое расследование по временной шкале.
• Проверено восстановление данных из архива.
• Добавлены метрики и алерты для контроля самой политики.
• Указана дата следующего пересмотра после роста инфраструктуры или крупного инцидента.

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