📊 Наблюдаемость

Короткий ответ На входе генерируют или подхватывают request id, кладут его в контекст логирования (contextvars) и передают дальше в заголовках при межсервисных вызовах; каждая запись лога формируется в JSON с этим id, что позволяет в системе агрегации отфильтровать все записи одного запроса по всем сервисам. Как это работает подробнее middleware на входе проверяет заголовок или генерирует UUID, сохраняет в contextvars.ContextVar, доступный во всех корутинах обработки запроса; фильтр логирования добавляет значение из контекста в каждую запись. Пример кода Что использовать на практике Рекомендация. JSON-формат даёт возможность индексировать поля (request_id, user_id, duration_ms) и строить дашборды/алерты по ним; при вызове другого сервиса request id передают в заголовке, чтобы его подхватил downstream-сервис. Подводные камни Риск. генерировать request id на каждом сервисе независимо, не передавая его дальше; использовать threading.local в асинхронном коде вместо contextvars — один поток обслуживает множество к

Читать полностьюcorrelation-id

Короткий ответ Типичный набор: counter http_requests_total для количества запросов и ошибок, histogram http_request_duration_seconds для latency с перцентилями, gauge db_connection_pool_in_use для занятости пула соединений, и бизнес-метрики типа counter orders_created_total. Как это работает подробнее counter — монотонно растущее значение, удобно для вычисления rate() за интервал; gauge — произвольно растущее/убывающее текущее значение; histogram распределяет наблюдения по бакетам и позволяет вычислять перцентили через histogram_quantile. Пример кода Что использовать на практике Рекомендация. latency лучше измерять histogram, а не average — среднее скрывает длинный хвост медленных запросов; по counter с лейблом status считают error rate для алертов SLO; gauge пула соединений помогает заметить приближение к исчерпанию до таймаутов. Подводные камни Риск. заводить лейбл с высокой кардинальностью (например, user_id) — взрывной рост числа временных рядов; мерить latency как gauge вместо histogram, что не даёт перц

Читать полностьюdistributed-systems

Короткий ответ Схема должна передавать context через W3C Trace Context заголовки между всеми сервисами и применять sampling — например, 100% для ошибок и медленных запросов, но лишь небольшой процент для обычных успешных; точный процент зависит от объёма трафика и бюджета на хранение. Как это работает подробнее OpenTelemetry SDK создаёт spans в каждом сервисе; context propagation передаёт trace id и флаг сэмплирования в заголовках следующего вызова — решение принимается либо один раз на входе (head-based), либо коллектором после сбора всех spans (tail-based, требующий буферизации). Пример кода Что использовать на практике Рекомендация. head-based проще и дешевле, но может не засэмплировать редкую важную ошибку; tail-based через Collector с политикой «сохранить трассу при ошибке или высокой latency» даёт лучшую видимость, но требует дополнительной инфраструктуры. Компромисс. высокий процент сэмплирования даёт полную видимость, но дорог в хранении; низкий процент дешевле, но рискует упустить редкие инциденты бе

Читать полностьюdistributed-systems

Короткий ответ Восстановление начинают с метрик (когда начался рост latency/error rate и что предшествовало), сужают через логи ошибок за этот период и трассировки конкретных запросов, затем формулируют точную последовательность событий, корневую причину и конкретные action items с владельцами и сроками. Как это работает подробнее метрики дают общую картину «что» и «когда»; логи дают «что конкретно пошло не так» на уровне исключений; трассировки показывают «где в цепочке вызовов» возникла задержка — вместе они восстанавливают причинно-следственную цепочку, а не только симптом. Пример кода Что использовать на практике Рекомендация. полезно сопоставить timeline с историей деплоев; 504 часто коррелируют с насыщенностью пула соединений к БД/внешнему сервису; самовосстановление за 20 минут может указывать на временную перегрузку, рассосавшуюся после снижения трафика. Компромисс. глубокое расследование с привлечением нескольких команд даёт точную корневую причину, но занимает больше времени; быстрый поверхностный р

Читать полностьюdistributed-systems