Терминология observability: SLI, SLO, SLA, burn rate и контекст данных

Observability в современных распределённых системах строится на связке метрик, логов и трассировок. Главной целью является не только сбор данных, но и способность быстро отвечать на вопрос: достигаются ли бизнес-цели и какие действия необходимы для сохранения уровня сервиса. В этой главе разберём ключевые термины - SLI, SLO и SLA - и познакомимся с концепцией burn rate как индикатором потребления запаса надежности. Особое внимание уделим роли контекста данных: как связать метрики, логи и трассировки для единообразной оценки качества сервиса и ускорения расследований инцидентов в Grafana-подходе с Prometheus, Loki и Tempo.

В рамках графана-обеспечения эти понятия выступают не абстрактными терминами, а практическими метриками, которые прямо включаются в дашборды, алерты и процессы управления изменениями. Понимание тонкостей реализации в стеке Grafana-Prometheus-Loki-Tempo позволяет переходить от концепций к оперативным решениям: какие показатели считать SLI, как рассчитывать SLO на разных временных резолюциях, как формировать алерты и как интерпретировать burn rate в контексте бизнес-целей и пользовательского опыта.

Что такое SLI, SLO и SLA и как они соотносятся внутри команды и с бизнес-целями.
Как вычислять и визуализировать SLI в рамках архитектуры observability.
Как burn rate отражает скорость расхода запаса надежности и как управлять им через алерты.
Как связать данные метрик, логи и трассировки через единый контекст данных и trace-id.
Какие практики внедрения применимы к микросервисной архитектуре и data platform.

Краткое содержание главы

Определения SLI, SLO и SLA, их роль в управлении уровнем сервиса и контекст данных.
Методы измерения SLI и расчета burn rate, выбор подходящих окон времени и чувствительных порогов.
Архитектура наблюдаемости: как Prometheus, Loki и Tempo работают вместе для единообразной оценки SLO и быстрого расследования инцидентов.
Реализация в Grafana: расчёты SLI и burn rate в PromQL, создание дашбордов и алертов, связь с логами и трассировками.
Контекст данных: связывание метрик, логов и трассировок, унификация идентификаторов и практики корреляции.
Практические сценарии внедрения и управление изменениями.

Введение в термины: SLI, SLO, SLA, burn rate и контекст данных

SLI (Service Level Indicator) - это измеряемый показатель качества обслуживания, который отражает, насколько сервис выполняет заданные требования за фиксированный период. Примером SLI может быть доступность веб-сервиса, доля успешных запросов или задержка выполнения запроса выше заданного порога.

SLO (Service Level Objective) - целевой уровень услуги, который подтверждает достижение желаемого качества. SLO задаёт ожидание по SLI в заданном окне времени. Например, SLO по доступности 99.9% за календарный месяц.

SLA (Service Level Agreement) - договорное обязательство между поставщиком и клиентом, где конкретизируются цели по SLO и санкции в случае их невыполнения. SLA - это юридический документ, в котором отражается ответственность за недостижение целей и последствия для сервиса.

Burn rate - расход запаса надежности, показатель того, как быстро потребляется резерв, выделяемый под SLO. В практическом виде burn rate показывает скорость, с которой текущий уровень качества сервиса «съедает» остаток брака по SLO. Управление burn rate включает настройку порогов алертов и действий, которые должны предприниматься при превышении установленного уровня.

Контекст данных - это подход к связке данных из разных источников (метрики Prometheus, логи Loki, трассировки Tempo) через единые критические атрибуты (trace-id, span-id, служебные теги). Такой контекст позволяет не просто видеть, что сломалось, но и быстро понять, почему случилось: на каком сервисе, в каком сценарии и с какими зависимостями это повлекло последствия для пользователя.

Почему эти термины важны для Grafana-проекта observability? Потому что они задают норму измерений, позволяют автоматизировать реагирование на инциденты и обеспечивают прозрачность для бизнеса. Инструменты Grafana позволяют визуализировать SLI/SLO и автоматически превращать их в алерты, а благодаря Loki и Tempo - в связке метрик, логов и трассировок - ускорять диагностику и снижать время простоя.

