Observability: metrics, logs и tracing¶

Раздел 04 · Типы достоверности

Тип материала: инженерный разбор. Схемы и примеры иллюстративные. Рекомендации — INFERENCE; учебные параметры — HYPOTHETICAL.

Проверка источников: 2026-11-02. Версии и границы первоисточников перечислены в конце. Documented contracts не означают выполненный runtime test.

Принцип работы и границы¶

Наблюдаемость должна отвечать, принят ли вход, где находится durable progress и какие бизнес-инварианты нарушены. Metrics показывают агрегированный симптом, logs сохраняют события и решения, traces связывают путь исполнения. Эти сигналы описаны в OpenTelemetry; sampling означает, что trace не является полным audit ledger.

INFERENCE: различайте transport lag, oldest unprocessed age, accepted→effect delay, checkpoint age, source retention headroom, DLQ debt и reconciliation exceptions. Для counters указывайте границы: attempts, unique accepted commands и committed effects — разные denominators.

Log event содержит operation_id, event_id, tenant-safe reference, partition/offset, state generation, decision и error class. Не вставляйте payment payload/PII в labels. High-cardinality идентификаторы пригодны для защищённых logs/traces, но плохо подходят для time-series labels.

Иллюстративная архитектура¶

flowchart LR
 P[Pipeline boundaries] --> M[Metrics with bounded labels]
 P --> L[Redacted structured logs]
 P --> T[Sampled traces]
 M --> A[Alerts and runbook]
 L --> I[Incident evidence]
 T --> I
 A --> I

Failure scenarios¶

Consumer lag ноль, но половина входов в quarantine. Histogram измеряет только успешные запросы и скрывает timeouts. Trace теряется при asynchronous queue boundary. Monitoring pipeline недоступен одновременно с production, и absence of metrics ошибочно принимают за здоровье.

Recovery protocol¶

Проверить сам сбор telemetry независимым heartbeat и freshness index.
Коррелировать accepted/effect/rejected/unresolved counts по тому же cut.
Определить последнюю здоровую boundary по durable evidence, а не только trace.
Приложить offsets/generation и redacted logs к incident; перейти к конкретному recovery runbook.
После восстановления проверить business reconciliation, а не закрывать incident по CPU/lag.

Trade-offs и критерии выбора¶

Подробные logs облегчают расследование, но увеличивают PII risk и storage cost. Tail sampling сохраняет ошибки, но не даёт complete ledger. SLO по freshness может конфликтовать с gate, защищающим correctness; отдельные статусы degraded/incomplete нужны клиенту.

FinTech и iGaming¶

Для settlement alarm нужен unresolved amount по currency и возраст exception, а не только message rate. Для antifraud feature completeness и watermark age важнее зелёного health endpoint. Tracing не должен раскрывать PAN или документы KYC.

Практический пример¶

Учебный alert contract: если source принят, но effect не виден после policy-defined deadline, открыть exception с operation_id и authoritative status. Число секунд зависит от продукта и здесь не задаётся как SLA. Добавьте dashboard для восьми строк failure matrix.

Типичные ошибки проектирования¶

Логировать только exceptions без outcome; offsets без topic/generation; operation_id в metric labels; считать tracing юридически достаточным аудитом; алертить lag без retention headroom.

Вопросы на собеседовании¶

Как увидеть silent data loss? Независимые accepted/effect counts, key-level сверка и source completeness checks.

Почему traces недостаточно для аудита? Sampling, retention и mutable storage не гарантируют полноты и целостности evidence.

Дополнительные источники¶

OpenTelemetry signals — rolling; conceptual.