Сообщить об ошибкеКороткий ответ
Единой правильной политики retention нет — она должна балансировать юридические/compliance-требования (например, обязательное хранение логов доступа N месяцев в некоторых отраслях), реальную частоту использования старых данных при расследованиях (как правило, резко падает после нескольких недель) и стоимость хранения; типичный подход — многоуровневое хранение с downsampling и разными retention для разных типов данных, а не единый срок для всего.
Как это работает подробнее
"горячий" слой (недавние raw-данные, дни–недели) оптимизирован под быстрый детальный запрос при активном расследовании; "тёплый" слой (downsampled метрики, сжатые логи, недели–месяцы) используется для анализа трендов и редких повторных расследований; "холодный" архив (объектное хранилище, месяцы–годы) используется почти исключительно для compliance-аудита и крайне редко читается напрямую, поэтому может иметь высокую latency доступа в обмен на низкую стоимость.
Компромисс: более долгое и детальное хранение увеличивает стоимость инфраструктуры и усложняет compliance (больше данных — больше поверхность риска утечки), но даёт больше возможностей для анализа долгосрочных трендов и редких повторяющихся инцидентов; агрессивный downsampling и короткий retention снижают стоимость и риск, но могут не дать нужной детализации при расследовании инцидента, произошедшего несколько месяцев назад. Конкретные сроки и уровни детализации должны определяться совместно инженерной командой, юридическим отделом и владельцами продукта с учётом отраслевых требований, а не выбираться произвольно.
Пример кода
Метрики: raw (15s) — 15 дней; downsampled 5m — 13 месяцев; downsampled 1h — 5 лет (compliance)
Логи: полнотекстовые — 30 дней; агрегированные счётчики ошибок — 13 месяцев
Трейсы: 100% sampling — 7 дней; 10% sampling (для долгосрочных трендов) — 90 днейЧто использовать на практике
- Практика. важно разделять retention-требования по типу данных и по чувствительности — логи с персональными данными могут требовать более короткого хранения и шифрования из соображений privacy (GDPR и аналоги), тогда как агрегированные метрики без персональных данных можно хранить дольше без тех же ограничений. Нужно явно согласовать политику с юридическим/compliance отделом, а не определять retention только из инженерных соображений стоимости.
- Практика. Такая многоуровневая схема позволяет детально расследовать инцидент текущей недели с полной точностью, анализировать тренды за год по агрегированным данным и соблюдать требование compliance-архива на 5 лет без необходимости хранить весь объём raw-данных все 5 лет, что было бы кратно дороже.
Подводные камни
- Частые ошибки. устанавливать единый retention "для простоты" одинаково для всех типов данных, что либо избыточно дорого для малозначимых технических логов, либо недостаточно для compliance-критичных данных; не учитывать, что raw high-cardinality данные (трейсы, детальные логи) растут в объёме кратно быстрее агрегированных метрик, и единая политика "храним всё 13 месяцев" может быть финансово нежизнеспособной именно для них; не тестировать процесс восстановления/чтения данных из холодного архива до того, как он реально понадобится при аудите.