Как снизить стоимость логов и метрик и не нарушить требования регуляторов

Речь пойдет про опыт работы с Grafana Cloud, но многие идеи можно применить и в других инструментах.

Рано или поздно почти любая инфраструктура упирается в стоимость observability. Метрики и логи растут, кардинальность зашкаливает (часто это архитектурная ошибка, но в реальности с этим сталкиваются почти все), счет в Grafana Cloud тоже растет. При этом часть логов по требованиям регуляторов нужно хранить годами, а другую часть логов мы, как разработчики, скорее всего никогда не будем использовать.

Да, мы пишем логи с расчетом на будущую отладку, но проблемы происходят не всегда. Такая реальность.

Я не буду сейчас углубляться в тему того, как правильно писать логи. Хочу сосредоточиться на том, что именно предлагает Grafana Cloud для решения этой проблемы.

Решение №1: Adaptive Metrics

Суть простая:

• анализируются реальные запросы к метрикам;
• неиспользуемые label-комбинации автоматически агрегируются или удаляются;
• кардинальность падает, стоимость ingest снижается.

Теоретически это может "сломать" метрики, но на практике это скорее вопрос неосторожной настройки.
Цель механизма - убрать мусор, который никто не запрашивает. И тут появляется дополнительный вопрос: если мы уже программно удаляем часть метрик, может быть, стоит вообще подумать, нужны ли они нам в принципе?

Решение №2: Adaptive Logs

Аналогично для логов - Adaptive Logs:

Идея та же:

• если лог никто не смотрит, зачем писать его в 100% случаев;
• логи сэмплируются по паттернам и частоте использования;
• низкоценный шум отбрасывается, ingest контролируется.

Нюансы и ограничения

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

И тут появляется второй, более важный нюанс.
Есть логи, которые нельзя выкидывать:

• аудит,
• безопасность,
• финансовые операции,
• требования регуляторов (хранить 1-3-5 лет).

Такие логи не должны лежать в hot-observability-стеке.

Разделяйте логи по назначению:

1. Hot logs (observability)
- дебаг, "текущие" логи;
- короткий срок хранения.

2. Audit / Compliance logs
- почти не запрашиваются;
- хранятся годами;
- отдельный log trail;
- выгрузка сразу (или через короткий период 3-7 дней) в cold storage (S3 / object storage / WORM).

Observability != постоянный архив.
Observability это про наблюдаемость в моменте (в короткий период времени).

Риски

• Слепо включить adaptive-фичи → потерять сигнал
• Неправильно классифицировать логи → проблемы с compliance
• Чуть сложнее архитектура → но сильно дешевле эксплуатация