Удалённый демо-набор данных

Перейдите в Team Settings и нажмите Edit у Local Connection:

Переименуйте подключение в Demo и заполните следующую форму, указав сведения о подключении к демо-серверу:

• Connection Name: Demo
• Host: https://sql-clickhouse.clickhouse.com
• Username: otel_demo
• Password: оставьте пустым

Прокрутите вверх до Sources и измените каждый из источников — Logs, Traces, Metrics и Sessions — так, чтобы они использовали базу данных otel_v2.

Настройте временной диапазон так, чтобы отображались все данные за предыдущий 1 day, используя селектор времени в правом верхнем углу.

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

Чтобы выделить ошибки, используйте фильтр SeverityText и выберите error, чтобы отображались только записи уровня error.

Ошибка должна стать более заметной:

С помощью возможности Clustering в HyperDX вы можете автоматически выявлять ошибки и группировать их в осмысленные шаблоны. Это ускоряет анализ при работе с большими объёмами логов и трейсов. Чтобы использовать эту возможность, выберите Шаблоны событий в меню Режим анализа на левой панели.

Кластеры ошибок показывают проблемы, связанные с неуспешными платежами, в том числе шаблон с названием Failed to place order. Дополнительные кластеры также указывают на проблемы со списанием средств с карт и на переполненные кэши.

Обратите внимание, что эти кластеры ошибок, вероятно, связаны с разными сервисами.

Нажмите на наиболее заметный кластер ошибок, который коррелирует с зарегистрированной у нас проблемой, из-за которой пользователи могут завершать оплату: Failed to place order.

После этого отобразится список всех случаев этой ошибки, связанных с сервисом frontend:

Выберите любую из найденных ошибок. Подробно отобразятся метаданные журналов. Просмотр разделов Overview и Column Values указывает на проблему со списанием средств с карт из-за кэша:

failed to charge card: could not charge the card: rpc error: code = Unknown desc = Visa cache full: cannot add new item.

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

Учитывая проблему с кэшем, имеет смысл проверить базовую инфраструктуру — возможно, в связанных подах есть проблемы с памятью? В ClickStack журналы и метрики объединены и отображаются в контексте, что позволяет быстрее найти первопричину.

Выберите вкладку Infrastructure, чтобы просмотреть метрики, связанные с базовыми подами сервиса frontend, и расширьте временной диапазон до 1d:

Похоже, проблема не связана с инфраструктурой — за этот период метрики заметно не менялись ни до, ни после ошибки. Закройте вкладку Infrastructure.

В ClickStack трейсы также автоматически коррелируются и с журналами, и с метриками. Давайте рассмотрим трейс, связанный с выбранным журналом, чтобы определить, какой сервис за это отвечает.

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

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

Мы установили, что пользователи не могут завершить покупки из-за проблемы с кэшем в сервисе payment. Давайте подробнее изучим трассировки этого сервиса, чтобы понять первопричину.

Переключитесь в основное представление Search, выбрав Search. Смените источник данных на Traces и выберите представление Results table. Убедитесь, что временной диапазон по-прежнему охватывает последний день.

В этом представлении показаны все трассировки за последний день. Мы знаем, что проблема возникает в нашем сервисе payment, поэтому примените к ServiceName фильтр payment.

Если применить к трассировкам кластеризацию событий, выбрав Шаблоны событий, мы сразу увидим проблему с кэшем в сервисе payment.

Перейдите в представление результатов, нажав Results table. Отфильтруйте записи с ошибками с помощью фильтра StatusCode и значения Error.

Выберите ошибку Error: Visa cache full: cannot add new item., перейдите на вкладку Infrastructure и расширьте временной диапазон до 1d.

Сопоставив трейсы с метриками, видно, что потребление памяти и CPU сервисом payment выросло, а затем упало до 0 (вероятно, из-за перезапуска пода), что указывает на проблемы с ресурсами, вызванные переполнением cache. Можно ожидать, что это повлияло на время обработки платежей.

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

