GreptimeDB — Убийца стека Prometheus+Loki+Tempo? Обзор базы данных на Rust для тотального observability

Знакомая ситуация? У вас есть Prometheus для метрик, Loki для логов и Tempo (или Jaeger) для трейсов. Каждый инструмент хорош по-своему, но вместе они образуют эдакий «зоопарк технологий». Данные разрознены, коррелировать события — целая история, а поддерживать всё это хозяйство становится всё сложнее с ростом проекта.

А что, если я скажу, что есть решение, способное заменить всю эту троицу? Сегодня мы заглянем под капот GreptimeDB — облачной time-series базы данных, написанной на Rust, которая обещает объединить метрики, логи и трейсы в одном месте. Давайте разбираться, насколько это удобно и кому такой инструмент может пригодиться.

Что такое GreptimeDB и зачем он нужен?

Если коротко, GreptimeDB — это база данных, созданная специально для хранения и анализа данных о наблюдаемости (observability). Ключевая идея — перестать делить данные на "метрики", "логи" и "трейсы" на уровне хранения. Для GreptimeDB это просто события, привязанные ко времени, которые можно складывать в одно место и анализировать вместе.

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

Проект идеально подходит для:

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

Ключевые возможности: чем цепляет GreptimeDB?

Давайте пробежимся по самым интересным фичам, которые я нашёл в README и документации.

1. Всё в одном: метрики, логи и трейсы под одной крышей

Это главная "фишка" проекта. GreptimeDB нативно поддерживает OpenTelemetry, что позволяет ему принимать и понимать все три столпа наблюдаемости. Вы можете отправлять в него данные, как в обычный TSDB, но при этом запрашивать их комплексно.

Чем это полезно? Вы получаете единый источник правды о состоянии вашей системы. Отладка инцидентов ускоряется в разы, потому что все необходимые данные находятся в одном месте и связаны между собой.

2. SQL и PromQL "из коробки"

Разработчики GreptimeDB не стали изобретать очередной проприетарный язык запросов. Вместо этого они предлагают использовать старый добрый SQL или уже ставший стандартом в мире мониторинга PromQL.

Это огромное преимущество. Не нужно переучивать команду — аналитики могут писать привычные SQL-запросы, а DevOps-инженеры продолжат использовать PromQL для алертов и дашбордов. Кстати, GreptimeDB совместим с протоколами MySQL и PostgreSQL, так что подключить к нему можно практически любой BI-инструмент.

3. Производительность на стероидах (спасибо, Rust!)

Проект написан на Rust, что уже намекает на фокус на производительности и безопасности. Разработчики заявляют о субсекундном времени отклика на запросах к петабайтным объёмам данных. Это достигается за счёт продуманной системы индексации (inverted, fulltext, skipping) и эффективной работы с памятью.

4. Облачная архитектура и экономия затрат

GreptimeDB спроектирован как cloud-native решение. Его архитектура с разделением вычислений (compute) и хранения (storage) позволяет гибко масштабировать компоненты независимо друг от друга. Данные хранятся в нативном формате в объектных хранилищах типа Amazon S3 или Azure Blob Storage.

Что это даёт на практике? Во-первых, вы платите за хранение гораздо меньше, чем при использовании дисков, подключенных к серверам баз данных. Во-вторых, это обеспечивает практически неограниченную масштабируемость и отказоустойчивость.

Как это работает под капотом?

GreptimeDB может работать в двух режимах:

Standalone: Один бинарный файл, идеально для локальной разработки, тестов или небольших инсталляций.
Distributed: Полноценный кластерный режим для продакшена, состоящий из трёх компонентов:
- Frontend: Принимает запросы, обрабатывает их и взаимодействует с клиентами по разным протоколам.
- Datanode: Отвечает за хранение и извлечение данных.
- Metasrv: Мозг кластера, который хранит метаданные и координирует работу остальных узлов.

Архитектура GreptimeDB

Интересно, что в основе GreptimeDB лежат такие мощные проекты Apache, как Arrow (для эффективной работы с данными в памяти), Parquet (для колоночного хранения на диске) и DataFusion (в качестве движка запросов). Это говорит о том, что команда не стала изобретать велосипеды, а взяла лучшие в своём классе опенсорс-компоненты.

Попробуем запустить?

Начать работать с GreptimeDB проще простого, если у вас есть Docker. Достаточно выполнить одну команду:

docker run -p 127.0.0.1:4000-4003:4000-4003 \
  -v "$(pwd)/greptimedb_data:/greptimedb_data" \
  --name greptime --rm \
  greptime/greptimedb:latest standalone start \
  --http-addr 0.0.0.0:4000 \
  --rpc-bind-addr 0.0.0.0:4001 \
  --mysql-addr 0.0.0.0:4002 \
  --postgres-addr 0.0.0.0:4003

После этого у вас будет запущенный экземпляр GreptimeDB, а по адресу http://localhost:4000/dashboard будет доступен встроенный веб-интерфейс. Можно сразу начинать отправлять данные и писать запросы.

Выводы: кому стоит присмотреться?

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

Кому точно стоит попробовать:

Инженерам, строящим observability-платформы: Если вы хотите предоставить своим разработчикам единый и мощный инструмент для мониторинга, GreptimeDB может стать отличным ядром для такой системы.
Проектам с большими объёмами данных: Если ваш Prometheus "задыхается" от кардинальности метрик, а ELK-стек обходится слишком дорого, GreptimeDB предлагает более производительную и экономичную альтернативу.
Любителям Rust и современных технологий: Проект активно развивается, у него открытый и дружелюбный код, и это отличная возможность поучаствовать в создании чего-то действительно нового.

Проект всё ещё находится в статусе беты, но уже используется в продакшене. Дорожная карта обещает релиз версии 1.0 в начале 2026 года. Учитывая скорость развития и мощь заложенных идей, я бы точно добавил GreptimeDB в свой список для наблюдения. А лучше — попробовал бы его на каком-нибудь пет-проекте уже сегодня.