OpenTelemetry (OTel) стал «общим языком» наблюдаемости: инструментируете сервисы один раз, а дальше можете менять бэкенд трасс без переписывания приложений. Но на практике выбор хранилища/бэкенда для distributed tracing определяет не только удобство поиска спанов, но и стоимость хранения, нагрузку на сеть, требования к дискам и время на сопровождение.
Ниже — практичное сравнение трёх популярных вариантов: Jaeger, Grafana Tempo и Elastic APM. Смотрим глазами админа/DevOps: протоколы (включая OTLP), стратегии sampling (в том числе tail-based sampling), storage, масштабирование, интеграции и cost of ownership.
Базовая модель: где заканчивается OpenTelemetry и начинается бэкенд
OpenTelemetry обычно складывается из трёх «слоёв»: API/SDK (инструментация кода), Collector (приём, обработка и маршрутизация телеметрии) и протоколы/форматы экспорта. Ключевая идея простая: приложения отдают данные «в стандартном виде» (чаще всего OTLP), а бэкенд может быть любым — если выстроить корректный пайплайн.
Типовая схема для tracing:
services -> OpenTelemetry SDK -> OTLP -> OpenTelemetry Collector -> (Jaeger | Tempo | Elastic APM)Collector здесь важен не меньше бэкенда: именно в нём обычно включают tail-based sampling, нормализацию атрибутов, ограничения по объёму, обогащение, маршрутизацию в несколько систем и прочие «политики продакшена».
Поэтому сравнение «Jaeger vs Tempo vs Elastic APM» правильнее воспринимать как сравнение экосистем хранения/поиска трасс и операционных компромиссов.
Jaeger: классика tracing, сильный поиск, но думайте про storage
Jaeger воспринимается как один из самых понятных вариантов для distributed tracing: зрелая модель данных, хороший UI, прогнозируемое поведение. Он «нативно» про трейсы и спаны, без необходимости превращать трассы в «почти логи».
Протоколы и OTLP
В современных схемах Jaeger чаще всего получает данные через OpenTelemetry Collector по OTLP: сервисы шлют OTLP в Collector, а тот экспортирует дальше. На старте это упрощает жизнь: вы централизуете правила обработки и снижаете привязку к конкретному бэкенду.
Sampling и tail-based sampling
Самый практичный путь — делать sampling на стороне Collector. Тогда вы централизованно задаёте правила: сохранить 100% ошибок, 100% медленных запросов, 1–5% «обычного» трафика. Это намного удобнее, чем пытаться держать согласованные политики по всем сервисам.
Tail-based sampling особенно полезен, когда решение принимается после завершения трейса: например, «сохранить, если есть 5xx» или «сохранить, если p95 > 1s». Плата за это — память/CPU на Collector и небольшая задержка, пока трейс «дособерётся».
Storage: где Jaeger становится дорогим
Главный вопрос по Jaeger — storage. «Поднять Jaeger» легко, а удерживать большой поток трасс неделями с комфортным поиском — уже нет. Если вам нужна долгосрочная ретенция и быстрый поиск по атрибутам, придётся дисциплинировать данные и внимательно относиться к кардинальности.
Что чаще всего раздувает стоимость:
- Объём: трейсы растут из-за лишних атрибутов, больших событий и ошибок, а также «богатых» span events.
- Кардинальность: атрибуты вроде
user_id,order_id,session_idкак индексация/теги для поиска — прямой путь к дорогому хранению и тяжёлым индексам. - Ретенция: разница между 3–7 днями и 14–30 днями обычно кратно меняет требования к дискам и бюджету.
Эксплуатация и стоимость владения
По cost of ownership Jaeger обычно «дешёвый на старте» и «может стать дорогим позже». Если держать разумную ретенцию и делать агрессивный sampling — всё стабильно. Если же пытаться хранить много трасс с богатым поиском по любым тегам, растут и инфраструктурные затраты, и операционные часы на поддержку.
Если трассировка у вас выделяется в отдельный контур (Collector, хранилище, UI), удобнее держать это на отдельном сервере, чтобы не конкурировать с приложениями за CPU и диск. Для таких задач обычно берут отдельный VDS и масштабируют его независимо от продакшена.
Grafana Tempo: дешёвое хранение трасс и ставка на корреляцию
Grafana Tempo построен вокруг идеи «хранить трассы дёшево», обычно — в объектном хранилище, а поиск и расследование делать через минимальные индексы и связку с логами/метриками. Это хорошо ложится на реальность, где «трейсов много», а бюджет и диски — конечны.
OTLP как основной транспорт
Tempo органично работает с OTLP: сервисы могут отправлять трассы напрямую, но в проде почти всегда разумнее гнать всё через OpenTelemetry Collector. Collector позволяет выровнять атрибуты, отрезать лишнее, включить tail-based sampling и держать единые политики для всех команд.
Sampling: почти всегда обязателен
Tempo способен принимать большие объёмы, но экономическая модель всё равно упирается в сеть и хранение. Поэтому sampling — часть дизайна. Практичный паттерн выглядит так:
- Head sampling на SDK (например 5–20%) как базовый «предохранитель».
- Tail-based sampling в Collector для сохранения «важного»: ошибки, медленные запросы, редкие операции.
Tail-based sampling в Tempo-стеке часто воспринимается как «нормальная практика»: экономит место и при этом сохраняет диагностически ценные трейсы.
Storage: сильная сторона Tempo
Главный плюс Tempo — стоимость storage на длительной ретенции: трейсы пишутся в объектное хранилище, а «тяжёлых индексов как в логах» стараются избегать. Из этого вытекает и компромисс: «гуглоподобный» поиск по любому тегу за год чаще всего не является целевым сценарием.
Если команда привыкла к богатому поиску по множеству атрибутов, Tempo потребует другой привычки расследования:
- Находим
trace_idиз логов/ошибок и открываем трейс точечно. - Используем ограниченный набор меток для фильтрации (и следим за кардинальностью).
- Строим корреляцию «метрики → лог → трасса» в Grafana.
По теме дисциплины логов и трасс полезно заранее продумать пайплайн и выборку: уменьшение объёма access-логов Nginx без потери диагностики.
Эксплуатация и стоимость владения
Tempo часто выигрывает по cost of ownership, когда трасс много и нужна длинная ретенция. Особенно если у вас уже есть Grafana-стек и вы готовы внедрить практики: trace_id в логах, минимально нужные метки, централизованный tail-based sampling.
Tempo лучше всего раскрывается не как «трассы сами по себе», а как часть системы: метрики подсказывают, где проблема, логи дают контекст, а трасса показывает путь запроса по сервисам.
Elastic APM: единая платформа и сильный поиск, но следите за объёмами
Elastic APM — это tracing внутри большой экосистемы Elastic: поиск, корреляции, алерты, аналитика. Для команд, которые уже живут в Elastic, это часто означает меньше «зоопарка» и единый интерфейс для расследований.
OTLP и интеграция с OpenTelemetry
Elastic APM может быть конечной точкой для данных из OpenTelemetry. На практике удобнее держать OpenTelemetry Collector как «точку контроля»: в Elastic отправлять уже нормализованные данные, с понятным набором атрибутов и заранее продуманным sampling.
Sampling и tail-based sampling
Из-за сильного поиска возникает соблазн «хранить всё». В проде это быстро приводит к росту индексов и затрат. Поэтому sampling всё равно нужен, даже если Elastic умеет искать хорошо.
Tail-based sampling в Collector тут особенно полезен: сохраняете «ценные» трейсы (ошибки, деградации, редкие пути), но ограничиваете рост стоимости хранения.
Storage и влияние кардинальности
Elastic хорош там, где нужна гибкая аналитика и поиск, но цена подхода — индексируемые поля. Плохая практика «индексировать всё подряд» (особенно высококардинальные идентификаторы) способна сделать tracing очень дорогим.
Практичный вывод: заранее определить «контракт атрибутов» — какие поля обязательны, какие запрещены, какие можно хранить без индекса (если это соответствует возможностям вашей схемы и политик).
Эксплуатация и стоимость владения
Типичный профиль cost of ownership у Elastic APM:
- Дороже старт (ресурсы под Elastic и базовые практики эксплуатации).
- Проще для команд, у которых уже есть Elastic: меньше интеграций и «склейки» данных.
- Может стать очень дорогим при неконтролируемом потоке и неправильной схеме атрибутов.
Если вы публикуете APM UI наружу или ходите к нему из разных сетей, не откладывайте TLS «на потом»: с корректным сертификатом проще и безопаснее жить в проде. Под такие задачи подойдут SSL-сертификаты с нормальной цепочкой доверия.
Сравнение по ключевым критериям
1) Опыт поиска и расследований
Jaeger: удобный UI и «трассовый» опыт, хорошо подходит для работы именно с трейсами и поиском по тегам при умеренных объёмах.
Tempo: ставка на дешёвое хранение; расследование часто строится как «метрика → лог → трасса», а поиск по атрибутам обычно намеренно ограничен.
Elastic APM: сильный поиск и аналитика по полям, особенно удобно, когда нужно склеивать tracing с логами и метриками в одной платформе.
2) OTLP и архитектура пайплайна
Во всех трёх случаях здравый вариант — централизовать экспорт через OpenTelemetry Collector по OTLP. Это снижает vendor lock-in и даёт единые политики обработки, ретенции (косвенно — через sampling) и контроля атрибутов.
3) Sampling и tail-based sampling
Если упростить:
- Для небольших объёмов можно жить с head sampling.
- Для продакшена и экономии почти всегда выигрывает tail-based sampling в Collector.
Практика, которая почти всегда окупается: хранить 100% ошибок и медленных операций, а «норму» семплировать. Это делает tracing полезным, но не разорительным.
4) Storage и ретенция
Tempo чаще выигрывает по цене длительного хранения благодаря объектному storage и минимальной индексации.
Jaeger хорошо подходит, когда объёмы умеренные или ретенция небольшая/средняя, а нужен удобный опыт работы с трейсами.
Elastic APM уместен, когда важны поисковые/аналитические возможности и вы готовы дисциплинировать схему данных и индексацию.
5) Что реально «съедает бюджет»
Независимо от выбора, чаще всего деньги и время уходят на:
- Сеть: OTLP-трафик от сервисов к Collector и дальше.
- Диски: объём хранения и IOPS (особенно для индексируемых систем).
- Операционные часы: обновления, бэкапы, ретенция, тюнинг, разбор инцидентов.
- Неправильные атрибуты: высокая кардинальность и «слишком много полей» могут убить любой бюджет.
Рекомендации выбора: под какие сценарии что лучше
Когда выбирать Jaeger
- Нужен понятный tracing «из коробки» с хорошим UI.
- Объём трасс умеренный, ретенция небольшая/средняя.
- Команда хочет быстро начать и не строить сложную корреляцию с логами и метриками.
Когда выбирать Grafana Tempo
- Трасс много, ретенция нужна длинная, и важно держать storage недорогим.
- Есть (или планируется) зрелая связка с логами и метриками в Grafana.
- Вы готовы внедрить дисциплину:
trace_idв логах, минимально нужные метки, tail-based sampling.
Когда выбирать Elastic APM
- Вы уже используете Elastic и хотите единый стек наблюдаемости.
- Нужен мощный поиск/аналитика по событиям и атрибутам.
- Есть готовность управлять индексами, ретенцией и схемой данных, чтобы cost of ownership не выходил из-под контроля.
Практичные советы по OpenTelemetry, которые помогают с любым бэкендом
1) Заведите «контракт атрибутов»
До раскатки на весь прод договоритесь на уровне команды/платформы:
- Какие атрибуты обязательны (например,
service.name,deployment.environment,http.route). - Какие запрещены или должны быть ограничены (например,
user_id,session_id, произвольные заголовки). - Какие поля можно хранить, но не индексировать (если ваш бэкенд и политика хранения это поддерживают).
2) Делайте tail-based sampling централизованно
Даже если сейчас объёмы небольшие, проектируйте так, чтобы tail-based sampling включался без переписывания приложений: через Collector, отдельные пайплайны и понятные политики.
Если вы строите наблюдаемость на выделенной инфраструктуре, удобный паттерн — ставить Collector рядом с приложениями или на отдельные узлы: развёртывание OpenTelemetry Collector на VDS для трассировок.
3) Продумайте ретенцию под реальные задачи
Честный вопрос: «Зачем нам трассы старше 7 дней?». Для большинства отладки и расследований 3–14 дней достаточно. Длинная ретенция обычно оправдана, если у вас редкие инциденты, длинные циклы постмортемов или внутренние требования по хранению.
4) Сразу внедрите корреляцию trace_id в логи
В реальных расследованиях самый быстрый путь обычно такой: ошибка в логе → trace_id → открыли полный трейс. Это особенно важно для Tempo, но полезно и для Jaeger/Elastic.
Итог
Если свести выбор к одной фразе:
- Jaeger — сильный и понятный tracing-опыт, хорош для умеренных объёмов и быстрого старта.
- Grafana Tempo — ставка на дешёвое storage и масштабирование, особенно когда трасс много и нужна длинная ретенция.
- Elastic APM — платформа «всё в одном» с мощным поиском, но требующая дисциплины по данным и контроля объёмов.
Во всех сценариях OpenTelemetry и OTLP дают главное преимущество: вы сохраняете свободу миграции и можете менять бэкенд, оптимизируя cost of ownership по мере роста системы. А если под это нужна предсказуемая инфраструктура и изоляция ресурсов, логичный шаг — выделить наблюдаемость на отдельный VDS.
