System Design Space

    Глава 152

    Обновлено: 15 февраля 2026 г. в 23:20

    Observability & Monitoring Design

    Прогресс части0/13

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

    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