Различия в данныхПоскольку набор данных каждый день воспроизводится с полуночи, точные визуализации могут различаться в зависимости от того, когда вы открываете демо.
Демонстрационный сценарий
Демо OpenTelemetry
Архитектура демо
Шаги демонстрации
Подключение к демонстрационному серверу
Режим только для локальной работыЭтот шаг можно пропустить, если при развертывании в локальном режиме вы нажали
Connect to Demo Server. В этом режиме к именам источников добавляется префикс Demo_, например Demo_LogsTeam Settings и нажмите Edit у Local Connection:Переименуйте подключение в Demo и заполните следующую форму, используя следующие сведения о подключении к демонстрационному серверу:Connection Name:DemoHost:https://sql-clickhouse.clickhouse.comUsername:otel_demoPassword: Оставьте пустым
Измените источники
Только локальный режимЭтот шаг можно пропустить, если при развертывании в локальном режиме вы нажали
Connect to Demo Server. В этом режиме к именам источников добавляется префикс Demo_, например Demo_LogsSources и измените каждый источник — Logs, Traces, Metrics и Sessions — так, чтобы он использовал базу данных otel_v2.Возможно, потребуется перезагрузить страницу, чтобы в каждом источнике отображался полный список баз данных.
Настройте временной диапазон
Настройте время так, чтобы отображались все данные за предыдущий1 day, используя селектор времени в правом верхнем углу.На обзорной столбчатой диаграмме можно заметить небольшую разницу в количестве ошибок: в нескольких соседних столбцах немного увеличится красная часть.Расположение столбцов будет различаться в зависимости от того, когда вы выполняете запрос к набору данных.
Отфильтруйте ошибки
Чтобы выделить ошибки, используйте фильтрSeverityText и выберите error, чтобы отображались только записи с уровнем error.Теперь ошибки будут заметнее:Выявление шаблонов ошибок
С помощью возможности Clustering в HyperDX вы можете автоматически выявлять ошибки и группировать их в осмысленные шаблоны. Это ускоряет анализ при работе с большими объёмами логов и трассировок. Чтобы воспользоваться этой возможностью, выберитеEvent Patterns в меню Analysis Mode на левой панели.Кластеры ошибок показывают проблемы, связанные со сбоями при оплате, включая именованный шаблон 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 визуализирует распределённый трейс между микросервисами, связывая спаны в каждом сервисе. Платёж явно задействует несколько микросервисов, в том числе те, которые выполняют checkout и конвертацию валют.Прокрутив представление до самого низа, мы увидим, что ошибку вызывает сервис payment, и затем она распространяется вверх по цепочке вызовов.Поиск трейсов
Мы установили, что пользователи не могут завершить покупки из-за проблемы с кэшем в сервисе payment. Давайте подробнее изучим трейсы этого сервиса, чтобы лучше понять первопричину.Переключитесь в основное представление Search, выбравSearch. Смените источник данных на Traces и выберите представление Results table. Убедитесь, что временной диапазон по-прежнему установлен на последний день.В этом представлении показаны все трейсы за последний день. Мы знаем, что проблема возникает в нашем сервисе payment, поэтому примените фильтр payment к ServiceName.Если применить к трейсам кластеризацию событий, выбрав Event Patterns, мы сразу увидим проблему с кэшем в сервисе payment.Изучите инфраструктуру трейса
Переключитесь в представление результатов, нажавResults table. Отфильтруйте ошибки с помощью фильтра StatusCode и значения Error.Выберите ошибку Error: Visa cache full: cannot add new item., перейдите на вкладку Infrastructure и увеличьте временной диапазон до 1d.Сопоставив трейсы с метриками, мы видим, что у сервиса payment выросло потребление памяти и CPU, а затем показатели упали до 0 (это можно связать с перезапуском пода) — это указывает на то, что проблема с кэшем привела к проблемам с ресурсами. Можно ожидать, что это повлияло на время завершения платежей.Event Deltas для более быстрого поиска причины
Event Deltas помогают выявлять аномалии, связывая изменения производительности или частоты ошибок с конкретными подмножествами данных, что позволяет быстрее определить первопричину.Хотя мы знаем, что у сервисаpayment есть проблема с кэшем, из-за которой растёт потребление ресурсов, первопричина всё ещё не установлена.Вернитесь к представлению таблицы результатов и выберите период времени, содержащий ошибки, чтобы ограничить объём данных. Обязательно захватите несколько часов до появления ошибок и, если возможно, после них (проблема может всё ещё сохраняться):Удалите фильтр ошибок и выберите Event Deltas в левом меню Analysis Mode.На верхней панели показано распределение длительностей, где цвет указывает на плотность событий (количество спанов). Обычно имеет смысл исследовать подмножество событий вне основной концентрации.Если выбрать события с длительностью больше 1ms и применить фильтр Filter by selection, можно проанализировать различия между “обычными” событиями и группой высокой плотности спанов с длительностью около 0 мс:При анализе этого подмножества данных видно, что спаны на “фоне” вне выделения — это в основном транзакции Visa, связанные с ответами длительностью 0 мс из-за ошибок кэша.Использование графиков для дополнительного контекста
В ClickStack можно строить графики по любым числовым значениям из журналов, трасс или метрик, чтобы получить больше контекста.Мы установили следующее:- Проблема связана с сервисом payment
- Кэш заполнен
- Это привело к росту потребления ресурсов
- Из-за проблемы платежи Visa не завершались или, по крайней мере, выполнялись очень долго.
Выберите
Chart Explorer в левом меню. Заполните следующие поля, чтобы построить график времени, необходимого для завершения платежей, по типу графика:Data Source:TracesMetric:MaximumSQL Column:DurationWhere:ServiceName: paymentTimespan:Last 1 day
Нажатие
▶️ покажет, как со временем ухудшалась производительность обработки платежей.Если задать Group By как SpanAttributes['app.payment.card_type'] (просто введите card для автодополнения), можно увидеть, как производительность сервиса для транзакций Visa ухудшалась по сравнению с Mastercard:Обратите внимание: после возникновения ошибки ответы возвращаются за 0s.Дополнительный контекст при изучении метрик
Наконец, давайте построим график размера кэша как метрики, чтобы посмотреть, как он менялся со временем, и тем самым получить больше контекста.Заполните следующие значения:Data Source:MetricsMetric:MaximumSQL Column:visa_validation_cache.size (gauge)(для автодополнения просто введитеcache)Where:ServiceName: paymentGroup By:<empty>
100,000. По Sample Matched Events видно, что наши ошибки коррелируют с тем моментом, когда кэш достигает этого предела, после чего его размер фиксируется как 0, а время ответа тоже становится 0s.Подводя итог, изучив логи, трейсы и, наконец, метрики, мы пришли к следующим выводам:- Проблема связана с сервисом payment
- Изменение в поведении сервиса, вероятно вызванное развертыванием, привело к медленному росту кэша visa в течение 4–5 часов — до максимального значения
100,000. - Это привело к росту потребления ресурсов по мере увеличения кэша — вероятно, из-за неудачной реализации
- По мере роста кэша производительность платежей Visa ухудшалась
- Достигнув максимального размера, кэш начал отклонять платежи и сообщать о размере
0.
Использование сеансов
Сеансы позволяют воспроизводить действия пользователя, наглядно показывая, как именно произошла ошибка с его точки зрения. Хотя их обычно не используют для поиска первопричины, они полезны для подтверждения проблем, о которых сообщает служба поддержки, и могут служить отправной точкой для более глубокого расследования.В HyperDX сеансы связаны с трассировками и журналами, что дает полное представление о первопричине.Например, если команда поддержки передала адрес электронной почты пользователя, столкнувшегося с проблемой при оплате,Ronny.Windler@gmail.com, часто эффективнее начать с его сеанса, а не сразу искать в журналах или трассировках.Перейдите на вкладку Client Sessions в левом меню, предварительно убедившись, что в качестве источника данных выбрано Sessions, а период времени установлен на Last 1 day:Выполните поиск по SpanAttributes.userEmail: Ronny.Windler, чтобы найти сеанс нашего клиента. При выборе сеанса слева отобразятся события браузера и связанные спаны для этого сеанса, а справа — заново воспроизведенное поведение пользователя в браузере:Повторное воспроизведение сеансов
Сеансы можно воспроизводить, нажимая кнопку ▶️. Переключение междуHighlighted и All Events позволяет менять степень детализации спанов: в первом режиме выделяются ключевые события и ошибки.Если прокрутить список спанов до конца, можно увидеть ошибку 500, связанную с /api/checkout. Нажатие кнопки ▶️ для этого конкретного спана переносит воспроизведение к этой точке сеанса, позволяя нам увидеть, что происходило у клиента: похоже, оплата просто не работает, и при этом никакая ошибка не отображается.Выбрав этот спан, мы можем убедиться, что причиной была внутренняя ошибка. Перейдя на вкладку Trace и прокрутив связанные спаны, мы можем подтвердить, что клиент действительно пострадал из-за нашей проблемы с кэшем.