Запрос трассировки корреляции цепочки вызовов и журнала

Я полагаю, что после долгого отпуска вы, пропустившие Alipay China Koi, должны были вернуться к работе. Хотя легко пропустить глобальный бесплатный подарочный пакет, не расстраивайтесь. Редактор тайно подготовил для вас секретный рецепт, который поможет вам успешно контратаковать и выиграть годовой бонус за последние три месяца 2018 года. В этом месяце редактор поможет вам понять технологию цепочки вызовов UAVStack и описать происхождение, реализацию, применение и ключевые технологии технологии цепочки вызовов. Внимательно изучите каждый толчок этого месяца, возможно, кои награды в конце года - это вы~~~ поторопитесь и введите текст

В последние годы в мониторинговом сообществе стал популярен термин «наблюдаемость». Автор рассматривает Observability как концепцию, надмножество мониторинга, охватывающее мониторинг, агрегацию журналов и распределенную трассировку, позволяющую более глубокое наблюдение за системой в реальном времени. В этой статье рассказывается об объединении журналов, распределенной трассировке и связанных с ними приложениях.

Ассоциация цепочки вызовов с агрегацией журналов

Появление микросервисов, облачных и контейнерных архитектур изменило то, как мы строим системы. Приложения распределены и быстро меняются, базовая инфраструктура и сетевые службы становятся все более надежными. Большая часть ежедневной работы по эксплуатации и обслуживанию системы будет сосредоточена на прикладном уровне или сложных интерактивных вызовах между различными приложениями.

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

Цепочка вызовов фокусируется на полном процессе вызова запроса. Когда степень детализации достигает определенного узла, журнал, распечатываемый самой прикладной системой, может лучше всего описать логику обработки текущего узла.

На следующей диаграмме показано, как связаны цепочка вызовов и объединение журналов.

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

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

Традиционный метод обработки часто требует многократного переключения между цепочкой вызовов и агрегацией логов, то есть после обнаружения проблемы в цепочке вызовов необходимо переключиться на агрегацию логов, запросить соответствующую информацию журнала по определенным атрибутам и вернуться к цепочке вызовов после проверки информации журнала Запрос информации цепочки вызовов, связанной с информацией журнала... и так много круговых поездок.

Для этого классического сценария ассоциативный запрос отслеживания журналов и цепочек вызовов предоставляет новый режим обработки с обратной связью:

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

взять каштан

С помощью поиска по агрегации журналов пользователь Сяомин обнаружил, что журнал системы А был ненормальным. На этом этапе Сяо Мин может найти соответствующий вызывающий процесс через эту ассоциацию журнала. Наблюдая за цепочкой вызовов a, Сяо Мин обнаружил, что исключение было вызвано тайм-аутом узла a[2] в цепочке вызовов a. Теперь Сяо Мин может связать содержимое журнала, относящееся к узлу a[2], из цепочки вызовов, чтобы определить проблему (подробности см. в разделе «Эффект отображения» ниже).

Общий архитектурный дизайн

1. Сбор данных:

Агенты развертываются на машинах в кластере приложений для сбора и загрузки данных, зонды встраиваются в контейнеры (Tomcat и т. д.) для профилирования приложений и сбора информации о приложениях.

2. Передача данных:

Агент отправляет обработанные журналы на сервер мониторинга через MQ.

3. Обработка и хранение данных:

Сервер мониторинга обрабатывает собранные данные и сохраняет их в ЭС, что удобно пользователям для быстрого поиска по конкретным признакам.

4. Отображение данных:

Визуально отображайте данные и предоставляйте удобные визуальные настраиваемые службы запросов.

Реализация

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

1. Технология перехвата промежуточного ПО:

Техника, которая динамически внедряет собственное поведение кода в различные варианты поведения промежуточного программного обеспечения при запуске промежуточного программного обеспечения. Например, при запуске Tomcat перехват кода динамически добавляется в начале обработки запросов Tomcat, поэтому такие функции, как портреты вызовов службы, могут быть реализованы до того, как Tomcat выполнит логику запроса на обработку. Дополнительные возможности и методы реализации см.Ненавязчивый мониторинг службы приложений практики управления службами JAVA.

2. идентификатор трассировки:

Благодаря технологии перехвата промежуточного программного обеспечения идентификатор, который может однозначно определить цепочку вызовов, генерируется в авангарде вызова службы.

Основная логика реализации:

При запуске контейнера приложения используйте технологию перехвата промежуточного программного обеспечения, чтобы добавить точки перехвата в записи вызова службы и записи файла журнала приложения.
Когда происходит вызов службы, сгенерируйте метаданные и контекст цепочки вызовов.
Когда приложение записывает журнал, оно получает контекст цепочки вызовов текущего вызова через точку перехвата записи в файле и записывает traceId и журнал приложения в файл журнала приложения.
Сбор журналов объединяет сгенерированные файлы журналов и отправляет их на сервер мониторинга.
Сервер мониторинга обрабатывает собранную информацию журнала и сохраняет ее в ES.
Отображение данных, хранящихся в ES, через веб-страницы.

Основная логика выглядит следующим образом:

Реализация цепочки вызовов и агрегации журналов

часть цепочки вызовов: разработка модели, сбор информации на стороне сервера (легкий/тяжелый), сбор информации на уровне метода (легкий/тяжелый), сбор информации на стороне клиента (легкий/тяжелый), разработка протокола цепочки вызовов (легкий/тяжелый), контекст цепочки вызовов. передача, вызов Существует несколько ключевых процессов записи и передачи информации, а также вызова обработки статистических данных.

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

Подробнее см.:Документация по архитектуре

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

ключевая технология: Технологии сервисного портрета, сбор логов.

Подробнее см.:Документация по архитектуре

Добро пожаловать на скачивание UAVStackисходный кодилиДемонстрация разработки AllInOneопыт.

Показать результаты

Вход в цепочку вызовов:

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

Нажмите кнопку ассоциации справа, чтобы быстро найти связанный журнал.

запись в журнале:

По условиям поиска (поиск по ключевому слову Hello на рисунке) ищем журналы, удовлетворяющие условиям.

Щелкните конкретный журнал, чтобы войти в соответствующий интерфейс вызывающего процесса.

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

Официальный сайт

адрес с открытым исходным кодом

UAVStack имеет открытый исходный код на Github и предоставляет двуязычные документы, такие как инструкции по установке и развертыванию, инструкции по архитектуре и руководства пользователя.

Отсканируйте QR-код ниже и подпишитесь на общедоступную учетную запись, которая вас не разочарует.

Всем привет, меня зовут Ли Чонг, я архитектор CreditEase, руководитель группы мониторинга, apm и ServiceGovern проекта мониторинга на уровне группы CreditEase. Я. В то же время я также являюсь основным разработчиком проекта с открытым исходным кодом UAVStack.В эту субботу (20 октября) я буду гостем на Салоне технологий Nuggets, чтобы поделиться со всеми «Системой APM под несколькими технологическими стеками — UAVStack». Приветствуется общение на месте.

Нажмите на изображение, чтобы узнать подробности: