Использование расширения логов для отслеживания ошибок распределенных трассировок

Логи являются важнейшим компонентом для понимания поведения вашей среды. Объединив логи с распределенными трассировками, вы можете проверять записи логов в полном контексте транзакции. Автоматическая контекстуализация данных логов работает «из коробки» для популярных языков, таких как Java, .NET, Node.js, Go и PHP, а также для веб-серверов NGINX и Apache.

Прежде чем начать

Подключите данные логов к трассировкам в Logs.

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

Варианты использования

Анализ и устранение многочисленных проблем с помощью логов и трассировок

Сценарий

Проблема затрагивает множество сервисов и сочетает в себе увеличение частоты сбоев с ухудшением времени отклика.

Шаги

Мы начинаем наш анализ с затронутого сервиса Go и проверяем его динамические запросы.

Чтобы исследовать частоту отказов, выбираем плитку Частота отказов. Это переведет нас на вкладку Частота отказов на странице Подробности.

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

Мы сразу видим, что затронуто множество запросов, и Ключ-АСТРОМ предлагает несколько возможных первопричин. Для первой из них мы выбираем Подробности, чтобы изучить эту возможную первопричину.

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

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

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

На первый взгляд видно, что два трассировочных файла находятся в ошибочном состоянии. Если бы мы просмотрели их все, то обнаружили бы логи ошибок для каждого из /cart.

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

Анализируя распределенную трассировку, мы приходим к выводу, что проблема связана с сервисом GetCart, что существенно влияет на общее время ответа. Если мы проверим его логи, то обнаружим запись о медленном запросе.

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

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

Оставшиеся записи в логах указывают на проблему с неподдерживаемым типом карты. Давайте развернем лог и перейдем к трассировке распределенной сети.

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

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

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

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

Сценарий

В этом примере мы анализируем онлайн-бутик HipsterShop. Это демонстрационное приложение на основе облачных микросервисов, которое позволяет пользователям просматривать товары, добавлять их в корзину и совершать покупки.

На дашборде мы видим, что за последние 24 часа было зарегистрировано две проблемы.

Шаги

Выбрав раздел Проблемы для их изучения, мы обнаруживаем, что система HipsterShop столкнулась с увеличением количества ошибок JavaScript, что имело последствия для конечных пользователей. Чтобы получить более подробную информацию, мы открываем описание проблемы P-2205042.

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

Выбрав пункт Анализ снижения частоты сбоев, мы получаем обзор всех неудачных запросов, в котором выделяются следующие моменты:

• Какие запросы не были выполнены?
  В данном случае проблемы повлияли на выполнение запроса GetAds.
• Подробности исключения, связанного с неудачными запросами.
  В данном случае исключение NullPointerException было выброшено там, где ожидался объект AdService.
• Соответствующие логи ошибок и предупреждения.

Сценарий

На дашборде мы хотим исследовать сервис frontend, развернутый в качестве рабочей нагрузки Kubernetes. Чтобы получить информацию о рабочей нагрузке, мы выбираем плитку Рабочая нагрузка Kubernetes для внешнего интерфейса.

На странице с подробными сведениями о рабочей нагрузке отображаются все критически важные показатели ее состояния, такие как использование ЦП и памяти, а также ограничения базовых подов, время отклика, частота сбоев и пропускная способность развернутых сервисов. Если один из сервисов (в нашем случае, frontend) столкнулся с ошибкой, вы можете исследовать ее на странице сервиса или, как в нашем случае, проверить раздел Логи.

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

Это показывает, что выбранная запись в логах микросервиса frontend на Go является лишь частью более сложной схемы ошибки. Мы видим, что она вызывает метод PlaceOrder нижестоящего сервиса hipstershop.CheckoutService. Выбрав этот сервис, мы видим, что ЕдиныйАгент автоматически собирает дополнительную полезную информацию, например, тот факт, что это вызов gRPC. Выбрав вкладку Логи, мы видим, что во время этого вызова были созданы две записи в логах, включая сообщение об ошибке. Выбрав вкладку Показать связанные записи на уровне кода, мы также можем понять, в какой части микросервиса Go была сгенерирована конкретная строка журнала.

Выбрав строку NGINX frontend reverse proxy, мы видим, что вызов вернул клиенту ошибку 500 – Internal Server Error, которая, по-видимому, не является правильным кодом ошибки для неверной информации о кредитной карте.