Модуль 18 ⏱ ~14 мин чтения 📐 1 Mermaid диаграмм

4. Noise vs signal

Соотношение сигнала и шума: культура устойчивого мониторинга

«Умение упрощать — значит устранять ненужное, чтобы необходимое заговорило в полный голос».
— Ханс Хофман

В предыдущей статье мы настроили инфраструктуру алертинга: связали Prometheus с Alertmanager и научились писать правила оповещений. Однако здесь системную инженерию подстерегает тонкая грань, отделяющая надежную систему телеметрии от назойливого генератора спама.

Если дежурный инженер получает за ночную смену пятьдесят оповещений в мессенджер, а утром механически смахивает их все в корзину — ваша Observability полностью сломана. Команда оказывается во власти тяжелейшей инженерной патологии — Alert Fatigue (Усталости от уведомлений).

Фундаментальная задача зрелой Observability — не собрать максимум терабайтов сырых данных, а максимизировать отношение Сигнала к Шуму (Signal-to-Noise Ratio, SNR).

Проблема информационного шума

В теории информации Клода Шеннона сообщение полезно лишь в той степени, в которой оно уменьшает неопределенность получателя. Если система непрерывно шлет однотипные сообщения о нормальных колебаниях нагрузки, неопределенность не уменьшается — она многократно возрастает. Инженеры теряют способность отличать штатные переходные процессы от надвигающейся катастрофы.

Сигнал vs Шум: Определения

  • Сигнал (Signal): Информация, требующая действия. Это аномалия, которая влияет на бизнес или пользователей, и требует вмешательства инженера.
  • Шум (Noise): Информация, не требующая действий. Это нормальная вариативность работы системы, известные проблемы или просто лишние данные.

Источники шума

В распределенных бэкенд-системах шум возникает по трем главным причинам:

1. Нормальная вариативность (Flapping)

Метрики в реальном мире "скачут". CPU может кратковременно подпрыгнуть до 100% при сборке мусора или старте приложения. Если вы поставите алерт cpu > 80%, вы получите бесконечный шум.

Это явление называется флаппингом (Flapping) — значение колеблется вокруг пороговой границы, вызывая каскад открытий и закрытий алерта.
Решение: Использование функций сглаживания (rate(), avg_over_time()) и задержки (for: 5m).

2. Мониторинг "Причин" вместо "Симптомов"

Алерт "CPU High" сам по себе — это шум. Это техническая метрика. Пользователь не видит CPU.
Алерт "High Latency" (высокая задержка) — это сигнал. Это симптом.
Правило: Алерты должны строиться вокруг того, что чувствует пользователь (SLO), а не вокруг того, что "чувствует" сервер.

Сервер с 95% утилизацией процессора может великолепно справляться с потоком запросов, отдавая их за 15 миллисекунд. Будить инженера из-за того, что процессор честно выполняет свою работу — абсурд.

3. High Cardinality в неправильном месте

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

Инженерные методы фильтрации

Как превратить сырой поток данных в чистый сигнал?

flowchart TD
    A["Raw Telemetry<br>Сырые данные"] --> B["Sampling & Filtering<br>Семплирование"]
    B --> C["Aggregation<br>Агрегация"]
    C --> D["Threshold & SLO<br>Пороги и цели"]
    D --> E["Signal<br>Уведомление"]

    subgraph "Noise Sources"
        N1["Network Blips<br>Микро-сбои сети"]
        N2["GC Pauses<br>Сборка мусора"]
        N3["Known Issues<br>Известные баги"]
    end

    A --> N1
    N1 -.->|"Filtered"| B

    style A fill:#1e293b,stroke:#38bdf8,stroke-width:2px,color:#fff
    style E fill:#881337,stroke:#f43f5e,stroke-width:2px,color:#fff
    style Noise Sources fill:#0f172a,stroke:#475569,stroke-width:1px,color:#fff

1. Семплирование (Sampling) в Трейсинге

Вам не нужно сохранять 100% трейсов, чтобы понять, что система работает медленно.

  • Head-based Sampling: Решение о записи трейса принимается в начале запроса (например, записываем 1% запросов).
  • Tail-based Sampling: (Продвинутый уровень) Записываем 100% запросов в память, но сохраняем в базу только те, которые:
    • Длились дольше N секунд.
    • Закончились ошибкой (Status Code 500).
    • Содержат конкретный error тег.

Это позволяет видеть "сигнал" (ошибки и тормоза) и игнорировать "шум" (успешные быстрые запросы), экономя деньги на хранении.

В OpenTelemetry Collector компонент tail_sampling буферизует спаны в оперативной памяти до завершения всего трейса и сохраняет только проблемные ветви.

2. Окна агрегации (Time Windows)

Никогда не алертуйте на мгновенное значение (cpu_now). Всегда используйте окно.

PROMQL 
# Шумно: Среагирует на любую секундную вспышку
rate(http_requests_total[10s])

# Чисто: Сглаживает пики и показывает реальный тренд
rate(http_requests_total[5m])

Оконная функция работает как цифровой фильтр низких частот (Low-Pass Filter), отсекая высокочастотный дребезг и пропуская истинный направленный тренд.

3. Дедупликация и Группировка

Когда падает кластер из 50 подов, вам не нужно получать 50 алертов в Slack.
Alertmanager (который мы обсуждали в прошлой статье) должен сгруппировать их в один:
Alert: ServiceDown. Instances: 50. Это сигнал. 50 отдельных сообщений — это шум.

Mechanical Sympathy: CPU и "Счастливые ушки"

Существует когнитивная ошибка, называемая "Happy Ears" (Счастливые ушки). Мы склонны настраивать мониторинг так, чтобы графики были зелеными и красивыми, игнорируя реальные проблемы.

Например, вы можете настроить for: 30m, чтобы алерт срабатывал очень редко. Шума нет, "уши счастливы". Но в это время пользователи могут страдать от периодических 5-секундных задержек, которые "прыгают" и не держатся 30 минут.

Баланс: Настройка порогов — это итеративный процесс.

  1. Начните с чувствительных настроек.
  2. Если приходит шум — анализируйте.
  3. Если шум не важен — поднимите порог или добавьте ignore правило.
  4. Повторяйте, пока поток алертов не станет равен количеству реальных инцидентов.

Итог

  1. Цель Observability — доставить сигнал, а не данные.
  2. Шум убивает доверие к мониторингу. Лучше один пропущенный алерт, чем 100 ложных срабатываний.
  3. Используйте SLO-based alerting (алерты по целям), чтобы фокусироваться на проблемах пользователей, а не серверов.
  4. Tail-based sampling — мощный инструмент для сбора полезного сигнала (ошибок) в трейсинге без захламления базы.

В следующей статье мы рассмотрим специфику запуска всех этих систем в среде Kubernetes: 5. Observability в Kubernetes.