Трейсинг через OpenTelemetry

«Запрос создаёт заказ 17, сохраняет его и ставит задачу; потребитель начинает через 4 секунды и работает 200 мс. Нужно различить очередь и обработку». Попросите схему spans и необходимые временные наблюдения. Один span потребителя на 200 мс не объясняет полную задержку пользователя. При этом реальные часы разных процессов и семантику измерений нужно согласовать, прежде чем делать выводы.

Контекст может не передаваться в метаданных сообщения, не извлекаться у потребителя или теряться при создании задачи. Покажите обе стороны публикации и обработки. Попросите способ стандартной передачи вместо общей глобальной переменной. Для пакетной обработки и повторов иногда нужны links, а не единственный родитель; схема должна отражать реальные связи, не обещая одну и ту же иерархию для любых сценариев.

Нет, большое число мелких spans может скрыть важную операцию и увеличить стоимость телеметрии. Проверьте автоматическое покрытие HTTP и базы, затем добавьте ручные бизнес-границы. Для учебного заказа полезнее видеть проверку доступности, запись и публикацию, чем каждый вызов помощника. Попросите объяснить, какой диагностический вопрос решает каждый новый span и какие атрибуты действительно помогают на него ответить.

На результат влияют выборка, ограничения экспорта и потери доставки. Согласуйте политику sampling и наблюдение за самим экспортёром. Не записывайте тела запросов и токены ради удобства поиска; используйте допустимые идентификаторы и типы операций. Енотик подготавливает схему, но не видит вашу систему трассировки: проверьте одну известную учебную цепочку и её повтор, сопоставив события с логами и метриками.