OpenObserve: во что обходится гигабайт собственных логов

MAATRIX

OpenObserve продают как экономичную замену Elasticsearch и Kibana: колоночное хранилище на Rust, сжатие в разы лучше, чем у классического ELK-стека, один бинарник вместо связки из трёх сервисов. Всё это правда — но «дешевле, чем Elasticsearch» и «дёшево в абсолютных цифрах» это два разных утверждения. Гигабайт логов на своём сервере никогда не стоит только цену диска: туда же входит память под индексацию и кеш запросов, CPU под компакцию файлов, и — самая недооценённая статья расходов — ваше время на настройку retention-политик и алертов, которое не разово тратится при установке, а капает постоянно. Разберём, из чего реально складывается владение логами на OpenObserve и на каком объёме это выгоднее облачного сервиса логирования, а на каком — нет.

Что такое OpenObserve и чем он отличается от ELK-стека

OpenObserve (в сообществе и в конфигах часто фигурирует как O2) — открытая платформа для логов, метрик и трейсов, написанная на Rust. Ключевое архитектурное решение — колоночное хранение данных в формате Parquet поверх объектного хранилища: локального диска, MinIO, S3, GCS или Azure Blob. Это принципиально другая модель, чем у Elasticsearch, который строит инвертированный полнотекстовый индекс по каждому полю каждого документа и держит эту структуру в куче JVM и файловом кеше ОС.

Разница проявляется в трёх местах:

• Формат хранения. Elasticsearch хранит данные в собственных сегментах Lucene, которые весят заметно больше исходного текста из-за индексов по каждому токену. OpenObserve хранит колонки в Parquet со сжатием (обычно zstd) — формат изначально проектировался под аналитические нагрузки и колоночное сжатие однотипных данных сжимает лучше, чем построчный JSON.
• Индексация. Полнотекстового индекса по умолчанию нет — OpenObserve строит облегчённый вторичный индекс (bloom-фильтры и метаданные по колонкам) плюс полнотекстовый индекс опционально для отдельных полей. Это ближе к модели Grafana Loki (индексировать метки, а не содержимое), чем к модели Elasticsearch, но с более гибким SQL-подобным запросом по всем полям.
• Рантайм. Один бинарник на Rust без JVM — нет кучи, нет GC-пауз, нет отдельного процесса под каждый узел кластера. Для небольших и средних объёмов это означает, что можно спокойно работать в single-node режиме на паре гигабайт RAM там, где Elasticsearch такого же объёма логов обычно просит 8-16 ГБ памяти под кучу и файловый кеш.

Разработчики OpenObserve публикуют собственные оценки экономии по хранению относительно Elasticsearch — цифры впечатляющие, но это маркетинг производителя на его синтетических данных. У вас будет другое соотношение: оно зависит от структуры логов, от степени сжатия и от того, включён ли полнотекстовый индекс на широких текстовых полях. Ниже считаем не рекламные цифры, а то, из чего реально складывается счёт за гигабайт на вашем сервере.

Из чего складывается цена гигабайта на своём сервере

Когда считают «стоимость логирования на своём сервере», обычно останавливаются на цене диска — это самая заметная, но далеко не единственная статья расходов. Полная стоимость владения (TCO) гигабайта логов в OpenObserve на самостоятельном хостинге состоит из четырёх компонентов:

1. Диск под хранение. Сжатые Parquet-файлы плюс WAL (write-ahead log) для только что принятых, но ещё не скомпактированных данных. WAL временно занимает больше места, чем финальные файлы — это нормально, но об этом забывают при расчёте пикового потребления диска.
2. Память под приём и запросы. Буферы приёма (ingestion buffer), кеш недавних запросов, память под компактор, который периодически объединяет мелкие файлы в крупные — это фоновый процесс, который ест CPU и RAM волнами, а не равномерно.
3. CPU под компакцию и запросы. Компакция — не бесплатная операция: сервер должен прочитать десятки мелких файлов, переупаковать их в один крупный со сжатием zstd, и делать это регулярно, иначе накопится «мусор» из тысяч мелких файлов, который замедляет поиск.
4. Время администратора. Настройка retention-политик по стримам (потокам логов), алертов на аномалии, дашбордов, прав доступа для команды — это не разовая настройка «поставили и забыли». Retention нужно пересматривать при изменении объёма логов, алерты — калибровать, когда меняется профиль нагрузки, иначе они либо молчат, либо спамят.

