Отслеживание в отключенных системах

Я знаю, что существуют библиотеки для отслеживания запросов в распределенных системах на основе OpenTracing и OpenTelemetry; все они работают, потому что запросы связаны / связаны (микросервисы разговаривают друг с другом). Как отследить, когда системы / службы отключены?

Служба X вызывает службу Y. Y выполняет некоторую обработку, а затем записывает в общую папку. Компонент Z опрашивает совместно используемое местоположение (через час) и выполняет обработку.

Я хочу знать, есть ли для каждого запроса, сгенерированного X, статус в каждой из этих 3 систем.

Простой способ отслеживать это - иметь таблицу и обновлять записи в БД. Однако, учитывая тот факт, что мне может потребоваться повторить определенные действия, я подумал о внедрении механизма рабочего процесса (Cadence), который открывает рабочий процесс в Службе X. Затем в каждой из Служб рабочий процесс обновляется. Если запрос достигает Y, шаг в ж / д завершается. Если он не достигает Z, рабочий процесс остается открытым, и через некоторое время я могу сгенерировать электронное письмо и т. Д., В котором говорится, что рабочий процесс не удался.

Мне нужна помощь, чтобы понять, правильный ли это способ и / или другие методы для этого.


distributed-tracing cadence-workflow data-tracing
person Magellan    schedule 05.03.2021    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Это один из наиболее типичных вариантов использования Cadence Workflow. Рекомендуемое решение - позволить сервису X запустить рабочий процесс. Он выполнит действие по вызову службы Y. Если возможно, позвольте компоненту Z отправить сигнал к рабочему процессу, сообщающий, что обработка завершена. Или у вас может быть другое действие, чтобы продолжить опрос статуса.

Обратите внимание, что retry можно легко отключить для действий, поддерживаемых Cadence.

Затем используйте таймер в рабочем процессе, чтобы инициировать действие по отправке электронной почты.

Наконец, статус этого рабочего процесса остается локальной переменной рабочего процесса. Вы можете реализовать обработчик Query в рабочем процессе для получения статуса. Или вы можете реализовать фоновую активность, чтобы заранее сообщать о прогрессе.

Фреймворк открытой библиотеки трассировки предназначен для решения другой проблемы. Это для измерения и анализа зависимости и задержки сервисов. Фактически, рабочий процесс Cadence также поддерживает открытую трассировку: пример. Это для уровня обслуживания, а не для конкретных запросов или обработки.

person Long Quanzheng    schedule 09.03.2021
comment
Я забыл упомянуть явно, но мне также нужно получить общую задержку; например, когда запрос инициируется в X, сколько времени нужно, чтобы добраться до Z. Спасибо. - person Magellan; 10.03.2021
comment
Есть несколько способов сделать это. В рамках рабочего процесса Вы можете получить текущую временную метку любого шага с помощью API Workflow.Now (). Если Z - это отдельный компонент, которому нужно отправить сигнал обратно, пусть он отправит объект с меткой времени в нем. Таким образом, вы можете использовать метку времени для расчета времени, необходимого для достижения Z. Или In Z запросите время начала и выполните вычисления. Если Z также является активностью рабочего процесса, вы также можете использовать открытую платформу трассировки. - person Long Quanzheng; 10.03.2021
comment
Каденция также выделяет множество стандартных показателей, таких как рабочий процесс и задержка активности. Вы можете получить их бесплатно - person Long Quanzheng; 10.03.2021