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

Короткий ответ

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

Как это работает подробнее

метрики обычно дешевы в хранении в агрегированном виде и могут держаться месяцами/годами, логи и особенно трейсы с высокой кардинальностью стоят значительно дороже при длительном хранении, что толкает команды к короткой ретенции (несколько дней); но инциденты часто обнаруживаются не сразу (дни), а полноценное расследование с постмортемом может начаться ещё позже — рассинхронизация между "когда нужны детальные данные" и "когда они физически ещё существуют" создаёт именно описанную проблему.

Компромисс: более долгая ретенция или staged downsampling снижает риск потери данных для расследования, но увеличивает затраты на хранение и, для логов/трейсов с персональными данными, может увеличивать риски соответствия требованиям (compliance); решение должно явно учитывать профиль инцидентов организации (как часто расследования начинаются спустя дни/недели), бюджет на observability-инфраструктуру и требования по хранению персональных данных, а не выбираться по умолчанию.

Пример / кейс

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

Пример кода

example.txtКопировать

Текущая ретенция: метрики — 13 месяцев, логи — 7 дней, трейсы — 3 дня.
Инцидент обнаружен на 5-й день после события (через жалобы пользователей) — трейсы уже удалены.
Предложение: логи/трейсы критичных сервисов — 30 дней; механизм "freeze" логов/трейсов
при создании инцидент-тикета с переносом в отдельное долгосрочное хранилище на 1 год.

Что использовать на практике

• Практический подход. Нужно явно сопоставить тип данных, стоимость хранения и типичное время до обнаружения+расследования инцидента в конкретной организации, и либо увеличить базовую ретенцию для дорогих данных выборочно (например, только для критичных сервисов), либо реализовать механизм экспорта/заморозки "интересных" данных в долгосрочное хранилище сразу при объявлении инцидента (до того как сработает стандартная очистка). Также стоит рассмотреть снижение детализации со временем (downsampling) вместо полного удаления — грубые агрегаты дольше, детальные данные короче.

Подводные камни

• Частые ошибки. Устанавливать одинаковую короткую ретенцию для всех типов телеметрии без учёта разницы в стоимости и ценности; не иметь процесса экстренного сохранения данных конкретного инцидента при его обнаружении, из-за чего стандартная очистка удаляет нужные данные посреди расследования; оптимизировать ретенцию только по стоимости хранения, не оценивая стоимость неполного расследования повторяющихся инцидентов.