System Design Space
Граф знанийНастройки

Обновлено: 24 марта 2026 г. в 15:23

Observability & Monitoring Design

medium

Практический дизайн observability-платформы: логи, метрики, distributed tracing, SLO-based alerting, runbooks и feedback loop для production.

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

Логи, метрики, tracing, SLO-based alerting, runbooks и feedback loops здесь собраны в одну диагностическую платформу, которая помогает не просто заметить сбой, а быстро пройти путь от симптома к причине.

В design review глава особенно полезна, когда нужно говорить о signal quality, cardinality cost, alert fatigue и том, какие данные действительно сокращают время расследования.

Практическая польза главы

Практика проектирования

Переводите знания о архитектуре observability и проектировании мониторинга под SLO в конкретные эксплуатационные решения: интерфейсы алертинга, runbook-границы и rollback-стратегии.

Качество решений

Оценивайте архитектуру через SLO, error budget, MTTR и устойчивость critical-path, а не только через функциональную полноту.

Interview articulation

Структурируйте ответ вокруг reliability lifecycle: сигнал деградации, реакция, локализация причины, восстановление и профилактика повторов.

Trade-off framing

Явно фиксируйте компромиссы по архитектуре observability и проектировании мониторинга под SLO: скорость релизов, уровень автоматизации, стоимость observability и операционная сложность.

Core Source

Site Reliability Engineering

Четыре золотых сигнала, SLI/SLO и подходы к наблюдаемости production-систем.

Открыть главу

Observability & Monitoring Design отвечает на практический вопрос: как построить систему наблюдаемости, которая помогает принимать решения во время инцидента, а не просто копит дашборды. Дизайн observability включает сигналы (logs/metrics/traces), pipeline их доставки, SLO-aware alerting, runbooks и операционный цикл улучшений после каждого сбоя.

Четыре опоры production-observability

Логи

События и контекст для расследования инцидента.

  • Структурированный JSON-формат вместо free-form текста.
  • Корреляционные поля: trace_id, span_id, request_id, user_id.
  • Явное разделение уровней: info/warn/error/fatal и бизнес-ошибок.

Метрики

Числовые временные ряды для SLO, capacity и раннего детекта деградаций.

  • Базовые фреймворки: RED (Rate, Errors, Duration) и USE (Utilization, Saturation, Errors).
  • Контроль кардинальности label-ов (особенно user_id, path, tenant).
  • Отдельные метрики для бизнес-фаннела и технического слоя.

Distributed Tracing

End-to-end путь запроса через сервисы, очереди и базы.

  • Propagation контекста между sync/async границами (HTTP, gRPC, Kafka).
  • Sampling-стратегия: tail sampling для редких ошибок и high-latency запросов.
  • Связка trace + logs + metrics для быстрого root-cause анализа.

Alerting

Правила, которые будят только по реально важным отклонениям.

  • Алерты от SLO/error budget burn-rate, а не только от CPU/RAM.
  • Разделение severity (page/ticket/info) и четкие маршруты эскалации.
  • Каждый page-alert сопровождается runbook-ссылкой.

Deep dive в логи, метрики, трейсы и алертинг

Логи: от forensic-разбора к операционной диагностике

Логи нужны для объяснения конкретного события: кто вызвал, что пошло не так, на каком шаге и с каким контекстом.

Must-have

  • Единый JSON-формат и стабильная schema-version.
  • Корреляция по trace_id/span_id/request_id для склейки с tracing.
  • Явные domain-поля: operation, tenant, entity_id, outcome, error_code.

Дизайн решения

  • Делайте семплирование info/debug на ingest-уровне, а не в приложении.
  • PII/секреты маскируются до отправки в лог-пайплайн.
  • Отделите security/audit логи от продуктовых для разных retention и доступа.

Типичные ошибки

  • Сырые stacktrace без контекста операции и входных параметров.
  • Free-form строки без machine-parse friendly полей.
  • Логирование всех событий без budget на storage и query latency.

Пример структурированного log-event

{
  "ts": "2026-02-15T06:00:00Z",
  "level": "error",
  "service": "checkout-api",
  "operation": "CreateOrder",
  "trace_id": "6c5f...",
  "request_id": "req-1942",
  "tenant": "acme",
  "error_code": "PAYMENT_PROVIDER_TIMEOUT",
  "duration_ms": 1840
}

Reference pipeline: от сигнала до реакции

1. Instrumentation

Код и инфраструктура публикуют telemetry через OpenTelemetry SDK/collector.

2. Collection & Transport

Агенты/коллекторы нормализуют сигналы и доставляют в хранилища без потерь.

3. Storage

Раздельные backend-и для logs/metrics/traces с retention-политиками по стоимости.

4. Query & Correlation

Единая навигация между графиком, trace и логами по общим идентификаторам.

5. Alert & Response

Алерты запускают on-call процесс: triage -> mitigation -> postmortem.

Practice

Troubleshooting Example

Пошаговая диагностика инцидента с применением RED + логов и гипотез.

Открыть кейс

Alerting без шума: дизайн правил

5-15 минут

Fast burn-rate

Быстро поймать критичный outage и сократить MTTR.

Высокий burn-rate error budget за короткое окно.

1-6 часов

Slow burn-rate

Зафиксировать длительную деградацию качества до полного отказа.

Устойчивое отклонение latency или availability от SLO.

15-60 минут

Business anomaly

Увидеть impact на продукт до обращения клиентов.

Падение конверсии / всплеск неуспешных платежей / drop по ключевому funnel.

Минимальная договоренность для команды: у каждого page-alert должен быть owner, runbook и postmortem action item. Без этого alerting быстро превращается в noise.

References

Связанные главы

Чтобы отмечать прохождение, включи трекинг в Настройки