SLI

SI - конкретное измерение качества. В зависимости от контекста, это может быть доля успешных HTTP-запросов, среднее время ответа или процент запросов, удовлетворяющих установленному порогу. Выбор SLI зависит от бизнес-целеполагания и пользовательского восприятия сервиса.

SLO

SLO - целевой уровень, который нужен бизнесу. Он отражает компромисс между инновациями и стабильностью. Простой пример: SLO по latency 95-й перцентиль менее 300 мс за календарный месяц. Величина SLO должна быть достижимой и иметь понятную ценность для пользователей.

SLA

SLA - юридический контракт с клиентом. SLA часто включает штрафные санкции и показываемые уровни сервиса. В рамках DevOps и SRE SLA служит мотивацией к улучшению надежности и дисциплине в эксплуатации, но для повседневной деятельности чаще опираются на SLO и SLI как operational targets.

Burn rate

Burn rate выражается отношением фактически потраченного запаса к запланированному. Если SLO равен 99.9% и окно - 1 час, то допустимая доля ошибок за час составляет приблизительно (1 - 0.999) / 3600 секунд на одну секунду измерения. Практически burn rate часто рассчитывают как соотношение фактического процентного объема ошибок к допустимому объему ошибок за заданное окно. Burn rate > 1 сигнализирует, что темп расхода запаса слишком велик и необходимы corrective actions.

Контекст данных

Контекст данных - это механизм связывания точек наблюдения в единый цепной след. Связь между метриками, логами и трассировками достигается через идентификаторы трасс (trace-id) и контексты, которые проходят через сервисы и инфраструктуру. В Grafana-стеке с Prometheus, Loki и Tempo это означает создание согласованных лейблов, поддержание стандартизированных форматов trace-context (W3C Trace Context, B3) и обеспечение возможности перехода от проблемы в инцидент к конкретному коду и зависимостям в микросервисной архитектуре.

Метрики и их измерение

Эффективная архитектура SLI/SLO требует ясности в том, какие метрики считаются, как они измеряются и как они агрегируются. В рамках observability-архитектуры целесообразно различать три уровня: инфраструктурный (уровень инфраструктуры и сервисов), бизнес-уровень (пользовательский опыт и бизнес-метрики) и инженерный (операционная работа и процессы).

Выбор SLI по доступности: доля успешных запросов за окно времени.
Выбор SLI по задержке: p95 или p99 latency в миллисекундах, соответствующий порог.
SLI по стабильности: доля ошибок 5xx в течение окна.
Контекстная совместимость: связать SLI с бизнес-метриками, например конверсию или время обработки заказа.

Рассмотрим простой пример: измерение доступности на уровне HTTP-запросов. Допустим, у нас есть счетчик http_requests_total с тегами status_code. Для SLI доступности можно определить две величины за окно 5 минут:

total_requests: сумма rate(http_requests_total[5m])
successful_requests: сумма rate(http_requests_total{status=~"2.."}[5m])

SLI_availability = sum(rate(http_requests_total{status=~"2.."}[5m])) / sum(rate(http_requests_total[5m]))

Для латентности можно использовать гистограмму продолжительности запросов http_request_duration_seconds_BUCKET:

total_requests = sum(rate(http_request_duration_seconds_count[5m]))
fast_requests = sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m]))
SLI_latency = fast_requests / total_requests

burn rate в таком контексте может быть рассчитан как отношение фактического расхода брака к рассчитанному брошу в окне:

error_rate = 1 - SLI_availability
allowed_error_rate_per_window = (1 - SLO) (для простого случая)
burn_rate_simple = error_rate / allowed_error_rate_per_window

Более точная формула с учётом времени окна:

window_seconds = 3600 (1 час)
allowed_error_rate_per_sec = (1 - SLO) / window_seconds
actual_error_per_sec = rate(http_requests_total{status!~"2.."}[1h])
burn_rate = actual_error_per_sec / allowed_error_rate_per_sec

Эта формула позволяет быстро определить, что текущий темп расхода запаса надежности превышает допустимый, и требует вмешательства.