Хотя мы знаем, что у сервиса payment есть проблема с кэшем, из-за которой растёт потребление ресурсов, мы ещё не до конца выявили первопричину.

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

Удалите фильтр ошибок и выберите Event Deltas в левом меню Analysis Mode.

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

Если выбрать события с длительностью больше 1ms и применить фильтр Filter by selection, можно проанализировать различия между "обычными" событиями и группой высокой плотности спанов с длительностью около ~0ms:

После анализа этого подмножества данных видно, что спаны "background" вне выделения — это в основном транзакции visa, связанные с ответами 0ms из-за ошибок кэша.

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

Мы установили следующее:

• Проблема связана с сервисом payment
• Кэш переполнен
• Это привело к росту потребления ресурсов
• Из-за этой проблемы платежи Visa не завершались — или, по крайней мере, завершались очень долго.

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

• Data Source: Traces
• Metric: Maximum
• SQL Column: Duration
• Where: ServiceName: payment
• Timespan: Last 1 day

Нажатие ▶️ покажет, как со временем ухудшалась производительность обработки платежей.

Если задать Group By как SpanAttributes['app.payment.card_type'] (просто введите card для автодополнения), можно увидеть, как производительность сервиса для транзакций Visa ухудшилась по сравнению с Mastercard:

Обратите внимание: после возникновения ошибки ответы возвращаются за 0s.

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

Заполните следующие значения:

• Data Source: Metrics
• Metric: Maximum
• SQL Column: visa_validation_cache.size (gauge) (для автодополнения просто введите cache)
• Where: ServiceName: payment
• Group By: <empty>

Мы видим, что размер кэша рос в течение 4–5 часов (вероятно, после развертывания), прежде чем достиг максимального значения 100,000. По данным Sample Matched Events видно, что наши ошибки коррелируют с тем, что кэш достигает этого предела, после чего его размер фиксируется как 0, а ответы также начинают возвращаться за 0s.

В итоге, исследовав журналы, трейсы и, наконец, метрики, мы пришли к следующим выводам:

• Проблема связана с сервисом payment
• Изменение в поведении сервиса, вероятно вызванное развертыванием, привело к медленному росту кэша visa в течение 4–5 часов — до максимального размера 100,000.
• Это вызвало рост потребления ресурсов по мере увеличения кэша — вероятно, из-за неудачной реализации
• По мере роста кэша производительность платежей Visa ухудшалась
• Достигнув максимального размера, кэш начал отклонять платежи и сообщать, что его размер равен 0.

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

В HyperDX сеансы связаны с трассировками и журналами, что дает полное представление о первопричине.

Например, если служба поддержки передает email пользователя, столкнувшегося с проблемой при оплате, Ronny.Windler@gmail.com, — часто эффективнее начать с его сеанса, чем сразу искать по журналам или трассировкам.

Перейдите на вкладку Client Sessions в левом меню, предварительно убедившись, что в качестве источника данных выбрано Sessions, а временной период установлен на Last 1 day:

Найдите SpanAttributes.userEmail: Ronny.Windler, чтобы найти сеанс нашего клиента. При выборе сеанса слева отобразятся события браузера и связанные спаны этого сеанса, а справа — воспроизведенная картина действий пользователя в браузере:

Сеансы можно воспроизводить, нажимая кнопку ▶️. Переключение между Highlighted и All Events позволяет менять уровень детализации спанов: в первом режиме выделяются ключевые события и ошибки.

Если прокрутить список спанов до конца, можно увидеть ошибку 500, связанную с /api/checkout. Нажатие кнопки ▶️ для этого конкретного спана перемещает воспроизведение к этой точке сеанса, позволяя нам подтвердить впечатления клиента: похоже, что оплата просто не работает, и при этом никакая ошибка не отображается.

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