Удаленный демонстрационный набор данных
В данном руководстве предполагается, что вы развернули Open Source-версию ClickStack, используя инструкции для образа «всё в одном» или режим Local Mode Only и выполнили начальное создание пользователя. Либо вы можете пропустить всю локальную настройку и просто подключиться к нашему размещённому демо ClickStack play-clickstack.clickhouse.com, которое использует этот набор данных.
В этом руководстве используется пример набора данных, размещённый в общедоступной песочнице ClickHouse по адресу sql.clickhouse.com, к которой вы можете подключиться из локального развертывания ClickStack.
Удалённые базы данных не поддерживаются при использовании Managed ClickStack. Поэтому этот набор данных недоступен.
Он включает примерно 40 часов данных, полученных из ClickHouse-версии официального демо OpenTelemetry (OTel). Данные каждую ночь повторно воспроизводятся со временными метками, смещёнными к текущему временному интервалу, что позволяет пользователям исследовать поведение системы, используя встроенные в HyperDX логи, трассировки и метрики.
Поскольку набор данных каждый день повторно воспроизводится с полуночи, конкретные визуализации могут отличаться в зависимости от того, когда вы изучаете демо.
Демонстрационный сценарий
В этом демонстрационном примере мы расследуем инцидент, связанный с интернет-магазином, который продает телескопы и сопутствующие аксессуары.
Команда службы поддержки сообщила, что пользователи сталкиваются с проблемами при завершении оплаты на этапе оформления заказа. Проблема была эскалирована в команду Site Reliability Engineering (SRE) для расследования.
Используя HyperDX, команда SRE проанализирует логи, трейсы и метрики, чтобы диагностировать и устранить проблему, а затем изучит данные пользовательских сессий, чтобы подтвердить, соответствуют ли их выводы фактическому поведению пользователей.
Демонстрация OpenTelemetry
В этой демонстрации используется форк официального демо OpenTelemetry, поддерживаемый ClickStack.
Архитектура демо
Демо состоит из микросервисов, написанных на разных языках программирования, которые взаимодействуют друг с другом по gRPC и HTTP, а также генератора нагрузки, использующего Locust для имитации пользовательского трафика. Исходный код этого демо был изменён для использования инструментации ClickStack.
Источник: https://opentelemetry.io/docs/demo/architecture/
Дополнительные сведения о демо приведены в:
Шаги демонстрации
В этом демо мы реализовали сбор телеметрии с помощью ClickStack SDKs, развернув сервисы в Kubernetes, откуда также собираются метрики и логи.
Подключение к демонстрационному серверу
Этот шаг можно пропустить, если при развертывании в локальном режиме вы нажали Connect to Demo Server. При использовании этого режима к именам источников будет добавлен префикс Demo_, например, Demo_Logs.
Перейдите в Team Settings и нажмите Edit для Local Connection:
Переименуйте подключение в Demo и заполните приведённую ниже форму следующими параметрами подключения к демонстрационному серверу:
Имя подключения:DemoHost:https://sql-clickhouse.clickhouse.comUsername:otel_demoPassword: оставьте поле пустым
Измените источники
Этот шаг можно пропустить, если при развертывании в локальном режиме вы нажали Connect to Demo Server. При использовании этого режима к источникам будет добавлен префикс Demo_, например Demo_Logs
Прокрутите вверх до Sources и измените каждый из источников — Logs, Traces, Metrics и Sessions — так, чтобы они использовали базу данных otel_v2.
Возможно, потребуется перезагрузить страницу, чтобы в каждом источнике отобразился полный список баз данных.
Настройте временной диапазон
Установите в селекторе времени в правом верхнем углу диапазон 1 день, чтобы отобразить все данные за последние сутки.
Вы можете заметить небольшое изменение в количестве ошибок на обзорной гистограмме — небольшое увеличение красного цвета в нескольких последовательных столбцах.
Расположение столбцов будет отличаться в зависимости от того, когда вы запрашиваете набор данных.
Фильтрация ошибок
Чтобы выделить появления ошибок, используйте фильтр SeverityText и выберите error, чтобы отображать только записи уровня ошибки.
Ошибка должна стать более заметной:
Выявление шаблонов ошибок
С помощью функции кластеризации HyperDX вы можете автоматически выявлять ошибки и группировать их в значимые шаблоны. Это ускоряет анализ при работе с большими объёмами логов и трассировок. Чтобы воспользоваться этой функцией, выберите Event Patterns в меню Analysis Mode на левой панели.
Кластеры ошибок выявляют проблемы, связанные с неудавшимися платежами, включая именованный шаблон Failed to place order. Дополнительные кластеры также указывают на проблемы со списанием средств с карт и переполнением кэша.
Обратите внимание, что эти кластеры ошибок, вероятнее всего, относятся к разным сервисам.
Изучение паттерна ошибок
Нажмите на наиболее очевидный кластер ошибок, который коррелирует с зарегистрированной проблемой, из‑за которой пользователи не могут завершить платежи: Failed to place order.
Отобразится список всех случаев этой ошибки, связанных с сервисом frontend:
Выберите любую из получившихся ошибок. Метаданные журналов будут показаны подробно. Прокрутка как раздела Overview, так и Column Values указывает на проблему с платёжными картами из‑за кеша:
ошибка списания с карты: не удалось списать средства с карты: rpc error: code = Unknown desc = кэш Visa переполнен: невозможно добавить новый элемент.
Изучите инфраструктуру
Мы выявили ошибку, связанную с кешем, которая, вероятно, приводит к сбоям платежей. Необходимо определить, в каком компоненте микросервисной архитектуры возникает данная проблема.
Учитывая проблему с кешем, имеет смысл проверить базовую инфраструктуру — возможно, в связанных подах возникла проблема с памятью? В ClickStack логи и метрики объединены и отображаются в контексте, что позволяет быстро выявить первопричину.
Выберите вкладку Infrastructure, чтобы просмотреть метрики, связанные с базовыми подами сервиса frontend, и расширьте временной интервал до 1d:
Похоже, проблема не связана с инфраструктурой — метрики за весь период наблюдения практически не изменились ни до, ни после возникновения ошибки. Закройте вкладку «Инфраструктура».
Изучение трассировки
В ClickStack трассировки также автоматически коррелируются и с логами, и с метриками. Давайте изучим трассировку, связанную с выбранным логом, чтобы определить, какой сервис за это отвечает.
Выберите Trace для визуализации соответствующей трассировки. При прокрутке вниз в открывшемся представлении можно увидеть, как HyperDX визуализирует распределённую трассировку по микросервисам, связывая спаны в каждом сервисе. Платёж явно задействует несколько микросервисов, включая те, которые выполняют оформление заказа и конвертацию валют.
Прокрутив представление до самого низа, можно увидеть, что сервис payment вызывает ошибку, которая затем распространяется обратно вверх по цепочке вызовов.
Поиск трассировок
Мы установили, что пользователи не могут завершить покупки из-за проблемы с кешем в платежном сервисе. Рассмотрим трассировки этого сервиса более детально, чтобы выяснить больше о первопричине.
Переключитесь на главное представление Search, выбрав Search. Переключите источник данных на Traces и выберите представление Results table. Убедитесь, что временной диапазон по‑прежнему составляет последние сутки.
Это представление отображает все трассировки за последние сутки. Поскольку мы знаем, что проблема исходит из платёжного сервиса, примените фильтр payment к полю ServiceName.
Если к трассировкам применить кластеризацию событий, выбрав Event Patterns, можно сразу обнаружить проблему с кешем в сервисе payment.
Изучение инфраструктуры для трассировки
Переключитесь на представление результатов, нажав на Results table. Отфильтруйте ошибки с помощью фильтра StatusCode и значения Error.
Выберите ошибку с текстом Error: Visa cache full: cannot add new item., переключитесь на вкладку Infrastructure и увеличьте временной диапазон до 1d.
Сопоставляя трассировки с метриками, мы видим, что потребление памяти и CPU увеличилось у сервиса payment, после чего упало до 0 (это можно объяснить перезапуском пода) — что указывает на то, что проблема с кэшем вызвала дефицит ресурсов. Можно ожидать, что это повлияло на время завершения платежей.
Дельты событий для более быстрого устранения
Event Deltas помогают обнаруживать аномалии, связывая изменения производительности или частоты ошибок с конкретными подсетами данных — что позволяет быстрее точно определить первопричину.
Хотя мы знаем, что у сервиса payment есть проблема с кэшем, приводящая к увеличению потребления ресурсов, мы пока полностью не установили её первопричину.
Вернитесь к табличному представлению результатов и выберите временной период, содержащий ошибки, чтобы ограничить объём данных. Убедитесь, что выбрали интервал, который, по возможности, охватывает несколько часов до появления ошибок и несколько часов после них (проблема может всё ещё проявляться):
Удалите фильтр ошибок и в левом меню Analysis Mode выберите Event Deltas.
Верхняя панель показывает распределение временных интервалов, где цвета обозначают плотность событий (количество спанов). Подмножество событий за пределами основной концентрации, как правило, заслуживает наиболее пристального внимания при анализе.
Если выбрать события с длительностью более 200ms и применить фильтр Filter by selection, можно ограничить анализ только более медленными событиями:
Проведя анализ этого подмножества данных, мы видим, что большинство всплесков производительности связано с транзакциями visa.
Использование графиков для дополнительного контекста
В ClickStack можно построить график любого числового значения из логов, трейсов или метрик для получения дополнительного контекста.
Мы установили, что:
- Проблема на стороне платёжного сервиса
- Кэш переполнен
- Это приводило к увеличению потребления ресурсов
- Проблема мешала успешному завершению платежей по картам Visa — или, по крайней мере, значительно замедляла их обработку.
Выберите Chart Explorer в меню слева. Заполните следующие значения, чтобы построить график времени завершения платежей по типу диаграммы:
Источник данных:ТрассировкиМетрика:MaximumСтолбец SQL:DurationГде:ServiceName: paymentИнтервал времени:Последние 24 часа
Нажатие ▶️ покажет, как со временем ухудшалась производительность платежей.
Если установить Group By в значение SpanAttributes['app.payment.card_type'] (для автодополнения достаточно ввести card), можно увидеть, как производительность сервиса ухудшилась для транзакций Visa по сравнению с Mastercard:
Обратите внимание, что после возникновения ошибки ответы приходят с временем 0s.
Изучение метрик для дополнительного контекста
Наконец, построим график размера кэша как метрики, чтобы увидеть, как он вел себя с течением времени, и получить дополнительный контекст.
Укажите следующие значения:
Источник данных:МетрикиМетрика:MaximumSQL Column:visa_validation_cache.size (gauge)(для автодополнения достаточно ввестиcache)Где:ServiceName: paymentGroup By:<пусто>
Мы видим, как размер кэша увеличивался в течение 4–5 часов (вероятно, после развертывания программного обеспечения), прежде чем достичь максимального размера 100,000. Из раздела Sample Matched Events видно, что наши ошибки коррелируют с достижением кэшем этого предела, после чего он фиксируется с размером 0, а ответы также возвращаются за 0 с.
Итак, последовательно проанализировав логи, трассировки и, наконец, метрики, мы пришли к следующим выводам:
- Проблема связана с платёжным сервисом
- Изменение поведения сервиса, вероятно вызванное развертыванием, привело к медленному росту кэша Visa в течение 4–5 часов, в результате чего его размер достиг максимального значения
100 000. - Это вызвало увеличение потребления ресурсов по мере увеличения размера кэша — вероятно, из‑за неудачной реализации
- По мере роста кэша ухудшалась производительность платежей по картам Visa
- После достижения максимального размера кэш начал отклонять платежи и сообщал, что его размер равен
0.
Использование сессий
Сессии позволяют воспроизвести пользовательский опыт, предоставляя визуальное представление того, как произошла ошибка с точки зрения пользователя. Хотя их обычно не используют для диагностики первопричин, они ценны для подтверждения проблем, о которых сообщается в службу поддержки, и могут служить отправной точкой для более глубокого анализа.
В HyperDX сессии связаны с трассировками и логами, что обеспечивает полное представление о первопричине проблемы.
Например, если команда поддержки предоставляет адрес электронной почты пользователя, столкнувшегося с проблемой оплаты Braulio.Roberts23@hotmail.com — зачастую эффективнее начать с анализа его сеанса, а не с прямого поиска по логам или трассировкам.
Перейдите на вкладку Client Sessions в левом меню и убедитесь, что источник данных установлен на Sessions, а период времени — Last 1 day:
Выполните поиск по SpanAttributes.userEmail: Braulio, чтобы найти сеанс нашего клиента. При выборе сеанса слева отобразятся события браузера и связанные спаны для этого сеанса, а справа — повторно воспроизведённый опыт пользователя в браузере:
Воспроизведение сеансов
Сеансы можно воспроизвести, нажав кнопку ▶️. Переключение между режимами Highlighted и All Events позволяет изменять степень детализации спанов: первый выделяет ключевые события и ошибки.
Прокрутив список спанов вниз, можно увидеть ошибку 500, связанную с /api/checkout. Нажатие кнопки ▶️ для этого спана переместит воспроизведение к данной точке сессии, что позволит подтвердить опыт пользователя — оплата просто не работает, при этом ошибка не отображается.
Выбрав спан, мы можем подтвердить, что это было вызвано внутренней ошибкой. Нажав на вкладку Trace и прокрутив связанные спаны, мы можем убедиться, что клиент действительно стал жертвой нашей проблемы с кэшем.
Это демо разбирает реальный инцидент с неуспешными платежами в e-commerce‑приложении и показывает, как ClickStack помогает выявлять первопричины с помощью объединённых логов, трейсов, метрик и записей сессий — ознакомьтесь с другими руководствами по началу работы, чтобы глубже изучить отдельные возможности.
