Спроектируйте систему мониторинга и алертинга для продакшена: метрики, логи, трейсы. Как не утонуть в алертах?
Короткий ответ
- Три сигнала: метрики, логи, трейсы — связанные общими идентификаторами
- Метрики: Prometheus плюс долгое хранилище (Thanos/Mimir)
- Логи: структурированные, в Loki или Elasticsearch
- Трейсы: OpenTelemetry, Tempo/Jaeger, связка с логами по trace id
- Алерты — на симптомы по SLO и burn rate, не на каждую причину
- Каждый алерт — actionable, с severity и runbook
- Дашборды по методам RED и USE
Observability строится на трёх связанных сигналах, а защита от шума — алерты только на симптомы, завязанные на SLO.
Как сказать вслух
пример ответаЯ строю наблюдаемость на трёх сигналах. Метрики собирает Prometheus с долгим хранилищем, по ним — дашборды и алерты. Логи пишем структурированно в JSON и складываем в Loki, трейсы собираем через OpenTelemetry, и всё связываем общим идентификатором запроса, чтобы от алерта дойти до конкретного трейса и строк лога. Чтобы не утонуть в алертах, бужу людей только по симптомам для пользователя — росту ошибок и латентности относительно SLO, — а не по каждому скачку CPU. И у каждого алерта должен быть runbook: если по нему нечего делать, это не алерт.
Подробный ответ
Основной ответ
Метрики: Prometheus (или совместимый стек) со service discovery, экспортеры для инфраструктуры, инструментирование приложений; долгосрочное хранение и глобальный обзор — Thanos/Mimir/VictoriaMetrics; дашборды в Grafana по RED (rate, errors, duration) для сервисов и USE для ресурсов. Логи: структурированный JSON, сбор агентом (Fluent Bit/Vector) в Loki или Elasticsearch, с лейблами окружения и сервиса. Трейсы: OpenTelemetry SDK и Collector, бэкенд Tempo/Jaeger; корреляция через trace id в логах и exemplars в метриках. Алертинг: симптомные алерты по SLO с multi-window burn rate — пейджер; причинные (диск, сертификаты) — тикеты; маршрутизация и дедупликация в Alertmanager, эскалации в on-call-инструменте. Гигиена: каждый алерт имеет владельца, severity и runbook; регулярный разбор шумных алертов; детекция «тихих» отказов через синтетические проверки (blackbox).
Ключевые моменты
- Корреляция сигналов. Trace id связывает метрики, логи и трейсы — от алерта до причины за минуты, а не часы.
- Симптомы, не причины. Пейджер — только за деградацию пользовательского опыта; причинные алерты идут тикетами в рабочее время.
- Burn rate по SLO. Многооконные правила сжигания бюджета дают чувствительность без шума единичных всплесков.
- Гигиена алертов. Runbook, владелец и регулярная чистка шумных правил — иначе наступает alert fatigue и пропуск реальных инцидентов.
Практический контекст
Такой дизайн спрашивают на senior SRE/DevOps-позициях, часто с уточнениями: «а если сервисов 200», «а как поймать проблему, о которой молчат метрики». На практике главная боль — не сбор данных, а шум: типичная зрелая команда приходит к симптомным алертам после периода, когда on-call будили по десять раз за ночь. Интервьюер оценивает, есть ли у кандидата эта выстраданная логика, а не просто список модных инструментов.
Частые ошибки
- Предлагают алертить на каждую метрику — CPU, память — вместо симптомов для пользователя
- Строят три независимых стека без корреляции по trace id
- Не упоминают runbook'и, severity и процесс борьбы с шумными алертами