Практикум по цене наблюдаемости

Оповещения без шума: скорость исчерпания бюджета, кардинальность и выборка

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

Эксплуатация → SRE55 минут4 модуля5 вопросов
После курса

Что вы сможете сделать

  1. Отделять состояние оповещения, уведомление и срочное оповещение, требующее действия.
  2. Строить оповещения SLO по скорости исчерпания бюджета и парным окнам.
  3. Оценивать, как новые метки перемножают кардинальность, и считать фактический срок хранения.
  4. Выбирать раннюю или хвостовую выборку трассировок, зная её слепые зоны и цену эксплуатации.
Модуль 1 из 4

Слой 1. Pager тратит человеческое внимание

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

  • Правило оповещения вычисляет состояние active/pending/firing, а слой уведомлений отдельно группирует, подавляет и направляет его.

    Проверить тезис: Сигнал мониторинга 01 02 · Правило оповещения 01

  • Срочное оповещение должно требовать действия; пользовательский симптом важнее дублирующих оповещений для каждой возможной причины.

    Проверить тезис: Оповещение, требующее действия 01 · Оповещение по симптомам 01 02

  • Частые оповещения, не требующие действия, создают усталость от уведомлений и могут скрыть настоящий инцидент в шуме.

    Проверить тезис: Alert fatigue 01 02

Модуль 2 из 4

Слой 2. Срочность через error-budget burn

Статический порог ошибок не знает цену SLO. Скорость исчерпания бюджета показывает, как быстро текущая ошибка съедает допустимый бюджет.

  • Скорость исчерпания бюджета, равная 1, равномерно расходует бюджет за окно SLO; множитель нельзя интерпретировать без точного SLO.

    Проверить тезис: Скорость расходования бюджета SLO 01 02 · Бюджет ошибок 01

  • В рекомендуемой схеме Google SRE Workbook длинное и короткое окна одной пары должны одновременно превышать её порог. Эта логика отличает выбранную схему и не является определением любого многооконного оповещения.

    Проверить тезис: Многооконное оповещение по скорости расхода 01

  • Срочное оповещение и заявку разводят по времени до исчерпания, а сервис с низким трафиком требует отдельной настройки из-за малого знаменателя.

    Проверить тезис: Оповещение, требующее действия 02 · Многооконное оповещение по скорости расхода 02

Модуль 3 из 4

Слой 3. Labels и retention имеют цену

Объём наблюдаемости растёт не только от скорости запросов: измерения идентичности создают новые ряды, а срок хранения удерживает их во времени.

  • Каждое уникальное сочетание меток — отдельный временной ряд; измерения могут перемножать кардинальность.

    Проверить тезис: Кардинальность метрик 01 02 · Кардинальность метки 02

  • Неограниченные ID пользователя, сеанса и запроса не помещают в метки метрик; исследование по сущности ведут в журналах или трассировках.

    Проверить тезис: Высокая кардинальность 01 02

  • Срок хранения — политика системы хранения: ограничения по времени и размеру могут сократить фактический горизонт, а сигналы требуют разных периодов.

    Проверить тезис: Хранение телеметрии 01 02 · Окно хранения 01

Модуль 4 из 4

Слой 4. Sampling — управляемая потеря данных

Выборка уменьшает стоимость только потому, что часть трассировок не попадёт в систему хранения. Нужно выбрать, какие слепые зоны допустимы.

  • Выборка трассировок сокращает обработку и экспорт, но не подходит для записей, которые политика запрещает терять.

    Проверить тезис: Выборка трассировок 01 02

  • Начальная выборка принимает раннее детерминированное вероятностное решение и не видит будущую ошибку на последующих этапах.

    Проверить тезис: Ранняя выборка трассировок 01 02

  • Хвостовая выборка выбирает по ошибке и задержке всей трассировки, но хранит состояние и требует маршрутизации с учётом TraceId всех фрагментов трассировки в один сегмент средства выборки.

    Проверить тезис: Выборка по завершённой трассировке 01 02