Примеры расчётов в PromQL

SLI Availability (2xx-ответы) за 5 минут:

sum(rate(http_requests_total{status=~"2.."}[5m])) / sum(rate(http_requests_total[5m]))

SLI Latency (p95) за 5 минут с порогом 300 мс:

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) < 0.3

Burn rate (упрощённо) при SLO = 99.9% за 1 час:
```
rate(http_requests_total{status!~"2.."}[1h]) / ((1 - 0.999) / 3600)
```
Эти формулы показывают, как SLI/SLO переводятся в компьютерные вычисления внутри Grafana/Prometheus. В реальных конфигурациях можно вынести расчет burn rate в отдельную рекорд-правила Prometheus (recording rule) и затем использовать полученное значение в алертах и дашбордах.

Практическая реализация в Grafana

Создайте дашборд SLO, который визуализирует SLI_availability, SLI_latency и burn_rate для каждого сервиса или региона.
Включите графики SLO attainment, которые показывают соответствие целям за текущий период и за прошлые периоды.
Добавьте алерты на burn_rate > 1 или на устойчивое снижение SLI ниже порога SLO. Конфигурация alert-rule в Prometheus или In Grafana Alerting позволит уведомлять команду через выбранные каналы (Slack, PagerDuty, email).
```
yaml
```
name: service_burn_rate
rules:
- record: job: slo_burn_rate
  expr: rate(http_requests_total{status!~"2.."}[1h]) / ((1 - 0.999) / 3600)
  labels:
  service: myservice
  severity: critical

Такой подход обеспечивает единообразную логику расчета burn rate и позволяет удобно использовать в панелях Grafana как отдельный временной ряд.

Архитектура наблюдаемости и взаимодействие Grafana stack

Эффективная система мониторинга строится на разделении ролей между данными источниками и рациональном сводном виде данных. В типичной стеке Grafana данные поступают так:

Prometheus дежурит за метриками services и инфраструктуры. Он собирает лейблы и диапазоны, которые затем используются в PromQL для вычисления SLI и burn rate.
Loki собирает логи и обеспечивает быстрый доступ к пригодным для расследования записям. Важно настроить базовые поля (trace_id, service, instance) так, чтобы логи можно фильтровать по трассировкам.
Tempo хранит трассировки, обеспечивает просмотр трассировок по trace_id и визуализацию задержек по цепочке вызовов. Tempo позволяет видеть, где возникали задержки и как они повлияли на SLI.

Контекст данных реализуется через единые идентификаторы трассировки и общие теги семантики. В практике это означает:

Придерживаться единого формата trace-context (например, W3C Trace Context).
В прокси или сервисах автоматически прокидывать traceparent и другие контексты в заголовках и логах.
В Loki хранить trace_id вместе с сообщениями логов, чтобы можно было быстро перейти от лог-события к трассировке.
В Tempo обеспечить коннект трассировок с метриками Prometheus через идентификаторы спанов и родительских цепочек.

Такой подход позволяет строить «карту причинно-следственных связей» между событиями. Например, при падении SLI можно перейти к логу ошибки, затем к трассировке, чтобы увидеть, какие сервисы повлияли на время отклика и какие зависимости повлекли задержку. Grafana позволяет связать эти данные в рамках единого запроса через использование общих лейблов и trace-id.

Реализация в Grafana/Prometheus/Loki/Tempo: шаги и рекомендации

Определите цель SLO на уровне сервиса и бизнеса: какие пользовательские сценарии критичны, какие пороги допустимы, и какова частота обновления данных в дашбордах.
Инструментируйте сервисы так, чтобы метрики, логи и трассировки содержали единый контекст (trace-id, span-id, service, environment). Это критично для корреляции.
Настройте Prometheus recording rules для SLI и burn rate, чтобы не выполнять повторные вычисления на графиках и алертах.
Создайте дашборд Grafana, объединяющий метрики Prometheus, логи Loki и трассировки Tempo. Включите:
- графики SLI по доступности и задержке;
- burn rate график с порогами alert;
- панели для контекстного расследования: по trace_id можно открыть трассировку в Tempo и логи в Loki.
Конфигурация алертов: помимо пороговых значений по burn rate и SLI, добавьте триггеры на устойчивое снижение SLI ниже SLO в течение заданного «for» периода, чтобы предотвращать нагружение команды при кратковременных колебаниях.
Внедрите тестовую среду для моделирования инцидентов и проверки корректности расчетов. Это особенно важно для burn rate, чтобы не реагировать на ложные сигналы в критический момент.

