Observability stack 2026: Prometheus, Grafana, Loki, OpenTelemetry

Observability в 2026 году уже не «приятный бонус» для SRE-команды, а базовая инженерная инфраструктура, без которой сложно держать SLA, бюджет и нервы on-call. Этот гайд разбирает, как собрать практичный стек на Prometheus, Grafana, Loki, Tempo и OpenTelemetry, чтобы видеть систему целиком, а не чинить продакшн по симптомам. Разберём модели данных, кардинальность, алертинг, стоимость и где у open-source-стека реальные границы по сравнению с SaaS-платформами.

Три столпа observability: logs, metrics, traces

Классическая тройка — логи, метрики и трейсы — работает только тогда, когда они связаны между собой по контексту: сервис, версия, окружение, tenant, request_id, trace_id. Если эта связка не сделана на уровне стандартов, команда получает три независимых источника шума. В реальных инцидентах это выглядит знакомо: дашборд «красный», логов миллионы строк, а корневая причина всё равно ищется вручную через grep и догадки.

Зачем нужны все три сигнала одновременно

Метрики отвечают на вопрос «где болит» и дают скорость реакции. Трейсы показывают «почему болит именно этот пользовательский путь». Логи помогают «доказать» гипотезу и восстановить контекст с ошибкой, payload и бизнес-атрибутами. У каждого сигнала своя роль:

• Metrics: агрегированная картина, дешёвое хранение, удобная база для алертов.
• Traces: причинно-следственные связи между сервисами и внешними зависимостями.
• Logs: деталь инцидента, forensic-уровень, юридическая и операционная аудитность.

Практическое правило: если у события нет trace_id и service.version, это не инженерный сигнал, а трудноиспользуемый текст.

Слои зрелости: от «видим CPU» к управлению риском

Большинство команд проходят 4 этапа:

1. Инфраструктурные метрики: CPU, RAM, диск, сеть, базовые алерты.
2. Service-level метрики: latency p95/p99, error rate, throughput по эндпоинтам.
3. Distributed tracing и корреляция с логами.
4. SLO/error budget и продуктовые сигналы (checkout success, search conversion).

Переход между этапами обычно занимает 6-18 месяцев, в зависимости от размера платформы и дисциплины релизов. Команды до 20 сервисов проходят путь быстрее; экосистемы 100+ сервисов упираются в стандартизацию тегов, ownership и расходы на хранение.

Минимальная схема данных для продакшна

Чтобы observability не превратилась в «дорогой лог-склад», введите обязательный набор атрибутов во всех трёх сигналах:

• service.name, service.namespace, service.version;
• deployment.environment (prod/stage/dev);
• region/zone;
• team/owner;
• trace_id и span_id для корреляции.

Это кажется бюрократией, но экономит часы расследований и десятки процентов бюджета на хранение за счёт управляемой фильтрации. Типичный выигрыш по MTTR после внедрения корреляции между сигналами — 20-40% в первые 2 квартала.

Prometheus и метрики: модель и кардинальность

Prometheus остаётся эталоном для метрик в cloud-native: pull-модель, мощный PromQL, огромная экосистема exporters и понятные операционные паттерны. Но в 2026 году главный вопрос уже не «как поставить Prometheus», а «как не убить его кардинальностью и долгим retention». Ошибки на этом уровне стоят дорого: от деградации query latency до роста инфраструктурных расходов в 2-4 раза.

Модель данных Prometheus и что в ней важно

Каждая временная серия определяется именем метрики + набором label-ов. Это гениально и опасно одновременно: один «плохой» label вроде user_id или session_id может создать миллионы серий.

• Хорошие label-ы: method, status_code, endpoint_template, region.
• Пограничные: pod_name, container_id (часто приемлемо, но требует лимитов).
• Плохие: email, phone, UUID запроса, полный URL с query-параметрами.

Практический ориентир: для среднего кластера Kubernetes держите активные серии в диапазоне 1-8 млн на инстанс long-term backend-а и 200-800 тыс на отдельный Prometheus shard. Выше нужно шардирование, federation или remote_write в отдельное хранилище.

Кардинальность как управляемый бюджет

Нормальная стратегия — не «запрещать всё», а вести кардинальность как бюджет с ревью. Рабочий подход:

1. Лимит на число series per metric и per tenant.
2. Review новых метрик в PR: зачем, где используется, какой retention.
3. Автоалерт на всплеск новых series (>20-30% за сутки).
4. Дропаут неиспользуемых метрик раз в 30-60 дней.

Для большинства продуктовых команд достаточно 15-30 дней hot-retention и downsampling для более длинной истории. Хранить «сырые» high-cardinality метрики 180+ дней обычно невыгодно.

Практика запросов и recording rules

PromQL гибкий, но дорогие ad-hoc запросы на больших диапазонах «кладут» UX Grafana. Выносите тяжёлые вычисления в recording rules и используйте стандартизированные панели. Пример ориентиров по latency в API:

Метрика	Цель	Окно
p95 latency	< 250-400 мс	5-15 мин
Error rate	< 0.5-1.0%	5 мин
Saturation (CPU/RAM)	< 70-80%	15-60 мин

Если Prometheus используется как часть observability-платформы, хорошо работает модель «локальный scrape + central long-term store». Она даёт быстрый on-call контур и отдельно решает аналитику на квартальных горизонтах.

Grafana: dashboards, alerting, datasources

Grafana давно перестала быть просто «рисовалкой графиков». В зрелом стеке это единая точка принятия решений: дашборды для команд, унифицированный alerting, доступ к метрикам, логам и трейсам через общую RBAC-модель. Ошибка №1 — делать «красивые» панели без чёткого use-case. Дашборд должен отвечать на вопрос за 30-60 секунд, иначе это декорация.

Дашборды: от vanity-metrics к decision-metrics

Каждой роли нужен свой слой:

• Exec/Product: SLO, доступность ключевых пользовательских сценариев, потери выручки.
• On-call: latency/error/traffic/saturation, деплои, состояние зависимостей.
• Команда сервиса: детальные панели по эндпоинтам, очередям, кэшу, БД.

Вместо «100 графиков на один экран» лучше 8-15 релевантных виджетов и drill-down по ссылкам. В 2026 норма — dashboard as code через Jsonnet/Terraform/Helm, а не ручной клик в UI.

Unified Alerting и шумоподавление

Алертинг в Grafana удобен, если выстроена маршрутизация и правила эскалации. Базовая схема:

1. Критичные сигналы (SLO burn rate, массовые 5xx) идут в pager и дублируются в чат.
2. Предупреждения (рост latency, nearing saturation) идут в командный канал без пейджинга.
3. Шумовые правила подавляются через inhibition/silence во время релизов.

Целевые ориентиры: не более 1-3 ночных пейджей на инженера в неделю и не менее 70% actionability у алертов. Если тревог много, а действий мало, проблема обычно в порогах и отсутствии привязки к SLO.

Datasources и безопасность доступа

Grafana часто становится точкой входа в разношёрстные хранилища. Типичный набор источников:

Datasource	Роль	Типичный горизонт
Prometheus/Mimir/VictoriaMetrics	Метрики и алерты	15-90 дней hot, далее downsample
Loki/ClickHouse	Логи и аудит	7-30 дней hot, архив 90-365 дней
Tempo/Jaeger	Трейсы	3-14 дней raw, longer через sampling

Для multi-team среды важны folder-level permissions, service accounts и токены с TTL. В средних компаниях (50-300 инженеров) переход на единый интерфейс обычно сокращает время первичной диагностики инцидента на 15-35%.

Loki: логи как код

Loki привлекателен не «дешевизной любой ценой», а тем, что переносит в логирование те же привычки, что в метриках: labels, централизованные queries и совместимость с Grafana. Ключевая идея: индексируются label-ы, а не весь текст сообщений. Поэтому архитектура логов должна быть продумана заранее, иначе можно получить быстрый ingest и медленные расследования.

Модель Loki и проектирование label-ов

Поток в Loki определяется набором label-ов. Каждый новый набор — отдельный stream, и здесь снова вопрос кардинальности. Рекомендуемый набор label-ов:

• service, env, region, cluster;
• level (info/warn/error);
• namespace/team.

Что не стоит класть в label: user_id, trace_id, request_id. Их лучше хранить в JSON-поле и фильтровать на этапе запроса. Если trace_id сделать label-ом, объём streams взлетает экспоненциально.

Pipeline: от сырых строк к полезному сигналу

Рабочий пайплайн «логи как код» обычно строится через Alloy/Promtail/OTel Collector:

1. Парсинг форматов (JSON/logfmt/regex) и нормализация полей.
2. Редакция PII: email, телефоны, токены, персональные идентификаторы.
3. Маршрутизация по окружениям и retention-классам.
4. Drop/debug-уровня в prod по policy.

Экономия заметная: ограничение debug-логов и нормальная ротация часто дают минус 25-60% к объёму хранения без потери операционной ценности.

Запросы и операционные сценарии

LogQL в Loki удобен, когда есть дисциплина в структуре логов. Примеры прикладных сценариев:

• Поиск ошибок по релизу: фильтр по service.version и уровню error.
• Корреляция с трассировкой: поиск по trace_id из алерта.
• Анализ деградации API: агрегация частоты ошибок по endpoint за 15 минут.

Типичный компромисс retention: 7-14 дней для детальных логов приложений, 30-90 дней для security/audit, архив в объектное хранилище на 6-12 месяцев при регуляторной необходимости. В рамках observability-стратегии Loki выигрывает, когда используется не как «черный ящик для всего», а как целенаправленный источник расследований.

Tempo и распределённый трейсинг

Tempo закрывает главную боль микросервисов: кто именно «сломал» пользовательский путь, когда метрики уже показывают деградацию. Его сильная сторона — масштабируемое хранение трейсов в object storage и глубокая интеграция с Grafana. Но ценность трейсинга раскрывается только при корректном инструментировании и понятных стратегиях sampling.

Что даёт трейсинг командам разработки

Трейс показывает путь запроса через gateway, сервисы, очереди, БД и внешние API, включая длительность каждого span. Это особенно полезно для:

• поиска «долгих хвостов» latency (p99 и выше);
• разбора редких, но дорогих ошибок в распределённых транзакциях;
• понимания влияния зависимостей: Redis, Kafka, Postgres, внешние платежи.

В практических командах время root cause analysis при сложных инцидентах сокращается на 30-50%, если трассировка покрывает ключевые пользовательские флоу end-to-end.

Sampling: где экономить, а где нельзя

Полный сбор трейсов для больших нагрузок слишком дорог. Обычно комбинируют head- и tail-sampling:

1. Head sampling 5-20% для общего потока.
2. Tail sampling 100% для ошибок, timeouts и медленных запросов.
3. Отдельные политики для VIP-операций: checkout, платежи, регистрация.

Это снижает объём хранения в 3-10 раз по сравнению с full-fidelity сбором. Для критичных сервисов имеет смысл хранить «золотой набор» трейсов 7-14 дней, а остальное 3-7 дней.

Практические ограничения Tempo

Tempo не заменяет логи и метрики, а дополняет их. Если нет корректных span-атрибутов (route, status_code, tenant, db.system), даже хороший UI не спасёт. Также нужен контроль размера спанов: слишком подробные атрибуты быстро раздувают storage.

Параметр	Типичный диапазон	Комментарий
Доля sampled-трафика	5-25%	Зависит от RPS и бюджета
Retention трейсов	3-14 дней	Чаще достаточно для инцидентов
Выигрыш MTTR	20-50%	При хорошей корреляции с логами

С точки зрения observability-платформы Tempo наиболее полезен там, где много межсервисных вызовов и регулярные релизы.

OpenTelemetry: стандарт инструментирования

OpenTelemetry (OTel) в 2026 — фактический стандарт для метрик, логов и трейсов. Его главная бизнес-ценность — переносимость: вы инструментируете код один раз и не привязываетесь к конкретному vendor. Для компаний, которые мигрируют между self-hosted и SaaS-решениями, это стратегическое преимущество.

Что именно стандартизует OTel

OTel задаёт:

• SDK и API для популярных языков (Go, Java, .NET, Python, Node.js, Rust);
• семантические конвенции атрибутов (HTTP, DB, messaging, cloud);
• OTLP-протокол доставки данных;
• Collector как универсальный pipeline-процессор.

Итог: единый язык наблюдаемости между командами, меньше «самодельных» форматов и меньше vendor lock-in.

Collector как control plane сигналов

OTel Collector обычно ставят как агент на ноды или как gateway-слой. Через него проходят фильтрация, batch, sampling, enrichment, redaction. Это точка, где удобно управлять качеством и стоимостью данных:

1. Удалять PII до отправки в storage.
2. Сэмплировать трейсы по правилам важности.
3. Ограничивать high-cardinality атрибуты.
4. Маршрутизировать разные типы сигналов в разные backend-ы.

На практике централизованный Collector-подход уменьшает число инцидентов, связанных с «сломали экспортер в коде», и ускоряет rollout новых политик с недель до дней.

План внедрения без остановки разработки

Рабочая последовательность для платформ из 20-100 сервисов:

• Шаг 1: стандартизировать resource-атрибуты (service.name, env, version).
• Шаг 2: покрыть HTTP/gRPC и базу данными auto-instrumentation.
• Шаг 3: добавить бизнес-спаны для ключевых сценариев.
• Шаг 4: включить correlation id в логи и связать с trace_id.

Обычно первые измеримые эффекты по диагностике видны через 4-8 недель. В рамках observability-архитектуры OTel лучше воспринимать как «слой стандартизации», а не как ещё один backend.

SLO и error budget на observability

Без SLO любая диагностика превращается в спор: «насколько это плохо». SLO переводит технические сигналы в управляемый риск для бизнеса. Если команда измеряет доступность, латентность и корректность по пользовательским путям, то приоритизация инцидентов и релизов становится объективной.

Как выбрать SLI и не утонуть в метриках

Для большинства продуктов достаточно 3-5 SLI на сервис:

• Availability: доля успешных запросов (например, 99.9%).
• Latency: доля запросов быстрее порога (например, 95% < 300 мс).
• Quality: бизнес-успех операции (например, оплаченный checkout).

SLO должны быть реалистичными: слишком «героические» цели ведут к постоянному burn и выгоранию, слишком слабые — не защищают пользователя.

Error budget как механизм управления релизами

Error budget — допустимая доля неуспеха за период (обычно 28-30 дней). Пример:

SLO	Допустимый downtime/ошибки в 30 дней	Интерпретация
99.9%	около 43 минут	Строгий режим, релизы через guardrails
99.5%	около 3.6 часа	Компромисс для внутренних платформ
99.0%	около 7.2 часа	Подходит не для всех клиентских сервисов

Если budget сгорает быстрее плана, команда снижает темп релизов и вкладывается в устойчивость. Если расход низкий, можно ускорять эксперименты. Это снимает вечный конфликт «фича против надёжности» на уровне фактов.

Алерты по burn-rate, а не по CPU

Современная практика — алерты на скорость сжигания error budget в нескольких окнах (например, 5 минут и 1 час). Такой подход лучше ловит реальные пользовательские инциденты и уменьшает ложные тревоги. В зрелых командах число «бесполезных» пейджей падает на 30-60% после перехода к SLO-ориентированному алертингу.

Если observability не связано с SLO, оно остаётся технической телеметрией. Когда связано — становится системой управления качеством сервиса.

Стоимость observability: cost-control

Расходы на наблюдаемость растут быстрее, чем кажется: больше микросервисов, больше событий, длиннее retention, выше требования комплаенса. Без политики cost-control бюджет легко удваивается за год. Хорошая новость: 40-70% затрат обычно управляемы через архитектуру данных и операционные правила.

Где возникают основные траты

• Ingest: объём входящих логов/метрик/трейсов в секунду.
• Storage: retention, репликация, класс хранилища.
• Query: тяжёлые аналитические запросы и concurrency.
• Эксцесс кардинальности: миллионы лишних серий и streams.

В типичном распределении логирование может занимать 50-80% общей стоимости, метрики 10-30%, трейсы 10-25% в зависимости от sampling.

Практические рычаги экономии без потери качества

1. Tiered retention: hot 7-30 дней, warm/cold в объектном хранилище.
2. Sampling и tail-policy для трейсов.
3. Drop low-value логов (debug/healthcheck spam).
4. Label hygiene и лимиты кардинальности.
5. Recording rules и кэширование популярных запросов.

В компаниях среднего масштаба (100-500 инженеров) комбинация этих мер часто даёт экономию 25-50% за 1-2 квартала.

Финансовая модель: ориентиры для планирования

Профиль команды	Примерный месячный диапазон затрат	Комментарий
20-40 сервисов, умеренный трафик	от 4 000 до 15 000 USD	Self-hosted + объектное хранилище
50-120 сервисов, высокий логовый поток	от 15 000 до 60 000 USD	Ключевой риск: логи и кардинальность
Крупная платформа 150+ сервисов	от 60 000 до 250 000 USD	Нужны строгие governance-политики