Первые три пункта считаются относительно просто — это ресурсы VPS или выделенного сервера, которые вы уже оплачиваете. Четвёртый пункт почти никогда не попадает в расчёт, хотя именно он определяет, окупается ли самостоятельный хостинг логов в командах, где нет выделенного DevOps-инженера.

Диск: сколько реально весит гигабайт после сжатия

Гигабайт «сырых» логов — это гигабайт текста, как он приходит из приложения: JSON-строки, plain text из stdout контейнеров, syslog-сообщения. После записи в OpenObserve этот гигабайт превращается в существенно меньший объём на диске за счёт двух эффектов: колоночного размещения (одинаковые значения в одной колонке сжимаются лучше, чем вперемешку в JSON-строке) и алгоритма сжатия zstd поверх колонок.

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

• Количество уникальных значений в полях. Поле status_code с десятком возможных значений сжимается кардинально лучше, чем trace_id со случайной строкой в каждой записи.
• Доля повторяющегося текста. Однотипные сообщения об ошибках, стектрейсы с одинаковой структурой — сжимаются хорошо. Свободный текст с высокой энтропией (например, сериализованные ответы внешних API) — заметно хуже.
• Включён ли полнотекстовый индекс. Если для поиска по содержимому сообщения включить полнотекстовую индексацию поля, это добавляет отдельную структуру данных поверх сжатых колонок — экономия по сравнению с Elasticsearch уменьшается, потому что вы платите за ту же функциональность похожей ценой.

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

# Быстрая проверка занятого места по стриму (потоку логов)
du -sh /data/openobserve/data/wal/files/default/logs/*/  
du -sh /data/openobserve/data/stream/files/default/logs/*/

Также не забывайте про WAL и промежуточные файлы до компакции — на пике (например, во время инцидента, когда логов резко больше обычного) занятое место может быть в разы больше финального, скомпактированного объёма, пока фоновый компактор не догонит поток.

Память и CPU: индексация, компакция, кеш запросов

RAM в OpenObserve расходуется не одним большим пулом, а несколькими независимыми потребителями, и это важно понимать при выборе размера сервера:

• Ingestion buffer. Входящий поток логов сначала попадает в память и WAL на диске, прежде чем будет упакован в Parquet-файл и отправлен в объектное хранилище. Чем выше пиковый поток записи (строк в секунду), тем больше требуется буфер, чтобы не терять данные при всплесках.
• Кеш запросов и метаданных. Активные дашборды, повторяющиеся алерт-запросы и недавние поисковые запросы кешируются в памяти — это ускоряет отклик UI, но растёт вместе с числом одновременных пользователей и активных алертов.
• Компактор. Периодически перечитывает мелкие файлы одного стрима и объединяет их в более крупные со сжатием — операция, которая кратковременно поднимает потребление CPU и RAM. На малых объёмах это незаметно, на потоке в десятки-сотни гигабайт в день компактор становится заметной нагрузкой, которую нужно закладывать в размер сервера отдельно от «повседневного» потребления.

Практическая рекомендация, с которой стоит начинать на single-node инстансе: 4 ГБ RAM и 2 vCPU достаточно для теста и небольшого продакшена (единицы гигабайт логов в день), но при росте потока стоит заранее заложить возможность апгрейда — вертикальный апскейл VPS с NVMe-диском обычно проще и дешевле, чем ранний переход на кластерную схему с отдельными компонентами ingester/querier/compactor.

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

Retention, алертинг и время администратора — скрытая часть TCO