Контекст данных: корреляция метрик, логов и трассировок

Контекст данных - ключ к эффективной диагностике. Применение trace-id на уровне интер-сервисных вызовов позволяет:

Связать конкретный инцидент с пользователем/клиентом и бизнес-сценарием.
Найти медленные сервисы и участвующие зависимости в трассировке Tempo.
Соотнести логи с трассировками, чтобы увидеть конкретные сообщения и ошибки, сопровождающие задержку.
Быстро выявлять узкие места в архитектуре: база данных, очереди, сетевые ограничения.

Современные практики рекомендуется дополнять следующим образом:

В системах с микросервисной архитектурой правильно инжектировать trace-context в клиентские запросы и пропускать его через все сервисы.
В логах хранить trace_id в формате приближённого контекста, чтобы находить соответствующую трассировку без потери информации.
В Tempo обеспечить быстрый поиск и фильтрацию по trace_id, а в Grafana - связать запросы по этому идентификатору с дашбордами SLI.
В бизнес-процессах учитывать, что не все SLO корректны на глобальном уровне. Региональные или клиентские SLO могут потребовать разных порогов и контекста.

Практические сценарии внедрения

Этап 1: формулировка целей SLO. Определение критичных бизнес-пользовательских сценариев и соответствующих SLI. Пример: 99.9% доступности для операций оформления заказа в течение календарного месяца.
Этап 2: инструментирование и сбор данных. Добавление метрик, исторически корректный сбор и интеграция trace-context. Создание базовых dashboards в Grafana, отображающих SLI и burn rate.
Этап 3: настройка алертирования. Пороговые значения burn rate и SLO-больницы. Включение отказоустойчивых стратегий: автоматическое масштабирование, переключение на резервные цепочки, уведомления на командные каналы.
Этап 4: корреляция и расследование. Использование контекста данных для быстрого поиска причин и влияния инцидента. Включение логов и трассировок в соответствующие дашборды и сценарии.
Этап 5: постоянное улучшение. Регулярный обзор событий, корректировка SLO на основе бизнес-целей, ретроспективы по инцидентам и улучшение автоматизации.

Key takeaways

SLI - измеряемый показатель качества сервиса; SLO - целевой уровень по этому показателю; SLA - договорное обязательство с бизнесом.
Burn rate отображает скорость расхода запаса надежности: его правильное вычисление и мониторинг позволяют предвидеть срыв SLO и избежать кризисных инцидентов.
Контекст данных обеспечивает способность обнаруживать причины инцидентов через связку метрик, логов и трассировок (trace-id, span-id) в Grafana-Prometheus-Loki-Tempo.
Правильная архитектура включает единые идентификаторы и согласованные схемы контекста между метриками, логами и трассировками, что ускоряет расследование и снижает время простоя.
Реализация SLI/SLO через PromQL и Grafana позволяет строить эффективные дашборды и алерты, а объединение с Loki и Tempo обеспечивает полноценную корреляцию и ускорение RCA.
Внедрение требует бизнес-ориентированного подхода к целям SLO, прозрачности для стейкхолдеров и устойчивых процессов непрерывного улучшения.

FAQ

Что такое SLI, SLO и SLA и как они взаимодействуют?

SLI - конкретное измерение качества: например, доступность или latency. SLO - целевой уровень на основании SLI, задаваемый на определённый период. SLA - юридический договор, где указаны обязательства и последствия. В практике SLI/SLO используются для оперативного управления сервисом, а SLA - как юридическая основа отношений с клиентами. В Grafana SLO можно визуализировать как достижение или нарушение, а SLA - как бизнес-обязательство, на которое могут ссылаться отчеты и аудит.