Для локального рынка также учитывают оплату труда платформенной команды: SRE/Platform-инженеры обычно в диапазоне 220-500 тыс ₽ в месяц в зависимости от уровня и региона. В результате observability-стоимость — это не только инфраструктура, но и инженерное время на поддержку стандартов.

Альтернативы Grafana stack: Datadog, NewRelic

Open-source стек выигрывает в контроле и предсказуемости архитектуры, но не всегда в скорости запуска. SaaS-платформы вроде Datadog и New Relic дают быстрый старт и богатые встроенные функции, зато требуют внимательного контроля биллинга и vendor-стратегии.

Когда SaaS объективно удобнее

• Нужно запуститься за недели, а не за квартал.
• Нет платформенной команды для поддержки self-hosted контура 24/7.
• Нужны out-of-the-box интеграции и APM без долгой настройки.

Для стартапов и продуктовых команд до 50 инженеров это часто рациональный выбор, особенно при ограниченных ops-ресурсах.

Когда self-hosted стек выгоднее

• Жёсткие требования к локализации данных и комплаенсу.
• Крупные объёмы телеметрии, где per-GB pricing становится дорогим.
• Нужен тонкий контроль pipeline и кастомные политики обработки.

На масштабах enterprise open-source контур нередко даёт лучшую экономику TCO, несмотря на более высокий порог входа.

Сравнение подходов

Критерий	Grafana stack (self-hosted)	Datadog/New Relic (SaaS)
Скорость запуска	Средняя: 1-3 месяца до зрелого контура	Высокая: 2-6 недель
Гибкость и кастомизация	Очень высокая	Высокая, но в рамках платформы
Прозрачность стоимости	Выше при хорошем FinOps	Ниже при резком росте ingest
Vendor lock-in	Низкий (особенно с OTel)	Средний/высокий
Нагрузка на внутреннюю команду	Выше	Ниже

Оптимальный путь для многих: начинать с SaaS на ранней стадии и параллельно строить OTel-стандарты, чтобы при росте безболезненно перейти на смешанную или self-hosted модель observability.

Российские решения: VictoriaMetrics, ClickHouse Keeper

В российском контуре часто критичны локальное размещение, предсказуемая стоимость и устойчивость к внешним ограничениям. Поэтому в дополнение к «классическому» стеку команды всё чаще используют VictoriaMetrics для метрик и ClickHouse-подход для логов/аналитики. Это не «замена всему», а прагматичная адаптация архитектуры под операционные и регуляторные реалии.

VictoriaMetrics: плотное хранение метрик и простая эксплуатация

VictoriaMetrics ценят за эффективность хранения, совместимость с PromQL-экосистемой и понятный operational footprint. Практические плюсы:

• Хорошая компрессия временных рядов и экономия диска.
• Поддержка кластерного режима для крупных инсталляций.
• Удобный путь миграции из Prometheus через remote_write.

Для платформ с высокими объёмами метрик это часто снижает стоимость на десятки процентов при сопоставимой функциональности для SRE-задач.

ClickHouse и Keeper в контуре логов и событий

ClickHouse широко используется как backend для логов, security-событий и продуктовой телеметрии. Keeper обеспечивает координацию в кластере, где нужна надёжная метаинфраструктура без внешних зависимостей. Сильные стороны подхода:

1. Высокая скорость аналитических запросов на больших объёмах.
2. Гибкие TTL и tiered storage.
3. Единая платформа для логов и бизнес-аналитики.

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

Реалистичная архитектура для локального рынка

Сигнал	Практичный backend	Комментарий
Метрики	Prometheus + VictoriaMetrics	Быстрый scrape и длинный retention
Логи	Loki или ClickHouse	Выбор зависит от сценариев расследования и BI
Трейсы	Tempo + OTel Collector	Нужны sampling-политики и корреляция

Если цель — устойчивый observability-контур на 2-3 года, лучше проектировать сразу гибридно: открытые стандарты (OTel), сменяемые backend-ы и чёткие внутренние правила данных.

FAQ о observability

Следите за обновлениями itech-news.ru — мы держим эту страницу актуальной.