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

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

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

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

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

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

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

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

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

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

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

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

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