Как выбрать подходящие SLI для микросервисной архитектуры?

Для каждого критического бизнес-сценария выбирайте SLI, которые отражают пользовательский опыт: доступность основных функций, latency для типичных сценариев (checkout, поиск), долю ошибок в критических операциях. Важно не перегружать набор SLI слишком большим количеством метрик - лучше иметь несколько понятных и стабильных индикаторов, которые можно автоматически измерять и визуализировать.

Как вычислять burn rate на практике?

Burn rate рассчитывается как отношение фактического расхода запаса надежности к допустимому расходу за окно времени. В простейшей формуле burn_rate = actual_error_rate / (1 - SLO). Более точная версия учитывает окно времени и использует allowed_error_rate_per_sec = (1 - SLO) / window_seconds. В Grafana это реализуется через PromQL-выражения и настраиваемые алерты.

Какие данные и интеграции необходимы, чтобы обеспечить контекст данных?

Необходимо иметь единый trace-context в запросах и пропагировать trace-id через сервисы. Логи должны содержать trace_id, чтобы можно было связать сообщение с конкретной трассировкой в Tempo. Метрики должны носить те же теги (service, environment, region). Grafana может визуализировать данные из Prometheus, Loki и Tempo вместе, если идентификаторы согласованы.

Как связать SLI с бизнес-метриками?

Привязка осуществляется через целевые бизнес-процессы (заказ, платеж, регистрация). Например, SLI доступности может быть связан с количеством успешно завершённых операций в заказном конвейере. Это позволяет обязательно видеть, как бизнес-уровень влияет на техническую надежность.

Какие практики важны для устойчивого внедрения SLO в Grafana?

Определяйте SLO в рамках бизнес-целей, держите их простыми и измеримыми, регулярно пересматривайте на основе реальных данных, автоматизируйте расчет SLI и burn rate, используйте единый контекст для корреляции. Регулярно тестируйте алерты на инцидентных сценариях и обновляйте их под меняющиеся условия.

Какие сложности возникают при интеграции Loki и Tempo с Prometheus?

Основная трудность - согласование контекста и производительность. Логи и трассировки должны быть легко доступными через Grafana. Требуется план нумерации и хранения trace-id и единый формат тегов для эффективной корреляции. В конфигурации Tempo и Loki важно обеспечить быстрые источники и индексирование, чтобы не тормозить рабочие процессы и не приводить к задержкам в обновлении панелей.

Какие примеры архитектурных паттернов применимы для контекста данных?

Рекомендовано: propagate trace-context через все сервисы, поддерживать trace_id в логах, связывать логи с трассировками и метриками через общие лейблы, использование единых схем именования сервисов и окружений. Это обеспечивает эффективную корреляцию и ускорение RCA.

Как адаптировать подход под data platform и большие объемы данных?

В случае data platform фокус - на метриках производительности джобов, ETL-процессов и доступности сервисов. Важно сохранять нормальные окна времени и резолюции для исторических трендов, а также поддерживатьTTR для расследования. Обеспечьте агрегацию и хранение критически важных данных, чтобы burn rate не просачивался в нерелевантные временные интервалы.

Как оценивать эффективность внедрения SLO через Grafana?

Оценка включает три элемента: точность измерений (SLE/SLI), соответствие алертов реальным инцидентам и бизнес-impact (увеличение конверсии, снижение времени простоя). Регулярно проводите ретроспективы по инцидентам и корректируйте пороги и окна времени, чтобы отражать эволюцию сервиса и бизнес-задач.

Эта глава подчеркивает, что SLI, SLO, SLA, burn rate и контекст данных - не набор теоретических понятий, а практический набор инструментов, который поддерживает архитектуру Grafana-стека и обеспечивает устойчивое обеспечение качества сервиса в условиях сложной современной цифровой инфраструктуры.

← Предыдущая статья

Основы observability: цели, принципы и опорные показатели

Следующая статья →

Архитектура Grafana: компоненты, роли и принципы развёртывания