Еще меньше данных и больше смысла: как ещё можно оптимизировать затраты на мониторинг?

Помните нашу предыдущую статью, в которой мы обсуждали сэмплирование как эффективный инструмент для снижения затрат на мониторинг? Тогда мы сделали акцент на том, как выборочная запись трейсoв позволяет резко сократить объёмы хранимых данных — и, соответственно, расходы на серверы и хранилища. Однако сэмплирование, каким бы эффективным оно ни было, — это лишь вершина айсберга.
Хотелось бы иметь возможность по щелчку пальцев, сократить затраты на инфраструктуру мониторинга минимум вдвое. Но для этого, нам нужен соответствующий инструментарий…
Далее в этой статье, мы рассмотрим стратегии и подходы, позволяющие снизить расходы на инфраструктуру мониторинга. Спойлер: ни что из этого не является универсальным решением. Каждый инструмент может как помочь, так и навредить — всё зависит от того, где и как его применить.

Один из самых простых способов снизить объём хранимых данных — агрегировать метрики. Вместо хранения каждого замера загрузки CPU за секунду можно сохранять усреднённое значение за минуту, фиксировать минимальные и максимальные значения, медиану или перцентили (например, 90-й или 95-й). Это позволяет существенно уменьшить нагрузку на хранилище без потери ключевой информации.

Когда данные теряют актуальность, можно увеличивать интервал агрегации. Например, секундная детализация может быть необходима только за последние несколько дней, а для полугодового периода достаточно хранить данные с интервалом 10−30 минут. Это помогает сохранять и отслеживать долгосрочные тренды, уменьшая при этом объём используемого хранилища.

Что если разделить информацию на «горячую» (оперативную) и «холодную» (архивную)? «Горячее» хранилище содержит свежие, критичные для быстрого анализа метрики, трейсы и логи, которые запрашиваются часто и помогают оперативно реагировать на инциденты. Более старые данные, необходимые в основном для выявления долгосрочных трендов и ретроспективного анализа, отправляются в «холодное» хранилище (например, S3 и его аналоги). Такой подход значительно снижает расходы на быстрое, а значит дорогое «горячее» хранилище, но при этом оставляет возможность вернуться к архивным данным, хранение которых стоит в разы дешевле.

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

Передача в мониторинг только действительно нужной информации — один из самых простых способов сократить расходы. Например, если система ведёт детализированное логирование на уровне INFO (доп контекст, отладочные данные и т. д.), при этом большая часть этих данных никогда не анализируется, то их стоит перенести на уровень DEBUG или TRACE и не отправлять в централизованное хранилище логов. Такой приём позволяет избавиться от «мусора» и концентрироваться на действительно критичных событиях, что снижает общий объём хранимых данных и ускоряет поиск аномалий.

В предыдущих пунктах мы обсудили, как не собирать и не отправлять ненужные данные. Теперь разберёмся, как очищать уже неактуальную информацию. Здесь помогает автоматизация политик ротации логов, метрик, трейсoв и другой телеметрии. При этом такой подход тесно связан с методами из пунктов 1 и 2: старые детализированные метрики сначала могут агрегироваться, затем перемещаться из «горячего» хранилища в «холодное» и автоматически удаляться по истечении заданного срока. Такой подход можно описать метафорой: «-> балкон -> гараж -> мусорка». Он позволяет освобождать ресурсы, сохранять исторические тренды и не загромождать систему неактуальными деталями.

Теперь у нас есть все что нужно, чтобы сократить затраты на инфраструктуру мониторинга. Вопрос только в том, как этим распорядиться…

Оптимизация мониторинга — это поиск баланса между затратами и качеством наблюдаемости. Мы рассмотрели несколько техник, включая агрегацию, фильтрацию, разделение на «горячие» и «холодные» хранилища, а также автоматизацию жизненного цикла данных. Однако чрезмерная оптимизация может привести к пропущенным инцидентам, поэтому важно тестировать каждую стратегию перед её внедрением.

Оптимизация мониторинга — это не просто экономия, а способ сделать инфраструктуру более устойчивой, понятной и эффективной. А какие подходы используете вы? Делитесь своими находками в комментариях!