Retention (срок хранения) в OpenObserve настраивается на уровне организации и стрима (потока) через UI или API, и это первое место, где самостоятельный хостинг требует постоянного, а не разового внимания. По умолчанию логи хранятся неограниченно долго, пока вы явно не зададите срок — а значит, если не настроить retention сразу, диск заполнится логами, которые никто никогда не откроет. Настройка задаётся числом дней хранения по стриму:

# Пример переменных окружения для докер-развёртывания OpenObserve
# (точный список переменных сверяйте с актуальной документацией под вашу версию)
ZO_ROOT_USER_EMAIL=admin@example.com
ZO_ROOT_USER_PASSWORD=change-me
ZO_DATA_DIR=/data/openobserve
ZO_COMPACT_DATA_RETENTION_DAYS=30

Значение retention для разных стримов почти всегда разное: логи веб-сервера и API нужны 30-90 дней для разбора инцидентов, аудит-логи — от полугода до нескольких лет (см. про то, что нужно хранить по закону), а debug-логи временных окружений можно чистить через неделю. Единая политика на всё подряд — частая ошибка: либо переплачиваете за диск под ненужные логи, либо теряете аудит-данные раньше срока.

Алертинг — вторая часть, требующая постоянной настройки, а не разовой. Алерт на «слишком много 5xx за 5 минут» работает нормально, пока не изменится профиль нагрузки: релиз, сезонный рост трафика, миграция сервисов — и старый порог либо молчит там, где нужно сработать, либо шлёт ложные уведомления по ночам. На практике команда, которая держит логи у себя, тратит на пересмотр retention и алертов от пары часов в месяц на небольшом проекте до нескольких часов в неделю на активно растущем — и это время нужно закладывать в TCO так же честно, как цену диска.

OpenObserve на своём сервере против облачных сервисов логирования

Облачные сервисы логирования (управляемые SaaS-платформы log management) продают удобство, а не только хранение: не нужно настраивать компакцию, retention чаще всего настраивается одним полем в интерфейсе, алертинг и дашборды готовы из коробки, масштабирование при всплесках нагрузки происходит само. Цена этого удобства — тарификация обычно по двум осям: объём принятых данных (ingested GB) и объём хранения за период, и обе оси растут вместе с потоком логов, а не с ценой ресурсов сервера.

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

На каком объёме самостоятельный хостинг реально выгоднее

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

• Малый и нестабильный поток (единицы гигабайт в месяц, разработка или ранняя стадия продукта). Почти всегда выгоднее облачный сервис с бесплатным или минимальным тарифом — время на разворачивание и настройку retention при таком объёме стоит дороже экономии на хранении.
• Стабильный средний поток (десятки гигабайт в месяц, один-два продакшен-сервиса). Разница начинает ощущаться: цена VPS под OpenObserve плюс время на первичную настройку часто оказывается дешевле подписки за сопоставимый объём, особенно если retention и алерты настраиваются один раз и меняются редко.
• Крупный устойчивый поток (сотни гигабайт и больше в месяц, несколько команд). Самостоятельный хостинг почти всегда выгоднее по деньгам за гигабайт — облачные тарифы на таких объёмах становятся заметной статьёй бюджета. Но это же объём, где нужен отдельный человек, следящий за компакцией и алертами регулярно — иначе экономия компенсируется инцидентами из-за забитого диска.
• Требования к резидентности данных или комплаенсу. Отдельный случай, где решение принимает не арифметика, а требование не выпускать данные за пределы своей инфраструктуры — здесь свой сервер обязателен независимо от объёма логов.

Прежде чем считать точку окупаемости в деньгах, честно оцените второй фактор: сколько часов в месяц команда реально готова тратить на компакцию, retention и калибровку алертов. Если ответ «ноль» — это сильный аргумент за облачный сервис даже при благоприятной арифметике по гигабайтам. Подробнее о том, как в принципе растёт счёт за observability вместе с нагрузкой, — в статье про цену логирования и мониторинга при росте в десять раз.

Частые вопросы