Как мы прослеживаем наш выход, используя Event-Tracing

Трассировка событий — это одна из тех тем, эффективность которых мы осознаем, но всегда уделяем ей низкий приоритет. Добавление трассировки к вашим потокам и архитектуре (в основном эффективно в экосистеме микросервисов) чрезвычайно важно, чтобы найти свои руки и ноги, когда нужно отлаживать или управлять кризисными происшествиями.

Сценарий: у нас есть несколько потоков в нашей системе микросервисов. Каждый поток имеет начальную и несколько конечных точек в зависимости от потока.

К сожалению, одна из наших служб вышла из строя, и поток не завершился, как ожидалось -> Boom -> Оповещения поднимаются, во всех журналах выполняются исключения, с чего нам начать? Что вызвало проблемы или какой запрос вызвал эту проблему? Итак, что мы делаем в первую очередь?

Вероятно, вы используете фреймворк агрегатора логов (стек ELK и т.д.). Мы сортируем логи по сервисам и времени и теперь начинаем выяснять, что произошло. На данный момент мы все еще изо всех сил пытаемся увидеть какую-либо ясность. Когда у вас есть несколько сложных потоков и путей, мы не можем точно сказать, какая цепочка событий привела к этой проблеме. Да, мы можем начать использовать временные метки и да, мы можем начать рисовать сценарии архитектуры (я помню те обсуждения: «Эй, вы помните, что у нас был поток A, который запускался, когда поток B заканчивался, но в качестве альтернативы он мог запускать поток C, если эти условия выполнялись??») выяснить, чтобы найти наш путь. Не обращая внимания, вы начинаете вести себя как «Гензель и Гретель», пытаясь найти свои хлебные крошки в лесу.

Отслеживание может облегчить вашу жизнь. Особенно в кризисные времена, когда моменты находятся под давлением. Итак.. «Сохраняйте спокойствие и смотрите на свой след»

Если бы вы могли нарисовать свой маршрут движения (как это делает GPS в самолете), вы могли бы легко отслеживать и решать проблемы.

Добавить систему трассировки к вашим компонентам несложно, но она должна быть последовательной и методологической. Чем раньше вы примените его стандарт, тем легче будет его внедрить.

Трассировка становится все более и более популярной по мере того, как сложные системы обнаруживают свою эффективность. Сегодняшняя проблема заключается в том, что у нас разные поставщики фреймворков трассировки, и у нас нет настоящего стандарта. Однако в настоящее время у W3C есть постоянный кандидат на стандарты трассировки:

Я буду держать это простым для вас.

Трассировка объединяет 3 основных ключевых значения:

Идентификатор корреляции:
параметр, указывающий полный поток трассировки (будет передаваться от одного сервиса к другому) — создается после запуска потока
Родительский идентификатор:
параметр, указывающий, откуда пришел запрос (кто мне звонил?) — передан предыдущим процессом
Идентификатор события:
параметр, который используется внутри области службы/процесса — создается как подзапрос
Эти параметры должны использоваться и/или создаваться для каждой вашей «точки входа» в рамках вашего сервиса/процесса.

Преимущество отката:

Трассировка позволяет вашей архитектуре откатить кросс-сервисную операцию.

Я упомянул параметр Correlation-Id. Поскольку идентификатор корреляции передается между одним процессом другому, вы можете использовать его как уникальный идентификатор агрегатора для «транзакции». Если вам нужно откатить состояние/транзакцию во всех ваших службах, просто укажите корреляцию, и ваши службы должны быть достаточно умны, чтобы откатить операцию (в следующем посте я подробно покажу возможные способы, как это сделать)

Преимущество повторной попытки:

Трассировка даст вам возможность повторить определенные события. Предположим, у вас есть транзакция, проходящая через все ваши сервисы. Но, к сожалению, одна из служб прекратила работу (по какой-то причине). Теперь ваша система находится в состоянии, которое я называю «половина готового состояния», когда часть ваших служб применяет транзакцию, а другие нет. Поскольку трассировка получила идентификатор события (упомянутый выше), вы можете указать конкретной службе повторить попытку (после восстановления) неудачной транзакции и выполнить выравнивание.

Другие преимущества отслеживания:

Различайте разные пути в вашем потоке (без использования временных меток или архитектурного мышления)
Трассировка источника данных: если вы используете уникальный идентификатор для записи транзакции источника данных, вы можете использовать идентификатор события. Это расширит ваш общий путь к вашим записям источников данных (позже корреляцияId будет отображать все связанные идентификаторы событий, которые в конечном итоге будут отображать все затронутые записи в разных источниках данных
Контролируйте компоненты в целом. Поскольку у вас есть CorrelationId, который является тем же значением, которое используется во всех участвующих компонентах, вы можете отслеживать и устранять нежелательные действия.
Ориентированной на клиента. Вы всегда можете вернуть своему клиенту идентификатор корреляции и использовать его позже, если возникнут какие-либо проблемы, связанные с бизнесом или не связанные с бизнесом. Будет легче отслеживать поток, оглядываясь на присвоенный идентификатор корреляции.
Как вы можете заметить, преимущества огромны.

Мой совет: применяйте трассировку как можно раньше. Это может быть настоящей болью, когда ваша система становится сложной и широкой.

В следующем посте я рассмотрю пару поставщиков трассировки и объясню, как мы применяем трассировку в наших компонентах и ​​какие фреймворки мы использовали для их визуализации.

взято из моего блога по адресу:

Ваше здоровье,

Если