Как идентификатор корреляции помогает расследовать запрос, проходящий через несколько сервисов?
Идентификатор корреляции — это единое уникальное значение, которое присваивается логическому запросу и передаётся через все участвующие сервисы и асинхронные этапы. По нему можно связать разрозненные записи журналов, увидеть маршрут обработки, найти место сбоя и сопоставить действия разных компонентов.
Он не ускоряет запрос и не обеспечивает доставку сообщений. Его задача — сделать распределённое выполнение наблюдаемым и пригодным для расследования.
В монолитной системе поиск проблемы часто ограничивался одним журналом и одним процессом. При переходе к распределённой архитектуре один пользовательский запрос стал последовательно обращаться к нескольким сервисам, очередям и внешним системам, каждая из которых ведёт собственные журналы.
Обычных временных меток и текста сообщения оказалось недостаточно: несколько запросов могут выполняться одновременно, часы на узлах могут расходиться, а один сервис может генерировать множество внутренних операций. Поэтому появился практический подход с передачей общего идентификатора через границы компонентов.
Пусть клиент оформляет заказ. Запрос проходит через сервис заказа, проверку оплаты, резервирование товара и доставку. Если резервирование завершается ошибкой, без общего идентификатора аналитик вынужден сопоставлять записи по времени, идентификатору заказа и содержимому сообщений.
Такое сопоставление ненадёжно. Идентификатор заказа может отсутствовать на раннем этапе, разные попытки обработки могут иметь один бизнес-идентификатор, а асинхронная доставка может произойти значительно позже исходного запроса. Неверная корреляция приводит к ошибочному диагнозу и усложняет оценку влияния сбоя.
На входе в систему создают идентификатор корреляции, если доверенный внешний идентификатор не был передан. Далее каждый компонент извлекает его из метаданных сообщения или запроса, добавляет в свои структурированные логи и передаёт дальше без изменения.
В результате записи разных сервисов можно отфильтровать по одному значению. В журнале полезно хранить не только корреляционный идентификатор, но и имя сервиса, операцию, результат, длительность, идентификатор попытки и техническую ошибку. Бизнес-идентификатор, например номер заказа, не должен автоматически заменять корреляционный: он отвечает за объект предметной области, а не за конкретное прохождение запроса.
Важно различать correlation ID и trace ID. Корреляционный идентификатор обычно связывает логически относящиеся события, а распределённая трассировка дополнительно описывает отдельные участки выполнения — spans — и их вложенность. Один trace может содержать множество spans, тогда как простой correlation ID не обязан описывать длительность и структуру каждого шага.
Для асинхронных процессов нужно заранее определить правила наследования. Сообщение, созданное в рамках исходной операции, обычно получает исходный идентификатор корреляции, а конкретная доставка или повторная попытка дополнительно имеет собственный идентификатор. Это позволяет видеть общую цепочку и одновременно различать отдельные попытки.
Нельзя без проверки принимать внешний идентификатор как доверенный диагностический атрибут. Его следует ограничить по длине и допустимому формату, не включать в него секреты и не использовать как механизм авторизации. Иначе злоумышленник сможет засорять журналы, затруднять поиск или раскрывать чувствительные данные.
Главный компромисс — между полезностью диагностики и стоимостью наблюдаемости. Подробные логи и трассировка увеличивают объём хранения и могут затронуть персональные данные, поэтому нужны структурированный формат, правила маскирования, сроки хранения и разумная политика выборки.
В интернет-магазине пользователи иногда получали ошибку оформления заказа, хотя платежи в отдельных случаях проходили успешно. Команда рассматривала два варианта: искать связанные записи по номеру заказа и времени либо ввести единый идентификатор корреляции для синхронного запроса и последующих сообщений.
Поиск по номеру заказа был проще и почти не требовал изменений, но не различал повторные попытки и не покрывал случаи до создания заказа. Кроме того, часть внешних операций не записывала этот номер. Единый идентификатор потребовал изменить формат логов, правила передачи метаданных и обработку сообщений в очереди, зато дал устойчивую связь между всеми этапами.
Выбрали второй вариант: на входе создавался корреляционный идентификатор, он сохранялся в контексте операции, передавался в сообщения и выводился в структурированные логи. Отдельно записывался идентификатор попытки платежа. В результате команда смогла установить, что ошибка возникала после успешного платежа на этапе подтверждения заказа, и исправила обработку повторного уведомления, не меняя бизнес-идентификатор заказа.
Нет. Он позволяет связать события, но обычно не показывает причинно-следственную структуру и длительность отдельных этапов. Для полной трассировки нужны идентификатор трассы, идентификаторы spans, связи между родительским и дочерним участками, а также корректная передача контекста через синхронные и асинхронные границы.
При этом correlation ID остаётся полезным даже без специализированной системы трассировки: его можно использовать для поиска по логам и сопоставления событий, когда полная трассировка отключена, неполна или не охватывает внешнего участника.
Цепочка распадётся на независимые фрагменты. В логах каждого сервиса события будут выглядеть корректно локально, но связать исходный запрос с последующими действиями станет невозможно или придётся использовать ненадёжные косвенные признаки.
Новые идентификаторы допустимы для отдельных технических операций, например для попытки доставки или внутренней задачи, но исходный идентификатор нужно сохранить как родительский контекст. В документации интеграции следует явно указать, какие поля передаются неизменными, а какие создаются заново.
Обычно нельзя. Корреляционный идентификатор описывает принадлежность событий одной логической цепочке и может быть общим для нескольких действий или повторных попыток. Идемпотентность требует определить, какие повторения считаются одной операцией, как долго хранится ключ и какой результат возвращается при повторе.
Если заменить один механизм другим, повторная обработка может либо ошибочно подавляться, либо выполняться несколько раз. Поэтому для диагностики используют correlation ID, для защиты конкретной операции от повторного применения — отдельный идемпотентный ключ, а для трассировки выполнения — специализированный контекст трассы.