Финишная прямая

Проверьте инженерное мышление

Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.

01Загрузка CPU на серверной части выросла до 90%, но пользовательская задержка и ошибки остаются в пределах SLO. Что корректнее для срочного оповещения?
02Длинное окно превышает порог исчерпания бюджета SLO, но короткое окно уже ниже него. Что означает парное правило AND?
03Предлагают добавить user_id с миллионом значений в метку метрики запросов. Что делать?
04Prometheus настроен на хранение 30 дн. и ограничение размера, которое заполняется за 12 дней. Каков вероятный фактический горизонт?
05Хвостовое средство выборки масштабировали случайным распределением каждого фрагмента трассировки по сборщикам. В чём риск?
Проверяемая база

Источники курса

Полные сведения о первоисточниках приведены один раз для всего курса. Под тезисами — ссылки на соответствующие утверждения Архивариума.

  • Официальная документация

    Alerting Rules

    Prometheus Authors · Prometheus latest documentation, checked 29 August 2026

    Документирует alert expressions, pending/firing states, for/keep_firing_for и передачу notifications в Alertmanager.

    Открыть первоисточник
  • Официальная документация

    Monitoring Distributed Systems

    Google Site Reliability Engineering · Site Reliability Engineering, Chapter 6

    Формулирует symptom-based paging, actionable pages и риск alert fatigue от частых незначимых notifications.

    Открыть первоисточник
  • Официальная документация

    Alerting Best Practices

    Prometheus Authors · Prometheus best practices, checked 29 August 2026

    Рекомендует простые alerts по user-visible symptoms, slack для коротких blips и диагностические links вместо paging на каждую cause.

    Открыть первоисточник
  • Официальная документация

    Alerting on SLOs

    Google Site Reliability Engineering · The Site Reliability Workbook, Chapter 5

    Определяет error-budget burn rate и multiwindow multi-burn-rate approach, включая разные page/ticket windows.

    Открыть первоисточник
  • Официальная документация

    Example Error Budget Policy

    Google Site Reliability Engineering · Published policy, 19 февраля 2018 года

    Определяет error budget как 1 minus SLO и связывает exhaustion с заранее согласованными actions.

    Открыть первоисточник
  • Официальная документация

    Metric and Label Naming

    Prometheus Authors · Prometheus best practices, checked 29 August 2026

    Определяет каждую unique комбинацию label pairs как отдельную time series и запрещает unbounded high-cardinality labels.

    Открыть первоисточник
  • Официальная документация

    Prometheus Storage

    Prometheus Authors · Prometheus latest documentation, checked 29 August 2026

    Документирует time/size retention, oldest-first deletion, capacity formula и временный disk overhead compaction.

    Открыть первоисточник
  • Официальная документация

    Guide to Computer Security Log Management

    National Institute of Standards and Technology · NIST SP 800-92, September 2006

    Связывает period хранения logs с policy, расследованиями, compliance, объёмом данных, защитой и доступными ресурсами.

    Открыть первоисточник
  • Первичная спецификация

    OpenTelemetry Tracing SDK Specification

    OpenTelemetry · OpenTelemetry specification, checked 29 August 2026

    Определяет Sampler, ShouldSample decisions, Sampled flag propagation и deterministic probability sampling behavior.

    Открыть первоисточник
  • Официальная документация

    Sampling

    OpenTelemetry · OpenTelemetry concepts, updated 16 October 2025

    Различает sampled/not sampled traces, head и tail sampling, representativeness и operational costs sampling.

    Открыть первоисточник
  • Официальная документация

    OpenTelemetry Collector Tail Sampling Processor

    OpenTelemetry · Collector Contrib main, checked 29 August 2026; processor stability beta

    Документирует stateful grouping spans by trace ID, policy-based decisions и требование направлять все spans trace в один collector instance.

    Открыть первоисточник

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

Подтвердите действие